David Crossley wrote:
Ross Gardler wrote:
I suggest that we stop adding target numbers to every issue in Jira. It
seems that we tend to put a fix version that represents what we would
like to see, but not what we can achieve.
We need faster release cycle and one way to do this is to reduce the
expectations for each release.
So, I propose that we only put a fix version on something once we *know*
it will be going into the next release. In the long run this will save
us allot of time during the release process sorting out the issue tracker.
And how will we "know"?
First of all, if no-one is tackling a task then it won't be done.
Secondly, once we agree the goals for a release we can saefly say it
will be included. Of course this may change as we learn more about the
task, but at least we start from a position of intent rather than desire.
The way that we have been doing it until now,
is that the Roadmap represents what we would like
to achieve, while the rest remain in the Unscheduled
state. Approaching release date, we start to
move unachievable issues into the next release and
would try to attend to them next time.
Yes, that is exactly my point. What we end up with is almost everything
goes into the next release. What I am advocating is some thought about
where something belongs and where it is truly attainable.
It was working okay when we had a smaller number of
open issues. Now it has become unwieldy.
Yes.
Note this does not mean it will take longer to get features into
Forrest, they will still happen when they happen. It just means we are
not continually updating fix release numbers and misleading our users.
For example, XHTML2 was originally scheduled for 0.6!
One exception to this rule should be any bug that is considered critical
or blocker will automatically go into the next release.
WDYT?
It depends on what we mean by "Roadmap". We should
clearly define that and add it to our Guidelines doc.
Yes, for me a roadmap is a document that defines the progression of the
product. It has two main purposes:
1) helps devs decide on important issues to work on
2) helps users plan future advancements for their own products
It is *not* an assurance of delivery dates or even schedules (at least
not in an Open Source project). However, it should at least give an
indication of the intended order of feature implementation and bug fixes.
For the last release and the next one we moved a fair number of issues
out of the next release number in order to get the release out. This is
OK for 1) (devs) but bad news for 2) (users)
One trouble is that many issues will get hidden in the
"Unscheduled" bag. I don't see how we will know what
issues have priority.
Yes, I agree. I almost started to move issues from 0.8 into the
unscheduled bag yesterday. But I stopped myself because of this very
thought. I think we can make better use of the priority field as well.
Something like:
Trivial: if this issue botthers you - then fix it because it'll take us
a while
Minor: OK so this is a recognised issue, but we don't think it affects
too may users - don't hold you breath for a fix
Major: We consider this important, it will be scheduled into a release
as soon as we find a developer with interest and time in this area
Critical: This is likely to be fixed reasonably soon, probably in one of
the next two releases
Blocker: This is an issue that affects many users or is a key new
feature, will be fixed in the next release
---
Glancing over our stats (but not the issues) we seem to have a
reasonable spread over these priorities:
Blocker 6 [2%]
Critical 12 [4%]
Major 117 [42%]
Minor 133 [48%]
Trivial 8 [3%]
---
For this to work we need a committer (any committer, I don't propose
nominating someone) to review each new issue and categorise it according
to the above. It would be a good idea to add a comment as to why it
falls into that category and a note about what it means too.
Ross
