Closed Bug 1153962 Opened 9 years ago Closed 9 years ago

Archive Firefox::Untriaged component

Categories

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

Product:
bugzilla.mozilla.org
Component:
Administration
Version:
Production
Type:
task
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: lmandel, Unassigned)

References

Details

The Firefox::Untriaged component seems out of place in the list of Firefox components. Firefox::General seems like the right place for these bugs. (I think it makes sense to have one catchall component vs two.) I propose that we archive the Firefox::Untriaged component and migrate all open bugs in this component into Firefox::General while setting their status to unconfirmed. (It looks like almost all of the bugs in Untriaged have their status set to unconfirmed already.)

I'll admit that I don't have the context about why the Firefox::Untriaged component was created and there may be something that I'm missing. I'd like feedback from bsmedberg or gavin before we proceed with any changes.
Flags: needinfo?(gavin.sharp)
Flags: needinfo?(benjamin)
I think I disagree with this, but I'm going to defer the details to Mike Hoye and Marcia who are working on improving the triage experience this quarter.

The situation here is that Firefox:General is considered a valid place for bugs. If there is a bug in Firefox but it doesn't fit into any other more specific component, it gets put into Firefox:General and is managed by the overall browser owner (Gavin).

Firefox:Untriaged is never a valid landing place for bugs. Having a bug in that component always indicates that a bug needs to be triaged to some other component. By default the guided bug entry form will put bugs into Untriaged so that they go through an explicit triage step.
Flags: needinfo?(benjamin)
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #1)
> The situation here is that Firefox:General is considered a valid place for
> bugs. If there is a bug in Firefox but it doesn't fit into any other more
> specific component, it gets put into Firefox:General and is managed by the
> overall browser owner (Gavin).
>
> Firefox:Untriaged is never a valid landing place for bugs. Having a bug in
> that component always indicates that a bug needs to be triaged to some other
> component. By default the guided bug entry form will put bugs into Untriaged
> so that they go through an explicit triage step.

My thinking is that a bug should always be filed into a valid component with an owner. A submitter should make a suitable guess at the component and default to General if they can't or don't want to find a more suitable one.
I haven't consulted with Marcia yet. 

- In Firefox-Untriaged There are ~1800 UNCONFIRMED bugs and ~140 NEW, which is pretty much all of them.
- In Firefox-General, there are about 2700 "NEW" and another 2200 "UNCONFIRMED" bugs. 

The difference between Fx::Untriaged and Fx::General + "UNCONFIRMED" in terms of submitters suggests that this is kind of a wash (and suggests that having editbugs-privileged submitters automatically get bugs flagged as "new" hurts than it helps.)

Toolkit:Untriaged and core:untriaged both have less than 100 bugs in them that are either new or unconfirmed.

I think that our first triage experiment be aimed at getting Firefox::untriaged down to zero, and then archiving those categories. I'll file a separate bug to reconsider the editbugs-default-behavior thing.
(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #0)
> I'll admit that I don't have the context about why the Firefox::Untriaged
> component was created and there may be something that I'm missing. I'd like
> feedback from bsmedberg or gavin before we proceed with any changes.

see bug 713163.

if this does get archived, we'll need to update the guided bug entry form to default to the general component instead of untriaged.
Blocks: 1154031
"it seems out of place" seems like an odd rationale for a change like this :)

