Proposed changes to blocker bug meeting processes

[Jaroslav Reznik]

----- 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 at lists.fedoraproject.org
> To unsubscribe:
> https://admin.fedoraproject.org/mailman/listinfo/test