----- Original Message ----- > 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. +1, it really makes sense to limit the time spent on one meeting for the reasons you described > 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. Again +1, there are conflicts with the main use case for #fedora-qa, #fedora-bugzappers should die. One reason I remember people wanted to use some more known channel was people sitting there but you can always ping guys to come to this channel. > 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. +1 > Thoughts? Improvements? Thanks! As it did these moves during F18 cycle, it makes sense. Also I hope F19 won't be such beast as F18 (yeah, hope :D). With automatic blocker status for specific bug types, I think we are going the good direction! Thanks guys! Jaroslav > -- > 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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
