Re: planning the 0.8 release

[David Crossley <cr...@apache.org>]

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

> 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
http://forrest.apache.org/issues.html
[B] FOR-roadmap-dev
http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12310820
[C] FOR-unscheduled-not-plugin
http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12310822
[D] FOR-plugins-blocker
http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12310825
[E] FOR-plugins-urgent 
http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12310824

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

-David

Re: planning the 0.8 release

[David Crossley <cr...@apache.org>]

Keeping this topic at the top of the list.
http://issues.apache.org/jira/browse/FOR-853

-David

David Crossley wrote:
> 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
> roadmap.
> 
> > 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
> http://forrest.apache.org/issues.html
> [B] FOR-roadmap-dev
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12310820
> [C] FOR-unscheduled-not-plugin
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12310822
> [D] FOR-plugins-blocker
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12310825
> [E] FOR-plugins-urgent 
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12310824
> 
> Note that some filters don't work well yet because
> we still need to classify the issues.
> 
> -David