Using flags for blocker bug tracking

[Kamil Paral]

> > 3) create 2 flags: accepted and rejected. These could be used with
> > the
> > tracking bugs to indicate state:
> > 
> >   Proposed Alpha Blocker:
> >     blocks fXXAlphaBlocker
> >   Accepted Alpha Blocker:
> >     blocks fXXAlphaBlocker
> >     accepted+
> >   Rejected Alpha Blocker
> >     does not block fXXAlphaBlocker
> >     rejected+
> > 
> > Of course, I could just be completely misunderstanding how flags
> > work
> > but I see this as not a huge change to our current processes and
> > not a
> > huge change request to the bugzilla devs.
> 
> Sure, let's call that 3). This is essentially using flags to replace
> the
> Whiteboard field, but continuing to use tracker bugs: it's a much
> more
> moderate option. 1) and 2) entirely replace the current use of both
> tracker bugs and the whiteboard field.
> 
> I'm not sure it would make sense to use two 'accepted' and 'rejected'
> flags in this way, it seems more sensible to me just to have a flag
> 'blocker' for blockers and 'freezeexception' for freeze exceptions,
> and
> set that flag's state depending on the decision made in the meeting.
> Flags aren't required to go ? before they go + or -. We could just
> consider bugs blocking the trackers but with no flag status as
> 'proposed', much like at present, then use the flag status to
> indicate
> acceptance or rejection, again much as we do with the WB.
> 
> To me this is very similar to using keywords instead of the WB,
> really -
> it has the same advantages and disadvantages compared to the WB
> field,
> which is that it's somewhat more programmatic so it eliminates the
> possibility of data entry errors, and it may be slightly more
> prominent
> and hence obvious than use of the WB field, but it requires us to ask
> the RH BZ team to do something for us. Either this or the keyword
> approach might be worth trying to get done for F19, though, since we
> seem to have a somewhat more responsive BZ maintenance team ATM, and
> neither change requires anything *ongoing* from them.

I would rather give a try to approach 2) than 3). I see it as more obvious, more discoverable. A lot of people are confused when seeing Blocks:F18Blocker, they don't know there are additional metadata in the Whiteboard/Flags.

Using a single place (Flags) with quite intuitive meaning (f18-alpha-blocker:? / f18-alpha-blocker:+ / f18-alpha-blocker:-, plus there can be an extensive tooltip on that field) seems better to me.