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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
