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
