> > 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. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
