Proposed changes to blocker bug meeting processes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux