1150757 - Can we rename a blocking flag in bugzilla? "blocking-loop" to "backlog"

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: Administration, task)

Description

[:shell escalante]

we're moving to follow how Firefox manages the backlog with a backlog flag.  sharing the firefox-backlog flag confused some Firefox team tracking (and webRTC has platform and other bugs).

Since we're not going to be using "blocking-loop" flag anymore (to get terminology the same). I wasn't sure if we could rename that one to just "backlog" with the drop down options being:
"webRTC+"
"parking lot"
"tech-debt"

Ideally the flag would be multi-select check boxes for future usage cases.  For immediate use we don't require that - but if multi-select is a configuration option rather than single select radial that would be ideal.

Comment 1

[David Lawrence [:dkl]]

(In reply to sescalante from comment #0)
> we're moving to follow how Firefox manages the backlog with a backlog flag. 
> sharing the firefox-backlog flag confused some Firefox team tracking (and
> webRTC has platform and other bugs).
> 
> Since we're not going to be using "blocking-loop" flag anymore (to get
> terminology the same). I wasn't sure if we could rename that one to just
> "backlog" with the drop down options being:
> "webRTC+"
> "parking lot"
> "tech-debt"

Are any other groups using the 'blocking-loop' flag that would be impacted by the name change?
Or are you the only one? We could definitely rename it even though any preset queries would be
broken and need to be updated (saved searches, wiki pages, etc.).

Also backlog may be to generic and not very descriptive so is there some other name that would
be better?

> Ideally the flag would be multi-select check boxes for future usage cases. 
> For immediate use we don't require that - but if multi-select is a
> configuration option rather than single select radial that would be ideal.

Unfortunately it does not support multi-select right now but it is something we would like
to add in the future. No definitely time frame on that.

dkl

Comment 2

[:shell escalante]

Hi David,

we were the only group using the "blocking-loop" flag (since we made it so specific).  We're trying to adopt more common practices across the teams.  The reasoning is we've had devs from across company boundaries come in and out of working on projects and they always need to learn a new team and process.  We also work with external factors - like QA, who are used to a certain type of triage.

We are looking to adapt the triaging practice of firefox-backlog (+/-) as that's been successful, but make it more generic so it can work across groups.  

Firefox-backlog was too specific to use for webRTC (we met with both engineering managers and EPMS). 75% of the time the work is for firefox desktop - but 25% is for FxOS, android, or iOS.  

Backlog would be a flag that we could use for webRTC+ now and hope to add other projects to later.  Using "parking lot" would mean not needing a "<teamname>-" for each team.  I'm going to be EPM'ing 2 new projects (TBD which ones) this year.  New projects would just get their name and a + added so they could be triaged the same way.  everyone could share "parking lot" - since that's the flag that says "ignore - beyond 6 months out" and isn't frequently queried.

Radial select is definitely fine for the near future (like 2015).  The reason I asked on multi-select was because we had bugs that are tracked in the Media team or Gaia and also webRTC.  It would be ideal if we can create a place where we could mark those bugs for each team tracking.  That would let us find work we're tracking across Product::component boundaries on a common field (instead of making up whiteboard tags or new flags each time).

Getting onto similar flow so it's simpler for the teams is the ultimate goal.  Not necessarily changing how teams that are working well are doing it - but as new teams/projects hit the point where they need some organization - we're trying to create and EPM template for how to get started.

I'm going to create triage guidelines nearly identical to this for webRTC, https://wiki.mozilla.org/Firefox/Iterative_Hello_Development#Triage_Guidelines.  And we took almost all that from how Firefox was doing things - and just added Rank (which works really well for 4-10 dev bug priority management).

Comment 3

[David Lawrence [:dkl]]

Ok. All done.