We discussed a few possible changes to the blocker bug meeting process at the QA meeting this week. It was agreed that I'd draft up these changes for list discussion. So here they are! Sent to test@ and devel@ as QA, devel and releng are the stakeholders in this process: I'm figuring releng folks are all subscribed to one list or the other. https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_SOP_blocker_bug_meeting https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_SOP_blocker_bug_process Here are the specific separated proposals: https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_QA_SOP_blocker_bug_meeting&diff=324139&oldid=324138 Specify a three-hour time limit on blocker review meetings https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_QA_SOP_blocker_bug_meeting&diff=324140&oldid=324139 Use a dedicated channel (#fedora-blocker-review) for blocker review meetings instead of #fedora-bugzappers https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_QA_SOP_blocker_bug_process&diff=324143&oldid=324142 Specify that blocker review should not happen in QA meetings The first change is pretty non-controversial; we started putting a three-hour cap on review meetings during F18 and carrying over to the next day, and that seemed to work much better than meetings that dragged on for six hours where just a couple of people were left at the end. The second was suggested by Johann, and I support it. Using #fedora-bugzappers for the meetings is kind of a hack - we just used the channel as we had it lying around and nothing was happening there any more. We tried running the meetings in #fedora-qa for a while, but it didn't work well, as people often want to discuss other stuff there while meetings are happening (especially in the case of long meetings). We can't use #fedora-meeting because we tend to run far too long; for the same reason we can't absolutely rely on meeting-1, meeting-2 etc being available). So a dedicated channel seems like a sensible option. It doesn't really result in 'channel proliferation' because after the change, #fedora-bugzappers won't really be used for anything, so we could all drop that one. The third was another thing we did in F18 that seemed to work well; doing blocker review _during_ QA meetings was something I was always a bit unhappy with (as it's a bit hard for people to know about or find logs of after the fact if they don't know about it), and simply beginning an actual blocker review meeting right after the QA meeting seemed to work fine. We could actually announce it ahead of time that way too; we usually know ahead of time when we're going to be doing it. Thoughts? Improvements? Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
