On Wed, 2012-10-10 at 16:51 -0600, Chris Murphy wrote: > On Oct 10, 2012, at 4:36 PM, Adam Williamson wrote: > > > On Wed, 2012-10-10 at 22:08 +0000, "Jóhann B. Guðmundsson" wrote: > >> On 10/10/2012 09:45 PM, Adam Williamson wrote: > >>> I think that way we could make the meetings more efficient without > >>> running the risk of missing proposals. > >> > >> The most time in the meetings is to get people to ack/nack/patch... > > > > [citation needed] > > > > it should be easy to check that from logs, but I doubt it's really true, > > I expect the average time from propose #agreed to #agreed is pretty > > short. > > Most of the time spend is reading the bug, understanding it, and > trying to infer why it's a blocker (that is huge because most bugs > don't explicitly make the case); including time spent by reviewers > looking over the release criteria for explicit justification for > blocking. > > I agree with the idea that a blocker proposal tool is needed. The tool > would be more soliciting of blockers on the one hand by reducing > obscurity for proposing them; while also ensuring some minimum amount > of justification for the proposal in the first place. Yep, I definitely like the idea. The only problem is the classic one - development resources. Tim has about ten awesome tooling ideas, and the time to work on one :) I'd love if we got an awesome blocker bug management (web)app from the Magical Unicorn Machine tomorrow, but I suspect in the short term, the triage idea is more practical as all it requires is someone with a bugzilla login and a keyboard, not someone with the ability to bash bits of code together in the right order. -- 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