[
https://issues.apache.org/jira/browse/ACCUMULO-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13981411#comment-13981411
]
Christopher Tubbs commented on ACCUMULO-2736:
---------------------------------------------
The biggest thing I see when looking at JIRA tickets/doing queries is issues
marked with a fixVersion that are resolved with something other than "Fixed",
or something marked as "Fixed" without a fixVersion (often, those should have
been "Won't Fix" or "Cannot Reproduce", but it was an oversight).
Most of these are obvious in their use: "Cannot Reproduce", "Invalid", "Won't
Fix", "Duplicate", because it's obvious no work has been done. If no work has
been done, it doesn't make sense to have a fixVersion on them.
It also seems obvious that something should not be marked "Fixed" without a
fixVersion, as that serves no benefit to users querying JIRA.
The less obvious ones are "Done", which is not defined in JIRA's help, and
"Implemented", which doesn't have a good definition. Because "Implemented" and
"Done" don't show up in the auto-generated release notes in JIRA, I can only
assume they mean something like "not fixing, because it's already done". The
few tickets I saw that had a fixVersion and one of these resolutions used it
that way. Another interpretation could be "Done, but I don't want it to be in
the CHANGES, because it's a task done for a particular version, but was a
change to the website, not the actual code" or "Implemented, but not tested, so
I don't want to advertise that it is resolved in the CHANGES".
I don't personally use "Implemented" or "Done" as resolutions when I resolve
issues, but if somebody else uses them in a particular way, I agree we should
probably define how they should be used. Personally, I think they should just
be excluded from the options, as they aren't clear.
> update our contributor guidelines to explain how we use jira
> ------------------------------------------------------------
>
> Key: ACCUMULO-2736
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2736
> Project: Accumulo
> Issue Type: Task
> Components: docs
> Reporter: Sean Busbey
> Priority: Minor
>
> It would help use reduce churn on the jira if we had a short guide for people
> on selecting Types, Priorities, Components, Labels, FixVersions, and
> Resolution Status.
> Take resolution statuses as an example. We should start with and link to
> [jira's built in
> help|https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#ResolutionTypes]
> We should clarify any resolution types that use explanations that claim the
> purpose is obvious (i.e. Implemented, Later, Done, Unresolved) and any that
> we add above the defaults. In particular, we should emphasize the use of
> statuses that end up in release CHANGES.
> From IRC, we should leverage Christopher's explanation of how he reads the
> resolution types:
> {noformat}
> 12:51 <@elserj> not sure what your criteria on fixVersion is
> 12:52 <@ctubbsii> fixVersion should be used if it's marked "Fixed",
> otherwise, it doesn't make sense. only "Fixed" issues show up in CHANGES
> (JIRA's auto-generated release notes)
> 12:53 <@ctubbsii> all other labels are reasons *not* to fix it ("Done" means
> "don't need to do, because it's already done", "Implemented" means "don't
> need to do, because it's already implemented",
> etc.).
> 12:53 <@ctubbsii> I'm updating the resolution type and fixVersion, based on
> whether the issue identified was addressed in that version.
> 12:54 <@madrob> ctubbsii: can you document that somewhere. i'm not sure that
> i share your view of JIRA states
> 12:54 <@ctubbsii> madrob: it's no my view... it's how JIRA uses it internally.
> 12:54 <@ctubbsii> s/no/not/
> 12:54 <@madrob> i would still like a link
> 12:54 <@ctubbsii> This is empirical. I don't know if it's documented.
> 12:55 <@busbey> ctubbsii: you could perhaps update our contributors page
> 12:55 <@busbey> to say what status should be used on closing a ticket
> 12:56 <@ctubbsii> busbey: I could... but I'm busy on other tasks... would
> somebody who has an interest in that mind performing that task that they wish
> to see accomplished?
> 12:57 <@madrob> i'm interested in seeing what your definitions are
> 12:57 <@ctubbsii> madrob: definitions of what?
> 12:57 <@busbey> I'm interested in tickets being closed correctly the first
> time. I can't help make clear to people the criteria that results in you
> reclosing.
> 12:58 <@busbey> I mean, I'm willing to take a shot at reverse engineering it
> 12:58 <@busbey> the chat room here is an excellent start
> 12:58 <@busbey> but I'm hesitant to document something, have people start
> taking it as 'the right way', and cause you further trouble down the road
> 12:59 <@busbey> ctubbsii: madrob means your definitions of ticket statuses
> 12:59 <@busbey> how about I make a ticket that we need this and people can
> follow up if needed later
> 13:00 <@ctubbsii> I don't have definitions. All I know is that the only
> resolution that ends up in CHANGES is "Fixed", which implies that the only
> resolution that implies "Fixed" is "Fixed". I don't have definitions of the
> others... I'm guessing.
> 13:02 <@madrob> Then you can make a definition. Or look up if Atlassian
> provides definitions.
> 13:02 <@madrob> I just want consistency.
> 13:02 <@kturner> when you go to resolve an issue there is a little help
> 13:02 <@kturner> question mark
> 13:02 <@kturner> everything is defined except for Done
> 13:03 <@kturner>
> https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#ResolutionTypes
> 13:05 <@busbey> that help isn't clear on e.g. if a new feature request should
> be closed as "Implemented" or "Fixed"
> 13:05 <@busbey> my guess is Fixed so it shows up in CHANGES
> 13:06 <@ctubbsii> kturner: thanks for the link. It clearly states that only
> one of them is "Fixed". While it doesn't provide strict definitions for
> "Implemented" and "Done", it does seem explicit that they do not imply a fix
> is "checked into the tree and tested"
> 13:07 <@kturner> thanks for cleaning up the tickets... its a big improvement
> over the previous state of things
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
