forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: planning the 0.8 release
Date Fri, 31 Mar 2006 07:21:22 GMT
Ross Gardler wrote:
> 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?

I didn't, but i was trying to put the current
discussion into words.

> Pretty similar to how I see it:
> I have a slight problem with the sentence "whether they are marked on 
> the roadmap or not".

I added that because i was previously under
the impression that the plugin issues are on
the roadmap too.

> 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 had seen it as applying to all issues.
After lots of thought in the last few days
i tend to like your suggested method.

So i suppose that Urgency only applies to plugin issues.
It is a duplication of information and effort to apply
it to the general issues, since we would not use it there.

Actually i wonder if your techinique of leaving
plugin issues out of the roadmap removes the need
for the Urgency field. Could filters [D] and [E]
use the Priority field instead?

> I see it working like this:
> Priority indicates priority to that part of the project (core or plugin).

Currently we say that Priority is the "severity" from
the reporter/user point-of-view, i.e. how it affects them. [A]
I will change the docs and Jira prompts

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

Yes, community. I don't think that the reporter
matters in this case.

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

I had trouble coming up with good examples.
Your second example would probably result in
creating a new core Issue about fixing the
plugin system.

Again i am wondering if the Urgency field is
worth the effort with the new way of managing the

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

Made a filter for that: [B] FOR-roadmap-dev

While we are here, lets figure out how to progress
to a release. How is this:

* Each of us visit [C] and add any more core issues
that we would realistically like to have fixed onto
the roadmap [B].

* The roadmap is going to be too big (already 40).
So we review it and move some issues over to Fix-for=0.9
i.e. put them on the next roadmap rather than send
them back to the unscheduled basket. Also jiggle some
Priority values. Need some discussion on each issue.

* Focus on the remaining issues.

* Repeat that process or carefully watch new issues.
Only put them on 0.8 roadmap if really necessary.

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

Yes. Also made two filters to show such issues
for all plugins:
[D] FOR-plugins-blocker
[E] FOR-plugins-urgent

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

Made a filter for that: [C] FOR-unscheduled-not-plugin

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

[A] Forrest issue tracker description
[B] FOR-roadmap-dev
[C] FOR-unscheduled-not-plugin
[D] FOR-plugins-blocker
[E] FOR-plugins-urgent

Note that some filters don't work well yet because
we still need to classify the issues.


View raw message