Blockers via flags?

[Jesse Keating]

On Tue, 2010-05-18 at 11:54 -0400, James Laska wrote:
> 
> I like the idea of having multiple flags, however am concerned that it
> is a significant documentation/training challenge.
> 
> Is there benefit in rolling this out in phases?  Part#1 would involve
> adding only a 'blocker' flag to allow for improved query and 3 blocker
> request states (requested, accepted, rejected).  Part#2 would add the
> team specific blockers (devel, releng and qa) and an automated mechanism
> to approve/reject 'blocker' requests based on these new flags. 

In my opinion, the training would be fairly light, and doing it in
phases wouldn't necessarily help here.

The biggest change is that when a user or developer considers something
to be a blocker, they set the flag to ? instead of adding the
F??{Alpha,Beta,Blocker} blocking bug.  That's going to happen even if we
do it in phases.  After that, the relatively small communities of releng
and QA need to know how to cast their vote for blocker or not via flags.
Since we're relatively small, it should be easy to train us.  The
maintainer or bug owner themselves will also have to confirm it's a
blocker in their opinion, I suppose that's the second biggest change.
The final biggest item would be using the right query to discover the
current list of approved blockers, and that would have to happen in the
first phase as well.

Doing it in phases removes one of the biggest advantages to me, the ease
of doing this work in an asynchronous mode.  My goal is to reduce the
amount of time we spend in those meetings, and to increase clarity for
maintainers and testers as to which bugs are actually blockers.  A 50%
reduction in goals in order to do it in phases doesn't sit well with me
(:

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100518/662bd78b/attachment-0001.bin