On Wed, 2012-10-10 at 15:35 -0600, Chris Murphy wrote: > Two suggestions for possible changes in blocker bug procedures: > > 1. I think more burden should be placed on he who proposes a bug as a blocker. > a.) what release criterion applies > b.) what workarounds are there > c.) what are the contra-arguments to blocking > > 2. The above information would be useful in scanning blocker bugs, and triaging their review. I'm not clear on the method for ordering the review, but it would probably be helpful getting non-QA participation if say, anaconda bugs were being reviewed all at once and in triaged order. > > The Wednesday scheduled blocker meeting should not, in my view, be "dicking around" with reviewers trying to infer why a bug was proposed as blocker. I'd relegate such bugs to last call or see those bumped to an unscheduled day. > > Something like that. I've always liked having a low bar to proposing blockers as it's like the justice system - it's much worse to let a single correct blocker bug go unproposed than to have one hundred incorrect blocker bugs proposed and rejected :) but obviously it'd save us time if we didn't have to do so much spadework on vague proposals at the meeting, yeah. Perhaps the way to square that circle is to have more of a concerted effort to improve the proposals *before* the meetings. This has been proposed a few times but in the end no-one's stepped up and starting doing it. It'd really just be a triage effort: go through the list of proposed blockers, and for ones where the impact of the bug is vague and/or the grounds for blocker status are neither really obvious nor provided in the bug, ask for more details. I think that way we could make the meetings more efficient without running the risk of missing proposals. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
