forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: Target version numbers in Jira
Date Sat, 19 Nov 2005 00:16:05 GMT
Ross Gardler wrote:
> 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.
> >
> >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.

Agreed. The order in which features are implemented
is also movable in Open Source.

Certainly we do need some guidelines to aspire to.

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


On the other hand, as a user i would rather have the next
release than wait.

That technique of pushing issues into the next release
might work better if we did releases more often.

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

Lets try that.

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

It should happen as soon as the issue is registered.
Whichever Forrest committer can manage to attend to it
should do so ASAP. Also when we document the above levels,
then the issue creator could start with their assessment.

Remember that Jira is configurable. We can add other
special fields. There are already some extra defined, e.g.
The development priority for fixing the Xalan issue (which may differ from the submitter's
(We can override that text definition.)
Not sure how the field is presented or used.

We can also redefine the screens to display different info.

So if there is some other categorisation needed then
we might be able to effect it.


View raw message