On Wed, Oct 5, 2016 at 12:19 PM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > I've talked about this before, but maybe the F26 cycle is time to make > it happen. Right now, we have only one way of saying "this bug is > important to the project as a whole; could we please get resources > focused on it?" — and that way is to stop the whole vehicle until > someone does something about it. This has always been kind of > problematic, even though it has served well enough so far... but as we > move to more deliverables and add things with different lifecycles, I > think we need something else. > > We have the Accepted Blockers > <https://qa.fedoraproject.org/blockerbugs/milestone/25/final/buglist> > list. The process is nicely documented at > <https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process>; please > read that if you're not familiar. > > I propose we create a parallel "Critical Issues" list, using basically > the same procedures. Issues eligible for this status would be those > which do not necessarily fail a release criterion but which have > critical impact on a Fedora Edition or on a council-approved Fedora > Objective. > > Since Fedora is a volunteer process, this can't be backed by a hard > mandate (like the "block the release!" emergency brake), but if we > agree together to take it seriously, I think it will still provide a > useful list. Anyone with a package or component involved in the issue > will be able to see the impact, and take that into account when > prioritizing. As FPL, it'd give me a nice overview of issues that might > need extra resources or coordination. > > We could either implement this by extending the existing blocker bug > process — adding a new tracker bug, add a new category in the > blockerbug app, and review candidate issues at the normal blocker > review meetings. Or, it could be done in parallel, with a > separately-configured instance of the blockerbug app and with review > in a separate meeting called as needed (or maybe just FESCo?) > > As with the existing Blocker or Freeze Exception levels, we could also > introduce a second tier "Important Issues", which could have a wider > net than the rules for "Critical Issues". I'm not sure about that. > > In any case, what do you all think? If this can be prominently included in a concise "how you can help make Fedora better" as a form of contributor recruitment, it'd probably be more enticing as well as helpful. If there were some consolidated, yet sortable list of To Do's: sortable by priority, and by expertise needed, and maybe an effort estimate, I think we'd find many small things getting more attention. It'd be easy to dive in, do something, finish it, and duck out. A way of advertising a path to getting more intermediate-expert types, rather than having to always depend on the same people for blockers and big fixes every release. Also a nice to have with this would be a Fantasy Fedora mechanism. A way to put together a virtual team and send out invites: here's something that needs work, what do you three people think of solving this problem together? -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