It's useful to distinguish bugs that have not been triaged (or filed by someone who can choose a non-default component) and bugs that have. Firefox::Untriaged lets us do that. Firefox::General can't be used for that, because the list of Firefox bug components is not exhaustive, and we need a place for triaged/confirmed "General" bugs.
Flags: needinfo?(gavin.sharp)
(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #2)

> My thinking is that a bug should always be filed into a valid component with
> an owner. A submitter should make a suitable guess at the component and
> default to General if they can't or don't want to find a more suitable one.

Part of the reason for FF:Untriaged was that it's too much to ask inexperienced users even to guess. Our Bugzilla categorization is extremely confusing (in no small part because there are just a lot of areas to categorize!).

Even if mhoye is successful at reaching a 100% triage rate (godspeed, sir), I think it would still be good to have a specific Untriaged component so that people can watch actual General bugs without the deluge of incoming untriaged bugs.

However, I _do_ think that there's opportunity to have a better guided bug entry sequence for some sets of users. For example, Gijs has proposed having a form specifically for webdevs, who are generally more capable of providing technical info.
Agreed with Gavin and Benjamin. I would prefer not to remove the distinction.
The idea we're pushing is that "in the right component" is only a part of what "triaged" means. The untriaged component is a start, but there's a potentially a bunch of steps between "new bug from new contributor" and "a component owner can make an informed decision this bug's fate". 

By making that state explicit with new status keywords - unconfirmed -> in-triage -> ready, e.g. - and some whiteboard flags we can make the triage process a lot more effective in supporting engineering decision-making. There are some wins there around discoverability and tool-assisted triage as well that are hard to achieve as we stand, though I suppose keeping "untriaged" around doesn't preclude that approach.
(In reply to Mike Hoye [:mhoye] from comment #8)
> The idea we're pushing is that "in the right component" is only a part of what "triaged" means.

sure, but why can't the bug remain in the untriaged component until the bug is full triaged?  ie. make moving it into the developer's queue the last step of the process, rather than it landing there by default in an untriaged state.

> By making that state explicit with new status keywords

wait, "new status keywords"?

i'm not a fan of adding another mechanism to track a bug's status .. we have a large number of systems for which the bug's status is important (eg. dashboards), so adding keywords for that sort of stuff can potentially be a breaking change.  it's the reason why (unfortunately) we cannot add new "real" statuses to bmo.

> some whiteboard flags we can make the triage
> process a lot more effective in supporting engineering decision-making.

hrm.

do you have a document which describes all elements of this idea?
(In reply to Byron Jones ‹:glob› from comment #9)
> (In reply to Mike Hoye [:mhoye] from comment #8
> > By making that state explicit with new status keywords
> 
> wait, "new status keywords"?
> 
> i'm not a fan of adding another mechanism to track a bug's status .. we have
> a large number of systems for which the bug's status is important (eg.
> dashboards), so adding keywords for that sort of stuff can potentially be a
> breaking change.  it's the reason why (unfortunately) we cannot add new
> "real" statuses to bmo.

Indeed, if the idea is to add more keywords, this sounds like a new, overlapping way to classify bug statuses, which is confusing.  See also recent discussions in bug 1151371 and https://groups.google.com/forum/#!topic/mozilla.dev.platform/3DAYBckD2C4.  All interesting ideas, but there's no clear buy-in, and without that, processes multiply and confusion results.

I'm okay with breaking dashboards given good reason; dashboards should be reflecting processes, not dictating them.  The fear of breaking them, though, implies that there may be miscommunication as to the proposed process.  This bug started out by switching the target component for untriaged bugs, but comment 8 appears to be hinting at a larger scope, which I believe should be discussed outside of a bug and include Firefox engineering management (and preferably linked here).

Perhaps the problem is that we have no good metaprocess for amending existing development processes, such as they are.

> > some whiteboard flags we can make the triage
> > process a lot more effective in supporting engineering decision-making.
> 
> hrm.
> 
> do you have a document which describes all elements of this idea?

I second this request.  There are great ideas here; let's lay the whole proposal out somewhere.
I want to explicitly table all talk of new workflow, workflow keywords, and all that. It's not right for this bug, and it's not the right time for it. Let me find somebody who can take responsibility for the entire problem, write a coherent plan, and then implement it.
I'm working on laying this all out right now, I'll run it by you in a few hours.
It's not super clear from that doc if Firefox::Untriaged is going to be a core part of the proposed process.  From comment 1 I gather that it is part of the existing process, however, and that it will probably continue to be.  Not sure if it belongs in the Triage doc there, but regardless, sounds like this is a WONTFIX unless the proposed process is radically altered at some later point (in which case this can be reopened).  Agreed?
Somewhat agreed. If we think the utility of the ::Untriaged components can be done better by triage-process status flags, we can use clearing out those components before archiving them as as a proof of concept.

If we think they will they either still have enough residual value to keep around afterwards (or we drop this proposal) then this is a wontfix, yes.
Yes, I think at a minimum that we'd want to see effective results of the proposed process change before getting rid of Untriaged. (But I also don't see how the proposal addresses comment 1 and comment 6 -- dumping a flood of newly filed bugs into General that don't actually belong there is not acceptable).

I feel like maybe there's a bit of miscommunication here too. Is it just that the "Untriaged" name of the component is the issue? We could rename it to something like "Incoming" or "Limbo" or "I Don't Know Where To Put This" if that helps clarify its current purpose.
> Is it just that the "Untriaged" name of the component is the issue?

"Just", heh. To boil it way too far down, it amounts to "triage is not a binary state, it's a process we can improve for both dedicated engineers and community contributors."

That said: bsmedberg has set several related bugs resolved-incomplete pending a larger discussion, so I'm going to do the same to this one.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
After reading all of the comments again, I think this comes down to different views of what the untriaged and general components should and are used for. 

My model is that each Bugzilla component should map to a component in Firefox. Each component should be owned by a person or team and triaged regularly for incoming bugs (denoted somehow, for ex, with the unconfirmed state). Untriaged bugs can easily be filtered from a dev list by leaving out those bugs that are in the untriaged (unconfirmed) state.

I see the General component as a catchall for I don't have or know a better place to file a bug. (I would encourage people to guess at the component rather than just dump all new bugs into an Untriaged component.) As we discover additional components thought submissions in General, we can create them. The same logic of triaged vs untriaged applies as above.

That's my thinking. I'm not trying to dictate process in this bug just suggest an alternate way to approach what we do today. I'm fine leaving this bug in the resolved state as it is the desktop team who needs to triage their components and who are in the best place to make a call on how is best for them to do that.
You need to log in before you can comment on or make changes to this bug.