On Wed, Oct 5, 2016 at 3:16 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > 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 The issue I see with that is if these are critical fixes that aren't being fixed, the likelyhood of a new contributor coming in and fixing them in a timely fashion is pretty low. What Matthew is really after is a prioritization problem for critical resources. > 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. That is completely orthogonal to what Matthew is talking about. We already have 'what can you do for Fedora' so if we need to expand that, let's start a different discussion. > 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. Where do you foresee these people coming from? Or rather, why aren't they already involved? > 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? How is that not just sending an email? josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
