== Description == While the [https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting blocker bug review meetings] are very much a necessary thing, they have a tendency to be long, tedious and not a whole lot of fun for those involved.
During the Fedora 15 retrospective, there was a request to streamline the process in order to distribute the workload and avoid more 4+ hour meetings.
Any proposals on how to reduce the length of the meetings while maintaining their utility would be much appreciated.
== Proposals == Pending discussion in comments and email
My first thought is to extend the same process that we're already using for accepted/rejected blockers and NTH. * Use a whiteboard keyword to indicate initial processing * Severity, number of users impacted, possible workarounds, criteria violation would need to be determined in order to be tagged * Once proposed blockers are tagged as "processed" they can be reviewed in the meeting. * Bugs not tagged as processed would not be reviewed.
This way, we could do more of the research ahead of time and spend less meeting time trying to answer the same questions for every new issue.
To facilitate processing, we could start with something similar to the [https://fedoraproject.org/wiki/Current_Release_Blockers current release blocker page] that is created from BZ data.
Eventually, it might be nice to have a bot go through the "unprocessed" bugs and add a comment requesting that the reporter(s) and developer(s) supply the information needed to process the bug. Something along the lines of what is already in [https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting#Requesting_Status_Before_The_Meeting the blocker bug review meeting SOP]. However, the bot part could be done later.
I like the general idea there, but it's worth keeping in the collective memory that the use of the whiteboard field was originally a bit of a lazy workaround, and we intended to replace it with keywords or flags or something more sophisticated later; we've just been too lazy to do so so far. The main drawback of using the whiteboard field is it's too easy to make a mistake in entering data into it, as it's entirely freeform. If you typo a keyword, Bugzilla refuses to accept it. If you typo a whiteboard field, it'll go through just fine...but then searches will miss it.
A smaller drawback is the whiteboard field in the web interface can get kinda overloaded and be hard to look through. It's also slightly harder to do searches on it (it's a custom field in the search form).
Yeah, I agree that the whiteboard method is not optimal but I'm not sure we could get much more hammered out and added to bugzilla in time for F16. Assuming that we start using a process like this, it would probably be good to start using flags or keywords instead of the whiteboard at some point but until we get everything streamlined, I think it would be better to wait. We could plan on that for the F17 timeframe, though.
I'm not as concerned with typos right now. In general, I'm all for reducing possible human error but I can only remember one case of a mistyped keyword causing problems for F15 and I think it would be a manageable drawback for now.
As far as the keywords to use are concerned, two forms come to mind: * !BlockerProcessed * !BlockerReady
Of the two, I think that I like !BlockerReady better since it indicates that more work needs to be done.
Another potential issue is the difference between blockers and NTH. While the process is pretty much the same for both, I can see how some human confusion could result from using a keyword with "blocker" in it for NTH bugs. I suppose that adding NTHReady might help that potential confusion but in all reality, how often are people unfamiliar with the process going to be using the keyword?
Reasonable.
Another issue: how do we ensure that this process takes place? The current process has the advantage that it's very difficult for a bug to fall through any cracks. The blocker review meetings are required to happen and required to go on for as long as it takes for every bug to be evaluated. This proposal creates a 'gap' where bugs are not evaluated at the meetings until an async step has taken place. We need to ensure we have sufficient measures in place to make sure the async step happens...
Replying to [comment:4 adamwill]:
This proposal creates a 'gap' where bugs are not evaluated at the meetings until an async step has taken place. We need to ensure we have sufficient measures in place to make sure the async step happens...
I'm thinking that the first step would be in addition to the current blocker bug meeting process. The idea is to reduce the total number of man hours spent on the review process and reduce the duration of the blocker review meetings without reducing what we already have.
By having an easier way to differentiate between meeting-ready and not meeting-ready proposed blockers, we can split the prep work up such that individual people can ask questions and identify criteria. That way we are effectively parallelizing the work and you spend ($time x 1 person) to do the initial leg work instead of ($time x 5 people) if we did it during the meeting. That way each involved person would be spending less total time on blocker review and the meetings could be shorter.
Hopefully, this would lend to more processing in BZ comments asynchronously but we would still need the review meeting to make sure that nothing was missed. Anything not prepared before the meeting would still need to be taken care of during the meeting.
The process would be in no way ideal and would rely on the same people spending the time to request information and process the blockers but it would be a step towards something better than the potential for 4 hour meetings.
I have some other ideas on how to streamline the process more but its a matter of taking the time to explore them all and learn how to interface with RHBZ.
I was just about to tinker with this a bit, and I noticed we have a rather nice section on out-of-meeting bug investigation...in the meeting SOP:
https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting#Requesting_Status_Before_The_Meeting
I'm thinking it might make for sense for that to be in the higher-level blocker process SOP - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
does that sound sensible? I think it'd make it a bit more obvious that part of evaluating bugs can happen (and indeed should happen) outside of the meetings.
Replying to [comment:6 adamwill]:
I was just about to tinker with this a bit, and I noticed we have a rather nice section on out-of-meeting bug investigation...in the meeting SOP: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting#Requesting_Status_Before_The_Meeting
That section seems to be pretty well placed in the blocker meeting SOP since it isn't as much a part of the blocker process as it is suggested methods of poking people for information. We just need to start doing that more regularly.
I'm thinking it might make for sense for that to be in the higher-level blocker process SOP - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process does that sound sensible? I think it'd make it a bit more obvious that part of evaluating bugs can happen (and indeed should happen) outside of the meetings.
I wonder if we could achieve the same effect by going a little more step-by-step with the blocker process. Right now, that page is a wall of text - if we added step by step instructions on requesting blocker process, we might get better results.
I'm thinking something along the lines of 1. Identify the release criterion violated by the bug 1. Modify the bug as follows * enter in the appropriate tracker bug * explain why this bug should be a blocker (quoting the release criteria, if possible)
yeah, I had the same feeling going back and looking at it: it sure does have that 'wall of text' feeling. I'll take a look at breaking it down into bullet points.
However, I'm not convinced the section discussed above belongs in the meeting SOP. The meeting SOP is supposed to be about carrying out the meeting, not about other tasks we might do to review blocker bugs. The blocker bug SOP just seems like the right place to put a task that's part of reviewing blocker bugs but is not part of the blocker bug review meetings, to me.
to get the 'best of both worlds' we could make it part of the blocker SOP and link to it from the meeting SOP.
Replying to [comment:8 adamwill]:
I guess the question becomes "is poking people part of the meeting process?". I thought of it as part of the meeting prep but I don't really have strong feelings about it. If we want to detach the two parts, either putting it into the blocker SOP or creating a blocker review SOP would make more sense.
Either way, I like the idea of linking to the review information from the meeting SOP.
I guess I figured if it's thought of as part of the blocker meeting process, then it's sort of implied to be the responsibility of a single person - whoever's organizing the meeting - and it's just a sort of single-shot meeting precursor. if we move it out to the blocker SOP, we can make it more of a multi-person ongoing process, independent of the meetings, which is what you want to speed things up, right?
tim: do you think it's worth keeping this ticket open, or did we already explore all the ideas? I think we did keep the meetings somewhat shorter in 16 cycle than 15.
We have made various efforts at doing this over the years; as well as those discussed above, in the current cycle we started doing the meetings earlier and are reviewing all proposed blockers (for all milestones) at each meeting, so we don't wind up with a huge backlog of proposed Final blockers to review later in the cycle.
I think this is a bit too general of a ticket to keep open any longer, so let's say we 'fixed' it, and we can open new tickets for specific new proposals if we want to.
Login to comment on this ticket.