On 10/11/11 22:52, Leo Simons wrote:
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.
+1
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.
+1
Actions speak louder than words.
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
+1
I see no point setting expectations (e.g. saying when things will be
done) without a mechanism to reflect costs and trade-offs.All that
happens is that there will be a growing pile of guilt. At which point
either release get pushed out or expectations are not met. Both are bad.
Andy
