Hi Leo
Leo Simons wrote:
On Thu, Nov 10, 2011 at 4:31 PM, Paolo Castagna
<[email protected]> wrote:
Paolo Castagna wrote:
Hi,
perhaps we can try to use JIRA "Fix Version/s" to assign JIRA
issues to releases (they can be moved as we wish).
We also should probably clarify how we want to use the "Fix Version/s"
in JIRA. There is also a "Fix for Version" field, but I do not see it
available in the JIRA version which Apache is using or maybe there is
a reason why it's disabled.
Mentors?
Hmm, what? I don't know what you mean. Jira by default has two version
fields, "Affects Version" and "Fix Version", and ASF jira is no
different. It's possible to add custom fields to jira but it's better
not to.
Generally people use "Fix Version" as "target fix version" until the
issue is closed, at which point the "fix version" is updated to the
version that the issue is / will be actually fixed in.
If a different field isn't available we could decide that:
- Fix Version/s for an open bug with a value of an unreleased version
is an expression of intent to fix that issue by the time we do a
release
- Fix Version/s for a closed bug with a value of a released version
is to say that that issue has been resolved (and released in that
specific release).
Other Apache projects seems to adopt this practice, for example:
https://issues.apache.org/jira/browse/WHIRR#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel
What do you think?
Lots of things.
For open source projects I prefer to not set fix versions at all until
an issue is actually fixed. When you do set it, match the version
number to the actual number in the associated artifact(s) that users
download, and nothing else. That way, the jira release notes are
accurate.
Similarly, I don't think due date is useful in our context.
Jira is great for project planning and scheduling and tracking
commercial software delivery. But for community open source projects,
it is better not to measure or promise or schedule as precisely as you
do in the commercial environment. The dynamic is different.
My advice would be not to focus too much on capturing intentions and
roadmaps and long-term plans in jira or in documentation. Discuss
plans on the mailing list, make sure you have consensus on the general
direction and goals, and then everybody works towards those goals as
they have time and energy available. Don't publish long term schedules
out to your user community, only announce things when they are
actually implemented.
If you do want to do some kind of scheduling/metrics using jira,
there's a bunch of stuff you can look at beyond the roadmap. I'd
suggest an important one would be average age and resolution time of
bugs (and only bugs), and another one is average age and resolution
time for issues that have a patch submission, but that one is a bit
harder to do a report on.
In other words, do things pretty much like jena has always done
them...but hey, you asked ;-)
Ok, I'll take the advice and remove the "Fix Version/s" when used in
forward looking/planning mode. But, I'll leave them in when an issue
is closed pointing to the version when the issue has been fixed.
I still thing there is some value in communicating (closer to a release
what's still missing so that people who want to help out knows where
they can help).
Long email threads do not work so well as a list of issues on JIRA
grouped by a future release version. I am not saying we do this for
medium-long term stuff (I'll remove what I did on JIRA), but I do not
see what are the cons in the short term.
Thanks Leo.
Paolo
cheerio,
Leo
