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
