Re: Proposed changes to blocker bug meeting processes
----- 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_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.
+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(a)lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test