Closed Bug 1445054 Opened 3 years ago Closed 2 years ago

Create INACTIVE as a new bug resolution

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: emceeaich, Assigned: emceeaich)

References

Details

User Story

We have a lot of open bugs.

We have found, searching for open bugs unmodified for more than one year around 90K bugs.

Some of these old bugs are still valid. So we won’t close these old bugs, but we want to get these old bugs resolved in a way that we don’t lose focus on current bugs. 

We’re marking these as RESOLVED INACTIVE. 

That means they aren’t closed, but have not been looked at, and should be reviewed to see if any are still valid. 

If a bug is still valid, and we do plan to work on it, then we will move it back to status NEW.

I don’t expect these to be reviewed by hand but by heuristics, statistical analysis, and machine learning.

Here’s a breakdown of the open, unresolved bugs by STATUS and Priority:


[Report broken down by Product, Status, and Priority](https://bugzilla.mozilla.org/report.cgi?x_axis_field=priority&y_axis_field=bug_status&z_axis_field=product&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&product=Core&product=External+Software+Affecting+Firefox&product=Firefox&product=Firefox+for+Android&product=Firefox+for+iOS&product=NSPR&product=NSS&product=Toolkit&resolution=---&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&emailtype1=substring&email1=&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=&j_top=AND&f1=days_elapsed&o1=greaterthan&v1=365&f2=noop&o2=noop&v2=&f3=noop&o3=noop&v3=&f4=noop&o4=noop&v4=&f5=noop&o5=noop&v5=&f6=noop&o6=noop&v6=&f7=noop&o7=noop&v7=&f8=noop&o8=noop&v8=&f9=noop&o9=noop&v9=&f10=noop&o10=noop&v10=&f11=noop&o11=noop&v11=&format=table&action=wrap)

Attachments

(1 file)

Screenshot-2018-3-16 Report Product Status Priority.png
70.53 KB, image/png
Details 
We have a large number of bugs still open without activity. 

We need to get these inactive bugs out of our 'head space' so we better understand the active set of bugs. 

But we don't want to close them, since they were reported as valid bugs. 

If we resolve these as INACTIVE they will get out of search results. 

I propose creating this status and a set of rules for moving bugs into and out of this status.

I'll use the user-story field on this bug for the rules on this.
+1, thought maybe some more care into the name -- c.f. how much emotional weight is on WONTFIX, I'd like something that triggers more neutral to positive emotions.
Personally I'd like to see the LATER resolution as well, which was there on BMO before IIRC.
Let's create this flag in bugzilla-dev today, and then see if it breaks anything.
Assignee: nobody → ehumphries
Summary: [meta] Create INACTIVE as a new bug resolution → Create INACTIVE as a new bug resolution
See Also: → 1445052
Would it be better to have this as bug status?
Flags: needinfo?(ehumphries)
Both this INACTIVE and MOVED are enabled on bugzilla-dev.allizom.org;

dkl: Can you double-check that phabricator doesn't care?
decoder: Can you confirm that this doesn't break your automation?
Flags: needinfo?(dkl)
Flags: needinfo?(choller)
No, we want this as a resolution to get bugs out of people's headspace. If they are still important, they can ask-to/or REOPEN.
Flags: needinfo?(ehumphries)
(In reply to Dylan Hardison [:dylan] (he/him) from comment #6)
> Both this INACTIVE and MOVED are enabled on bugzilla-dev.allizom.org;
> 
> dkl: Can you double-check that phabricator doesn't care?

Phabricator integration, at this point in time, does not rely on bug statuses and the push connector only looks for changes in bug roles and group security.

dkl
Flags: needinfo?(dkl)
Thanks for keeping us in the loop. I think this shouldn't affect any of our automation.
Flags: needinfo?(choller)
Suggestion:
How about creating INACTIVE status, instead of INACTIVE resolution.
As now inactive bug will look as RESOLVED INACTIVE with shown both status and resolution,
which this bug is not resolved by any means (but will look like one), it is just inactive for now,
so INACTIVE as status will be better connotation here, than RESOLVED INACTIVE,
in my opinion of course.
Flags: needinfo?(ehumphries)
If we did that we'd need to change search defaults so that quicksearch and advanced search defaults excluded status INACTIVE and RESOLVED.

Making INACTIVE a resolution means we don't need have to change search, and I'd like people to take an action to REOPEN an INACTIVE bug.
Flags: needinfo?(ehumphries)
Flags: needinfo?(dylan)
Flags: needinfo?(dkl)
Flags: needinfo?(Virtual)
I clicked "SAVE" too soon and forgot to ask :Dylan and :dkl how difficult would it be to modify default search behavior.
I also suspect that making INACTIVE as resolution will increase amount of duplicates.
Making INACTIVE a status would need quite a bit of code change for more than search as a lot of BMO code treat RESOLVED as the bug being closed where INACTIVE would also sort of mean closed as well. Making it a resolution would not need as much work from a code standpoint. The default search for advanced query page just looks for bugs with resolution=--- which means 'no resolution' so that would work. Dashboards would need to make sure not to include INACTIVE resolution bugs in their metrics as it would look like a successful closing which it is not. Metrics that only look for resolution=FIXED would be unaffected.

dkl
Flags: needinfo?(dkl)
From what :dkl said, I think keeping INACTIVE as a resolution makes more sense, we'll need to tell people to update their dashboards so that they don't co-mingle FIXED/VERIFIED with INACTIVE. 

It's possible that this could increase duplicates, but we already display potential duplicates when someone is filing a bug.
Flags: needinfo?(dylan)
Dylan, per our conversation, let's turn on the new status today. 

Also let's run your admin user script to move the bugs since there are so many to start with. 

The query is: 

limit=0&include_fields=id,status,priority,product,component&product=Core&product=External%20Software%20Affecting%20Firefox&product=Firefox&product=Firefox%20for%20Android&product=Firefox%20for%20iOS&product=NSPR&product=NSS&product=Toolkit&resolution=---&f1=days_elapsed&f2=priority&f3=bug_id&o1=greaterthan&o2=notequals&o3=greaterthan&v1=1y&v2=P1&v3=0

That has to be run multiple times, updating v3 with the last bug to get the whole list.
Flags: needinfo?(dylan)
"Today" being May 2nd, wfm.
Flags: needinfo?(dylan)
Interesting to note:

If I restrict to bugs filed by people with editbugs, that's 60k bugs. If I restrict to bugs filed by staff, that's 30k bugs. 

I'm wondering if we should start by resolving bugs filed by staff first?
I understand there are many year-old bugs that are no longer valid, but this is a bad idea IMO because:

* it encourages duplicates
* it encourages external users to spam a bug with "me-too" comments just for the sake of keeping a bug alive
* it potentially leaves some valid bugs in the dust (I doubt triage owners have time to reproduce all bugs in the RESOLVED INVALID list)
* yearly bug-spam is not enjoyable
* it does not make sense for feature requests/meta bugs
* mass reopening is not enjoyable (like I just dealt with various feature requests)

Instead of mass closing all bugs with the last activity a year ago, can we use more fine-grained heuristics ? Like only closing year-old bugs with Has-STR: false to RESOLVED INCOMPLETE, or stop closing bugs with the keyword "feature"/"meta" (since it does not make sense for Feature requests/meta bugs), etc.

Just mass closing everything is just extremely counter-productive.
*sigh* You can't even mass reopen bugs/mass set their status to NEW. You can only set to UNCONFIRMED :/

Also, I wanted to add another heuristic for closing bugs: do not close bugs with "enhancement" as Importance, as these are likely feature requests too.
Can we please rollback/hold this change until there's a way to mass-reopen bugs or set their status to NEW ?

This change has been closing many feature requests that I'd like to reopen.
Flags: needinfo?(ehumphries)
Flags: needinfo?(dylan)
If you are getting notifications on these closures, then there's an error. This is running from a console job that should be be sending bugspam. 

If you wish to reopen the feature requests then use this search https://mzl.la/2GK1ac8 and you can bulk edit the results.
Flags: needinfo?(ehumphries) → needinfo?(ntim.bugs)
I was using "Change several bugs" in this link: https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&emailtype1=exact&emaillongdesc1=1&email1=ntim.bugs%40gmail.com

It only provides an option for "UNCONFIRMED" and "RESOLVED".

Your other link seems to work, thanks, but I'd like to see all the bugs I've commented on.
Flags: needinfo?(ntim.bugs)
Quicksearch: "ALL commenter:ntim.bugs@gmail.com"

https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20commenter%3Antim.bugs%40gmail.com&list_id=14164051

And if you want to see all the bugs on one page (up to 100,000) use ALL+:

ALL+ commenter:ntim.bugs@gmail.com
Flags: needinfo?(dylan)
Was there some sort of public notification/discussion of this that I missed?  I'm seeing a huge number of bugs resolved that shouldn't have been.  And while it's all well and good to say "they aren’t closed", the fact is that all existing workflows assume RESOLVED == closed (in the sense that that bug will not need to be dealt with in any way).  So this is a fundamental workflow change that needs to be clearly communicated at the very least.
Flags: needinfo?(ehumphries)
Flags: needinfo?(dylan)
This change silently closed hundreds of security bugs which does not seem good.
Depends on: 1464209
Depends on: 1464226
Bugs with the leave-open keyword have been closed.  (175 of them, full list http://paste.debian.net/1026500/)
(In reply to Sylvestre Ledru [:sylvestre] from comment #27)
> Bugs with the leave-open keyword have been closed.  (175 of them, full list
> http://paste.debian.net/1026500/)

I'll run the undo script on those too.
Flags: needinfo?(dylan)
:bz, after all-hands we'll re-visit this.
Flags: needinfo?(ehumphries)

Closing this for now.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.