firefox-dev mailing list
So, the one thing that firefox-backlog+ has that an unrestricted fields don't is an unambiguous signal that this bug you're picking up is something we've said is worth fixing (at some point). Otherwise it could be something mistagged by the bug filer, etc, and we risk wasting people's time that way instead.
On 12/08/2015 06:29, Mike Connor wrote:
If this is the only reason to keep it around, I bet we could make the Priority, Rank and any other fields that we'd use instead editbugs-only even for bugfilers. It'd save me time and effort when doing triage-type stuff as well.So, the one thing that firefox-backlog+ has that an unrestricted fields don't is an unambiguous signal that this bug you're picking up is something we've said is worth fixing (at some point). Otherwise it could be something mistagged by the bug filer, etc, and we risk wasting people's time that way instead.
Perhaps the backlog is the place where the upcoming quality teams will pull from as its ideally identifying important issues in all of our components. A follow-up question would be if anyone is pruning this list?
I've been thinking a lot about what it means to make a decision
about every bug, and I don't have final answers, but I do think
that we need to end up with the following categories which we can
apply to every bug in bugzilla:
Speaking for the Desktop Manual QA team at Softvision, we have this field in several of our queries, and it helps us track Sprint work that needs our attention (https://goo.gl/kRtLCx).
Here’s an example of query with and without the field… this contains the bugs that we need to monitor in the current 43.1 sprint:
- WITH the firefox-backlog+ flag – 43 bugs - https://bugzilla.mozilla.org/buglist.cgi?f1=OP&v6=firefox-backlog%2B&o2=substring&o6=substring&f4=cf_qa_whiteboard&query_format=advanced&j1=OR&f3=status_whiteboard&f2=cf_fx_iteration&f5=CP&f6=flagtypes.name&v2=43.1&list_id=12470143
- WITHOUT the firefox-backlog+ flag – 80 bugs - https://bugzilla.mozilla.org/buglist.cgi?f1=OP&o6=substring&o2=substring&f4=cf_qa_whiteboard&query_format=advanced&j1=OR&f3=status_whiteboard&f2=cf_fx_iteration&f5=CP&f6=flagtypes.name&v2=43.1
Updating the queries is easy, but if you want to remove the flag it would help if someone could clarify what those extra bugs in the second query are, and how we can filter them out.
Florin Mezei | QC Team Lead
SOFTVISION | 57 Republicii Street, 400489 Cluj-Napoca, Romania
Email: fme...@softvision.ro | Web: www.softvision.ro
The content of this communication is classified as SOFTVISION Confidential and Proprietary Information.
Thanks Marco! It sounds like we (the Desktop Manual QA team) don’t need the backlog flag anymore. As for the qe-verify flag we constantly monitor fixed bugs in the sprint that don’t have the flag set and make decisions on whether they need verification or not, so we should be good there.
I do have a plan for how bugzilla fits in with our broader quality efforts
Bug reports are the primary unit of quality assurance in software. Bug reports from our users, but especially pre-release users, are essential to building a quality product. We at Mozilla have lived so long in a world where we don't triage and make a decision about every bug report that we're numb to the pain that it's causing us. We need to make some dramatic changes in how we handle bug triage and the tracking and decision-making process around bugs.
Relative to the specific firefox-backlog bug flag, my experience has been that we don't really use it. We were supposed to pick bugs for the priority backlog from the larger list of firefox-backlog bugs. But in practice, tech leads have in their head the list of bugs they need to accomplish for particular projects, and so the backlog is mostly not looked at once things have been added to it. I don't have a stake in whether we keep it or throw it out for now, but eventually when we have a bugmaster who can spend their full attention figuring out the best way to organize bugzilla flags across multiple teams, I'm hoping we can come up with something more organized and available across multiple teams.
The query is matching iteration="43.1". IIUC, on the Firefox team, if any bug was marked as being in an iteration, it *must* have had that flag set - the flag is why it was up for consideration for the iteration. Marco can correct me if I'm wrong, but any bug with an iteration set but without that flag simply implies the flag should have been set.