Talk:Bug management/How to triage

Previous page history was archived for backup purposes at Talk:Bug management/How to triage/LQT Archive 1 on 2015-07-10.

We have discussed bits of this here and there but hopefully now we can have a consistent decision:

We accumulate hundreds of open bugs and enhancement requests under the Extensions product, and many of those fall under extensions that are explicitly archived or no longer maintained.

I believe it is OK and even healthy to take all the open reports in an abandoned extension and assign WONTFIX (if the project is explicitly abandoned but their maintainers) or Lowest priority in case of doubt.

This way we can keep our focus on the areas that really need cleaning and have active contributors directly benefiting from our triaging work.

This post was posted by Qgil-WMF, but signed as Qgil.

There are also extensions in need of a new maintainer . We could probably lower the priority of those reports.

Extension:LogEntry has 3 open issues and it seems it hasn't been touched since 2008. I changed the priority of the 3 to Lowest.

This post was posted by Qgil-WMF, but signed as Qgil.

Is it ok for bug triagers to WONTFIX reports? It's not covered in the guide.

For instance, there is an old enhancement request that nobody has been addressing and it is clear nobody has currently plans to address. Is it ok to WONTFIX it?

This post was posted by Qgil-WMF, but signed as Qgil.

No.

MediaWiki serves many masters. Among them is the Wikimedia Foundation. Also among them is a large number of third-party users. Bugzilla covers both groups (and others).

Legitimate bug reports must stay open. They can be marked as enhancement requests as necessary.

The topic was a little bit covered in http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064357.html and followups.

Ok, then the right thing is to mark as Lowest those requests that are not incorrect but (to be best of our knowledge) nobody is planning to work on. Understood and thank you.

This post was posted by Qgil-WMF, but signed as Qgil.

In general I've learned in the MediaWiki community to use WONTFIX way less often (I set WONTFIX more often when I started working in Wikimedia Bugzilla). *If* you can argument that a request is rather "esoteric" and won't be helpful for 99.9% people and will just clutter the interface with another option, personally it would sound close enough for setting WONTFIX, or I might move it to "MediaWiki extensions > Extension requests" with lowest prio.

Here are a couple of examples of reports I WONTFIXed, in case it helps. Both of these reports I triaged during a bug day, and I got input from IRC on the proper resolution.

bugzilla:12221 "Without tidy: wrongly closed table cell messes up display completely"

bugzilla:30097 "output of {{#nowiki}} differs from <nowiki>"

Both look like perfectly fine cases for WONTFIX and I would have done the same. :)

For the past couple of years we've been using "ASSIGNED" in Bugzilla to mean "the team has accepted that this bug should be worked on by someone at some point", and default component assignees of the team experts in each area. However, this is unsatisfying for a number of reasons, most notably that it makes it really confusing for an outside to tell if something really is being worked on, or is just accidentally cookie-licked. Another big issue is that VE developers can't quickly see what they're meant to be working on from within Bugzilla, because they'll have dozens of hundreds of bugs "ASSIGNED" to them (so we have worklists outside of Bugzilla, which isn't as transparent as I'd like).

Some options come to mind:

1. Keep the status quo ante.
   • Simplest, but not good.
2. Stop marking bugs as accepted, and just let them rot on the vine.
   • If every time someone wants to work on a bug they have to have a search through the bug's history to work out whether it's been "blessed" as in the right direction for the product, this isn't really very useful.
3. Mark bugs as accepted with rôle account called something like "VE team bugs – take if you're interested!".
   • Easy to do, but might be a bit messy? (Also changing the assignee on 900 bugs will be a bit frothy, but we can quiet the IRC bot at least).
4. Add a status to Bugzilla between "NEW" and "ASSIGNED" for "ACCEPTED" (or "BACKLOG" or whatever).
   • Most teams probably won't use this, but it might be useful.

What do people think would be best?

Personally I don't like that a bug that nobody works on should be called "ASSIGNED" (maybe also because the "ASSIGNED" status was renamed to "IN_PROGRESS" in upstream in the meantime) but different teams have different workflows so I don't want to challenge this. :) For avoiding cookie-licking I prefer #3. I'm not a fan of default human/individual assignees for bug reports when that human assignee does not plan to work on the specific ticket, plus you cannot differentiate anymore which bugs you yourself *really* plan to work on. I assume that's why the default "Nobody" assignee was introduced at some point, which is more or less already #3.

OK, will do option 3 then.