Apologies ... I should have started out with a "Thank you" for
initiating this thread and sharing your ideas.
On Tue, 2010-05-18 at 10:37 -0700, Jesse Keating wrote:
> 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.
Agreed. I'm just sharing my experiences going through this same
workflow definition where it took many releases to flesh out. So I'm
hopeful it could be defined and documented in a 2 month span, I'm just
not optimistic.
Just so you don't think I'm Mr. Gloom'n'Doom, I'm not rooting against
success here. I'm just trying to be realistic and hopeful we can avoid
maintaining+executing a half-implemented process that doesn't meet the
stated definition of success.
Maybe the next step is spelling out the proposed changes on the wiki?
> 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
> (:
No objections with your stated objective, I agree and share some of that
goal. We have made some great strides in adding transparency to the
blocker meetings and doing our best to apply the release criteria in an
objective and consistent manner. As intended, doing so has correctly
highlight some of these rough spots in the process. This seems like a
natural flow along those lines, and qualifies as "good" problems to
have :)
How do the following goals sound?
1. Document blocker bug escalation procedures
A. I think this is a no brainer, but we'll need the process
documented in SOP form on the wiki
B. Do we still need to distinguish between "MUST HAVE" and
"NICE TO HAVE" (which I have been treating F13Blocker
and F13Target as, respectively)
2. Reduce meeting time spent reviewing proposed blocker bugs
3. Increase asynchronous/out_of_meeting blocker bug approval
Anything else?
Thanks,
James
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
