You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Pascal Sancho <ps...@gmail.com> on 2012/12/19 18:14:18 UTC

Jira: using issue type field

Hi,

Jira comes with
 - a new field [Type] that didn't exist in Bugzilla, with following entries:
" Bug", "New feature", "Improvement", "Wish", "Task", and "Test".
 - the opportunity to create sub-tasks.

I propose the following usage:

"Bug": a bug report, and only that

"New feature" and "Improvement":
 - contributor patch (rather than add "[patch]" in summary),
 - committer contribution

"Wish": new feature request

"Task": team process (like release).

When a contributor proposes a patch to fix a bug, he should create a
sub-task (type "Improvement") rather than change the summary and the
type of the issue.
So, bug discussion and patch comments will be in separate tasks.

WDYT?

-- 
pascal

Re: Jira: using issue type field

Posted by Pascal Sancho <ps...@gmail.com>.
Hmm, I have a concrete example:

wish: FOP-1785 [1], Auto Table Layout
patch #1: FOP-1226 [2], [PATCH] auto table layout -- dirty draft
patch #2: FOP-1674 [3], [PATCH] auto table layout - yet another patch

There are 2 patches and 1 bug/wish that are about the same topic.
today, the only relation is dependence indicator between the 2
patches, but they all clearly serve the same main topic: wish to
implement AutoTableLayout, witch is described by the Wish task (IMHO,
the mother task).

Same situation can occur with a bug.

[1] https://issues.apache.org/jira/browse/FOP-1785
[2] https://issues.apache.org/jira/browse/FOP-1226
[3] https://issues.apache.org/jira/browse/FOP-1674

2012/12/19 Glenn Adams <gl...@skynav.com>:
>
> On Wed, Dec 19, 2012 at 9:14 AM, Pascal Sancho <ps...@gmail.com>
> wrote:
>>
>> Jira comes with
>>  - a new field [Type] that didn't exist in Bugzilla, with following
>> entries:
>> " Bug", "New feature", "Improvement", "Wish", "Task", and "Test".
>>  - the opportunity to create sub-tasks.
>>
>> I propose the following usage:
>>
>> "Bug": a bug report, and only that
>>
>> "New feature" and "Improvement":
>>  - contributor patch (rather than add "[patch]" in summary),
>>  - committer contribution
>>
>> "Wish": new feature request
>>
>> "Task": team process (like release).
>>
>> When a contributor proposes a patch to fix a bug, he should create a
>> sub-task (type "Improvement") rather than change the summary and the
>> type of the issue.
>> So, bug discussion and patch comments will be in separate tasks.
>>
>> WDYT?
>
>
> Personally I prefer bug discussion and patch comments to be in one issue.
> This makes it easier (for me) to keep track of activity instead of having to
> look in multiple places. If there is a legitimate need for a [Meta] issue
> that covers multiple sub-issues/tasks, then that's ok, but should include a
> [Meta] tag in its description, and then indicate it is blocked by the
> sub-issues.



-- 
pascal

Re: Jira: using issue type field

Posted by Glenn Adams <gl...@skynav.com>.
On Wed, Dec 19, 2012 at 9:14 AM, Pascal Sancho <ps...@gmail.com>wrote:

> Jira comes with
>  - a new field [Type] that didn't exist in Bugzilla, with following
> entries:
> " Bug", "New feature", "Improvement", "Wish", "Task", and "Test".
>  - the opportunity to create sub-tasks.
>
> I propose the following usage:
>
> "Bug": a bug report, and only that
>
> "New feature" and "Improvement":
>  - contributor patch (rather than add "[patch]" in summary),
>  - committer contribution
>
> "Wish": new feature request
>
> "Task": team process (like release).
>
> When a contributor proposes a patch to fix a bug, he should create a
> sub-task (type "Improvement") rather than change the summary and the
> type of the issue.
> So, bug discussion and patch comments will be in separate tasks.
>
> WDYT?
>

Personally I prefer bug discussion and patch comments to be in one issue.
This makes it easier (for me) to keep track of activity instead of having
to look in multiple places. If there is a legitimate need for a [Meta]
issue that covers multiple sub-issues/tasks, then that's ok, but should
include a [Meta] tag in its description, and then indicate it is blocked by
the sub-issues.

Re: Jira: using issue type field

Posted by Chris Bowditch <bo...@hotmail.com>.
Hi Pascal,

On 19/12/2012 17:14, Pascal Sancho wrote:
> Hi,
>
> Jira comes with
>   - a new field [Type] that didn't exist in Bugzilla, with following entries:
> " Bug", "New feature", "Improvement", "Wish", "Task", and "Test".
>   - the opportunity to create sub-tasks.
>
> I propose the following usage:
>
> "Bug": a bug report, and only that
>
> "New feature" and "Improvement":
>   - contributor patch (rather than add "[patch]" in summary),
>   - committer contribution

Thanks for raising this. Its true Jira has a whole host of extras that 
we aren't used to, but in my view, FOP is quite a straight forward 
project with simple requirements, so most of the extra features aren't 
needed in my view.

Patches exist for bugs as well as enhancements, so to classify a Jira 
issue as New feature or improvement when a patch is associated seems 
misleading to me, especially when the patch exists to fix a bug.

>
> "Wish": new feature request
There are too many types that simply mean "Enhancement"; Wish, New 
Feature and Improvement could all be rolled into 1 in my view. It's true 
they are subtley different, but as committers do we really need to 
capture that information?
>
> "Task": team process (like release).
>
> When a contributor proposes a patch to fix a bug, he should create a
> sub-task (type "Improvement") rather than change the summary and the
> type of the issue.
> So, bug discussion and patch comments will be in separate tasks.

I agree with Glenn on this. It just seems like adding complexity for 
complexity sake. Those features are more useful in a commercial 
development environment where Managers like to conduct sprint reviews of 
tasks and see the work broken down for better estimation and work 
sharing. I don't think this applies in open source development as 
bugs/improvements are usually tackled by individuals and I suggest that 
we lock these features down to prevent the public creating them.

Thanks,

Chris

>
> WDYT?
>