forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: planning the 0.8 release (Was: [RT] structurer location and resource types)
Date Wed, 29 Mar 2006 10:57:33 GMT
David Crossley wrote:
> Ross Gardler wrote:
>>David Crossley wrote:
>>>Ross Gardler wrote:
>>>>David Crossley wrote:
>>>>>The "roadmap" mixes in all of the plugins issues.
>>>>>The so-called "Priority" is a reporter-based priority.
>>>>Does it? I can't check it right now (I'm replying offline) but I'm 
>>>>pretty sure I moved all of the plugin stuff out of the roadmap for 0.8. 
>>>>The only references to plugins in there (that I intentionally left) is 
>>>>to how core handles plugins.
>>>Ah, i did not realise that you were doing that.
>>>However, as we move more stuff into plugins,
>>>what would happen when we have plugins issues
>>>that need to be fixed?
>>That's where you urgency field comes in (which wasn't available when I 
>>did the 0.8 roadmap).
> That sounds like it would work. So to assess the
> state of the upcoming release, we look at the filters
> to see Urgency=blocker and Urgency=urgent
> (whether they are marked on the roadmap or not).
> The remaining issues on the roadmap are "hope-to-fix".
> Is that how you see it too?

Pretty similar to how I see it:

I have a slight problem with the sentence "whether they are marked on 
the roadmap or not". My understanding of the urgency field was to allow 
plugins to have blockers that are not blockers to a core release. We 
therefore need to be able to keep such issues out of the roadmap, but 
keep them visible. Hence the introduction of urgency.

I see it working like this:

Priority indicates priority to that part of the project (core or plugin).

Urgency indicates the likelihood of the community fixing it (as opposed 
to the reporter).

So, a blocker for the OOo plugin may only have a low urgency if it is 
unique to a specific use case for a specific user. On the other hand, a 
low priority issue may be an indicate of a problem with the design of 
the plugin system in the core, in which case we are likely to give it a 
high urgency.

So, to establish the state of a core release, look at the 0.8-dev roadmap.

To establish the state of a plugin release look at the urgency/priority 
of issues against that plugin.

To find issues that are unscheduled, but should be in the roadmap look 
at all non-plugin issues sorted by priority/urgency.

> There were many issues in the "unscheduled" before
> you started. Speaking for myself, i don't look
> often enough at that filter.

I reviewed all issues when creating the roadmap (after discussion). That 
doesn't mean I didn't miss any, but I did my best ;-)


View raw message