Blocker Bug Voting and Conversation

[Chris Murphy]

On Dec 3, 2012, at 3:19 PM, Tim Flink <tflink at redhat.com> wrote:
> 
> 
> Affected Voters:
> - Do you vote on blocker status in bug comments?

Rarely. I agree with Kamil's comment that it makes bug reports less readable. It may also encourage conversations, turning the bug report into a giant email thread, ick.


> - Would you vote on blocker status more often if you could easily vote
>   outside of meetings?

I don't think so. On the one hand the meetings, even shortened, are quite long which is a disincentive to participation; on the other hand a specifically scheduled time makes me more likely to participate if I have the time/interest. An email thread becomes yet another pile of emails I'm inclined to ignore even if it's easier to participate.

Perhaps the solution to encourage participation by email is to limit it to controversial bugs, as suggested by Kamil.


> - Do you want to receive status updates on the bugs you vote on, even
>   if those status updates don't deal directly with blocker status?

No. Maybe 90+% of the bugs I vote on don't affect me, or minimally affect me. If I care about a bug I'm already on the bugzilla distribution for status/additional comments so I'll be notified if a change affects me.

> 
> Anyhow, helpful thoughts would be appreciated. Hopefully we can improve
> the process so that it's less painful for everyone and maybe even more
> useful (at the very least, less difficult to understand).

I think the release criteria needs to define which bugs can be determined entirely by QA to be blockers. A significant minority of bugs don't need to be voted on, when they obviously cause release criteria to not be met, for many users, and maybe another parameter or two go in there. If the bug is in that category, dink, it's a blocker and doesn't need to be voted on. I call this delegation to and trust in QA, and the process. So the process needs parameters to allow for this.


Chris Murphy