forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Target version numbers in Jira
Date Thu, 17 Nov 2005 08:22:49 GMT
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.


>>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.
> 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.


View raw message