<div dir="ltr">Hi Florin,<div><br></div><div>Yes, we previously used the flag to separate work that was important for the whole Desktop team from those that were not. Now we are in a multi-team situation where whiteboard tags are primarily, but not exclusively, used to identify and separate areas of responsibility. For example, the Privacy Team uses [fxprivacy] and the Partner Search Team uses [fxsearch]. Combined with this we continue to use the Iteration flag to identify which bugs are being worked on in any particular iteration.</div><div><br></div><div>Regarding QA, we continue to use 'qe‑verify' flag to mark those bugs which do (+), or do not (-), require verification. Without the 'firefox-backlog' flag you can still search for bugs tagged for an iteration and if they are marked for verification. The issue that could arise if someone forgets to set the 'qe‑verify' flag.</div><div><br></div><div>Thanks.</div><div><br></div><div>Marco<br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 13, 2015 at 8:37 AM, Florin Mezei <span dir="ltr"><<a href="mailto:florin.mezei@softvisioninc.eu" target="_blank">florin.mezei@softvisioninc.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If those bugs are just missing the flag, then indeed we can do without it. I<br>
think a while back the flag was used to separate the work in Marco's team<br>
from other teams that used the same iteration flag (e.g. 43.1), but were of<br>
no interest to us. If that's no longer the case then I have no problem<br>
dropping the backlog flag. Let's see if Marco can clarify this for us.<br>
<br>
Regards,<br>
Florin.<br>
<br>
-----Original Message-----<br>
From: Mark Hammond [mailto:<a href="mailto:skippy.hammond@gmail.com">skippy.hammond@gmail.com</a>]<br>
Sent: Thursday, August 13, 2015 12:16 PM<br>
To: Florin Mezei; 'Shell Escalante'; 'Dave Townsend'<br>
Cc: 'Mooney, Sheila'; 'Jenn Chaulk'; 'Marco Mucci'; 'firefox-dev'; 'Larissa<br>
Shapiro'; 'Wong, Edwin'; 'Justin Dolske'<br>
Subject: Re: Is firefox-backlog+ still useful?<br>
<br>
On 13/08/2015 6:17 PM, Florin Mezei wrote:<br>
> Hello everyone,<br>
><br>
> Speaking for the Desktop Manual QA team at Softvision, we have this<br>
> field in several of our queries, and it helps us track Sprint work<br>
> that needs our attention (<a href="https://goo.gl/kRtLCx" rel="noreferrer" target="_blank">https://goo.gl/kRtLCx</a>).<br>
><br>
> Here's an example of query with and without the field. this contains<br>
> the bugs that we need to monitor in the current 43.1 sprint:<br>
><br>
> - WITH the firefox-backlog+ flag - 43 bugs -<br>
> <a href="https://bugzilla.mozilla.org/buglist.cgi?f1=OP&v6=firefox-backlog%2B&o" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/buglist.cgi?f1=OP&v6=firefox-backlog%2B&o</a><br>
> 2=substring&o6=substring&f4=cf_qa_whiteboard&query_format=advanced&j1=<br>
> OR&f3=status_whiteboard&f2=cf_fx_iteration&f5=CP&f6=<a href="http://flagtypes.name" rel="noreferrer" target="_blank">flagtypes.name</a>&v2=<br>
> 43.1&list_id=12470143<br>
><br>
> - WITHOUT the firefox-backlog+ flag - 80 bugs -<br>
> <a href="https://bugzilla.mozilla.org/buglist.cgi?f1=OP&o6=substring&o2=substri" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/buglist.cgi?f1=OP&o6=substring&o2=substri</a><br>
> ng&f4=cf_qa_whiteboard&query_format=advanced&j1=OR&f3=status_whiteboar<br>
> d&f2=cf_fx_iteration&f5=CP&f6=<a href="http://flagtypes.name" rel="noreferrer" target="_blank">flagtypes.name</a>&v2=43.1<br>
<br>
At face value, these just seem to be bugs that haven't had that flag set. I<br>
know that's somewhat obvious, but I can't see any reason these bugs are less<br>
"worthy" of QA simply because they lack the flag.<br>
<br>
The query is matching iteration="43.1". IIUC, on the Firefox team, if any<br>
bug was marked as being in an iteration, it *must* have had that flag set -<br>
the flag is why it was up for consideration for the iteration. Marco can<br>
correct me if I'm wrong, but any bug with an iteration set but without that<br>
flag simply implies the flag should have been set.<br>
<br>
I don't believe anyone sets that flag with the intent being "this is a good<br>
QA candidate" - which is one of the reasons I'd like to see it die<br>
- the signals it sends to people are often wrong.<br>
<br>
I suspect that for your purposes, it might be best to work with individual<br>
program managers (so, eg, you might end up with slightly different queries<br>
per bugzilla component). For example, based on what Shell indicated, the<br>
"Rank" field might be the best indicator for the stuff she manages,<br>
especially if that also allows you to sort by relative importance. Other<br>
teams will do things slightly differently.<br>
<br>
Marco does an excellent job of managing the qa-verify? flag, which is<br>
another great indicator and probably extremely useful for you (but not in<br>
your search). But we'd need to arrange for that flag to be trustworthy (eg,<br>
you could needinfo the bug assignee if that flag isn't set for a bug that<br>
otherwise matches your criteria?)<br>
<br>
Cheers,<br>
<br>
Mark<br>
<br>
><br>
> Updating the queries is easy, but if you want to remove the flag it<br>
> would help if someone could clarify what those extra bugs in the<br>
> second query are, and how we can filter them out.<br>
><br>
> Regards,<br>
><br>
> Florin.<br>
><br>
> *Florin Mezei*| QC Team Lead<br>
><br>
> *SOFTVISION*| 57 Republicii Street, 400489 Cluj-Napoca, Romania<br>
> *Email: *<a href="mailto:fmezei@softvision.ro">fmezei@softvision.ro</a> <mailto:<a href="mailto:fmezei@softvision.ro">fmezei@softvision.ro</a>> | *Web:<br>
> *<a href="http://www.softvision.ro" rel="noreferrer" target="_blank">www.softvision.ro</a> <<a href="http://www.softvision.ro/" rel="noreferrer" target="_blank">http://www.softvision.ro/</a>><br>
><br>
> The content of this communication is classified as SOFTVISION<br>
> Confidential and Proprietary Information.<br>
><br>
> *From:*firefox-dev [mailto:<a href="mailto:firefox-dev-bounces@mozilla.org">firefox-dev-bounces@mozilla.org</a>] *On Behalf<br>
> Of *Shell Escalante<br>
> *Sent:* Wednesday, August 12, 2015 11:37 PM<br>
> *To:* Dave Townsend<br>
> *Cc:* Mooney, Sheila; Jenn Chaulk; Marco Mucci; firefox-dev; Larissa<br>
> Shapiro; Wong, Edwin; Justin Dolske<br>
> *Subject:* Re: Is firefox-backlog+ still useful?<br>
><br>
> Sebastian has a good point about having some clarity into what teams<br>
> are doing and visibility to contributors (even if it's just teams<br>
> documenting their method). I will ask EPM's . There are engineering<br>
> managers are on this list, who might know people who are working on<br>
> bugs outside of smaller teams and could ask them how they are managing.<br>
><br>
> please do not deprecate the flag without a plan. If everyone can live<br>
> without, then we make a change - but we want a chance for folks to do<br>
> any mark-up to not lose info if needed. I don't see any reason why<br>
> individual teams can't stop using sooner, if it is not adding value to<br>
> their workload.<br>
><br>
> several teams use the firefox-backlog flag to show triaged and<br>
> prioritized bugs versus untriaged bugs - but there might be simpler<br>
> options. I also think QA might have it in a few of their queries.<br>
> I'll check if they need it and what it does for them.<br>
><br>
> my teams also set Rank, which we could use instead to know our triaged<br>
> bugs. I would love to stop using firefox-backlog - after discussing<br>
> with teams for OK. we'd only need time for a bit of clean-up for edge<br>
> cases.<br>
><br>
> I can't use Priority to mark triaged versus untriaged bugs. Priority<br>
> has been set on many bugs and not all following the firefox<br>
> prioritization - and if it was set long ago i'd like to revisit.<br>
><br>
><br>
> Cheers,<br>
> Shell<br>
><br>
> Program Manager | webRTC & Hello<br>
><br>
> IRC: Shell<br>
><br>
> On Tue, Aug 11, 2015 at 10:13 PM, Dave Townsend <<a href="mailto:dtownsend@mozilla.com">dtownsend@mozilla.com</a><br>
> <mailto:<a href="mailto:dtownsend@mozilla.com">dtownsend@mozilla.com</a>>> wrote:<br>
><br>
> I'm fine with the plan but I'm pretty wary that none of the program<br>
> managers have said anything, and they're the ones that make use of<br>
> the flag the most. So I've copied some of them in to make sure<br>
> they've seen this thread and Justin's proposal to stop using the<br>
> firefox-backlog flag.<br>
><br>
> On Tue, Aug 11, 2015 at 9:41 PM, Justin Dolske <<a href="mailto:dolske@mozilla.com">dolske@mozilla.com</a><br>
> <mailto:<a href="mailto:dolske@mozilla.com">dolske@mozilla.com</a>>> wrote:<br>
><br>
> I also don't think this flag is useful.<br>
><br>
> The basic problem is that Firefox is a huge, complicated piece<br>
> of software and the set of people working on it (staff +<br>
> volunteers) is tiny. The flag was intended as a mechanism to<br>
> help track relevant bugs that we're not currently working on,<br>
> but I think we just ended up with (1) varying criteria for what<br>
> bugs should be marked backlog+ (2) a smaller but still unwieldy<br>
> set of of bugs and (3) some people simply stopping usage of it<br>
> because it's effectiveness was unclear.<br>
><br>
> AFAIK the backlog+ list has never been triaged or prioritized.<br>
> Nor is it clear to me that would actually be an effective use of<br>
> time -- it would be spending a lot of time to maintain a<br>
> wishlist of bugs that will mostly not be worked on. And<br>
> priorities quickly become stale as the browser market evolves.<br>
><br>
> So, to make this thread a bit more actionable: I propose that<br>
> that we go ahead and deprecate this flag. As a first step we can<br>
> freeze the existing set of bugs with it set, and remove the<br>
> ability to set/request it on further bugs. Projects areas can<br>
> track their own project-specific backlogs with priorities,<br>
> whiteboard tags, metabugs, spreadsheets, etc. If you have a<br>
> demonstrably useful need for the flag, speak now or forever hold<br>
> your peace. :)<br>
><br>
> Justin<br>
><br>
> On Mon, Aug 3, 2015 at 10:53 AM, Christopher Karlof<br>
> <<a href="mailto:ckarlof@mozilla.com">ckarlof@mozilla.com</a> <mailto:<a href="mailto:ckarlof@mozilla.com">ckarlof@mozilla.com</a>>> wrote:<br>
><br>
> Now that my role has become more of, as my wife says, "one<br>
> of those people that flips a lot bugzilla flags", I'm guilty<br>
> as charged.<br>
><br>
> I largely adopted it because it was trying to adopt the<br>
> larger convention, but I agree that filtering searches to<br>
> P1-Px for a backlog would work equally well of me.<br>
><br>
> A quick test of that would require me to<br>
> triage/de-prioritize an additional legacy 100 bugs to get<br>
> back to the curated backlog I created with firefox-backlog,<br>
> but that's the cost of doing business.<br>
><br>
> I don't have a lot of context around the original intention<br>
> of the flag, and am happy to learn any new spells.<br>
><br>
> -chris<br>
><br>
> On Mon, Aug 3, 2015 at 12:35 AM, Sebastian Zartner<br>
> <<a href="mailto:sebastianzartner@gmail.com">sebastianzartner@gmail.com</a><br>
> <mailto:<a href="mailto:sebastianzartner@gmail.com">sebastianzartner@gmail.com</a>>> wrote:<br>
><br>
> As far as I understand firefox-backlog it is for issues<br>
> that are lying around for long and need<br>
> prioritization.[1] So it sounds like it fulfills a<br>
> different purpose than P1 to P5.<br>
><br>
> The question is whether this flag is still used as Gavin<br>
> imagined it to work, i.e. if there's still some backlog<br>
> management as described in the wiki[2].<br>
><br>
><br>
> I guess it needs to be clarified how the process of<br>
> prioritizing bugs works and there need to people tasked<br>
> to do this priorization and keep track of it for all<br>
> bugs, e.g. the module owners.<br>
><br>
> My opinion is that the firefox-backlog flag would not be<br>
> needed if P1, P2, etc. were set consistently and always<br>
> be considered. E.g. at the moment there are a lot of old<br>
> bugs having P1.[3]<br>
> Also, prioritization needs to be based on many factors<br>
> like security, number of affected people, severity,<br>
> votes, other implementations, specifications, etc.<br>
><br>
> Sebastian<br>
><br>
><br>
> [1]<br>
><br>
<a href="https://mail.mozilla.org/pipermail/firefox-dev/2014-April/001551.html" rel="noreferrer" target="_blank">https://mail.mozilla.org/pipermail/firefox-dev/2014-April/001551.html</a><br>
> [2]<br>
><br>
> <a href="https://wiki.mozilla.org/Firefox/IterativeDevelopment#Product_Backlog" rel="noreferrer" target="_blank">https://wiki.mozilla.org/Firefox/IterativeDevelopment#Product_Backlog</a><br>
><br>
> [3]<br>
><br>
<a href="https://bugzilla.mozilla.org/buglist.cgi?priority=P1&list_id=12440512&resolu" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/buglist.cgi?priority=P1&list_id=12440512&resolu</a><br>
tion=---&chfieldto=2010-12-31&query_format=advanced&chfield=[Bug%20creation]<br>
><br>
> <<a href="https://bugzilla.mozilla.org/buglist.cgi?priority=P1&list_id=12440512" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/buglist.cgi?priority=P1&list_id=12440512</a><br>
> &resolution=---&chfieldto=2010-12-31&query_format=advanced&chfield=%5b<br>
> Bug%20creation%5d><br>
><br>
> On 3 August 2015 at 04:45, Matthew N.<br>
> <<a href="mailto:MattN%2Bfirefox-dev@mozilla.com">MattN+firefox-dev@mozilla.com</a><br>
> <mailto:<a href="mailto:MattN%2Bfirefox-dev@mozilla.com">MattN+firefox-dev@mozilla.com</a>>> wrote:<br>
><br>
> I had the same reaction: the priority field overlaps<br>
> with the backlog flag.<br>
><br>
> One thing that that the backlog flag has that the<br>
> priority flag doesn't is a way to nominate a bug for<br>
> review of the priority via "firefox-backlog?". One<br>
> could argue that every bug without an assigned<br>
> priority could fall into this category but then we<br>
> would want to either regularly triage recently filed<br>
> bugs to set a priority on them or do a pass on all<br>
> existing bugs to assign a priority making it easy to<br>
> see unprioritized bugs. In general I'm not a fan of<br>
> new BMO fields or whiteboard/keyword metadata that<br>
> duplicate or overlap with existing metadata.<br>
><br>
> On a related note, I'm not a fan of fine-grained<br>
> prioritization for low priority bugs (e.g. like the<br>
> Rank field is doing). In general, it seems like<br>
> either a bug is important (represented as P1, maybe<br>
> P2) or it's not and so thinking about P4 vs. P5<br>
> doesn't seem useful as the reality is that neither<br>
> of them are going to end up in a prioritized<br>
> backlog. The only way they'll get fixed is if<br>
> someone is scratching their own itch or the priority<br>
> changes.<br>
><br>
> Another "feature" of firefox-backlog+ is that only a<br>
> limited set of users can set this state. This avoids<br>
> having to manually police people marking pet bugs as<br>
> a priority despite the views of the module<br>
> owner/peers. Maybe the existing BMO groups like<br>
> canconfirm/editbugs already cover the priority field<br>
> though (maybe not for bugs by the reporter?).<br>
><br>
> Matthew<br>
><br>
> On Sun, Aug 2, 2015 at 5:53 PM, Mark Hammond<br>
> <<a href="mailto:mhammond@mozilla.com">mhammond@mozilla.com</a> <mailto:<a href="mailto:mhammond@mozilla.com">mhammond@mozilla.com</a>>><br>
> wrote:<br>
><br>
> On 1/08/2015 9:34 AM, Christopher Karlof wrote:<br>
><br>
> I just started using the flag today to build<br>
> a Desktop Sync backlog.<br>
><br>
><br>
> I've noticed bugs being changed in this way, and<br>
> also the same set of bugs having the<br>
> "importance" field changed (ie, a number of bugs<br>
> set to P1, P2, etc).<br>
><br>
> I don't understand the use of both of these.<br>
> Can't the current Sync backlog be determined<br>
> based on the importance? What would a P1 bug<br>
> without that flag mean relative to a P5 with it?<br>
><br>
> So I agree with Matt - it became clear to me<br>
> very soon after the backlog flag was added that<br>
> the sheer number of items marked with the flag<br>
> made it useless for both filtering and<br>
> prioritization, and I expect this to continue to<br>
> be true for Sync. I don't mind continuing to<br>
> ignore it completely, but I'd prefer to just see<br>
> it die.<br>
><br>
> Mark<br>
><br>
><br>
> -chris<br>
><br>
><br>
> On Fri, Jul 31, 2015 at 2:08 PM, Matthew N.<br>
> <<a href="mailto:MattN%2Bfirefox-dev@mozilla.com">MattN+firefox-dev@mozilla.com</a><br>
> <mailto:<a href="mailto:MattN%252Bfirefox-dev@mozilla.com">MattN%2Bfirefox-dev@mozilla.com</a>><br>
> <mailto:<a href="mailto:MattN%2Bfirefox-dev@mozilla.com">MattN+firefox-dev@mozilla.com</a><br>
> <mailto:<a href="mailto:MattN%252Bfirefox-dev@mozilla.com">MattN%2Bfirefox-dev@mozilla.com</a>>>><br>
><br>
><br>
> wrote:<br>
><br>
> I just had a realization that now that<br>
> we're not using a single<br>
> backlog for all desktop work (we have<br>
> various smaller project<br>
> teams), it's not clear to me what the<br>
> purpose of the firefox-backlog<br>
> flag is. There are 1629 bugs set to<br>
> '+'[1] which seems like a lot<br>
> given that this flag was intended as a<br>
> way to mark bugs that we<br>
> would likely work on in approximately<br>
> the next 6 months. There are<br>
> bugs in there that don't seem like they<br>
> are actually things we want<br>
> to do.<br>
><br>
> I'm curious to hear how/if people are<br>
> currently using the flag and<br>
> whether anyone is actually pulling bugs<br>
> from there outside of bugs<br>
> identified for a specific project.<br>
> There are searches for good bugs<br>
> from<br>
><br>
<a href="https://wiki.mozilla.org/Firefox/IterativeDevelopment#Contribute_to_Firefox_" rel="noreferrer" target="_blank">https://wiki.mozilla.org/Firefox/IterativeDevelopment#Contribute_to_Firefox_</a><br>
Desktop<br>
> but I don't know if contributors are<br>
> using them over bugsahoy.<br>
><br>
> Perhaps the backlog is the place where<br>
> the upcoming quality teams<br>
> will pull from as its ideally<br>
> identifying important issues in all<br>
> of our components. A follow-up question<br>
> would be if anyone is<br>
> pruning this list?<br>
><br>
> Cheers,<br>
> Matthew N. (:MattN)<br>
><br>
> [1]<br>
><br>
> <a href="https://bugzilla.mozilla.org/buglist.cgi?f1=flagtypes.name&list_id=124" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/buglist.cgi?f1=flagtypes.name&list_id=124</a><br>
> 37184&o1=equals&query_format=advanced&resolution=---&v1=firefox-backlo<br>
> g%2B&order=bug_id&limit=0<br>
><br>
><br>
><br>
_______________________________________________<br>
> firefox-dev mailing list<br>
><br>
> <a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
> <mailto:<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a>><br>
> <mailto:<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
> <mailto:<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a>>><br>
><br>
> <a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
><br>
><br>
><br>
><br>
><br>
_______________________________________________<br>
> firefox-dev mailing list<br>
> <a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
> <mailto:<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a>><br>
><br>
> <a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> firefox-dev mailing list<br>
> <a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
<mailto:<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a>><br>
> <a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> firefox-dev mailing list<br>
> <a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a> <mailto:<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a>><br>
> <a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> firefox-dev mailing list<br>
> <a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a> <mailto:<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a>><br>
> <a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> firefox-dev mailing list<br>
> <a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
><br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Marco Mucci - Engineering Program Manager </div><div>Mozilla Corporation </div><div>Work: 1.416.848.3114 x 860 </div><div>Mobile: 647.717.3381 </div><div>Email: <a href="mailto:mmucci@mozilla.com" target="_blank">mmucci@mozilla.com</a></div><div>IRC: MarcoM</div><div>Skype: marco.a.mucci</div></div></div>
</div>