Proposed changes to blocker bug meeting processes
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_mee...
https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_SOP_blocker_bug_pro...
Here are the specific separated proposals:
https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_QA_SOP_bl...
Specify a three-hour time limit on blocker review meetings
https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_QA_SOP_bl...
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_bl...
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