In last week's triage meeting we tended to surface really, really old bugs that only surface under edge or corner cases.
For example, I now am assigned bug #93 which deals with how ~~~~ behaves inside <nowiki>. This is the paradigmatic example of a corner case. This isn't preventing anyone from getting their work done in MediaWiki, unless they happened to be compiling a wiki of ASCII art. I took the bug just to learn more about the parser, really.
Maybe the Bugmeister role is still being defined, but I think it would be most helpful if we used these sessions to catch bugs that were important, but for one reason or another fell through the cracks.
Some suggested heuristics (not rules!!):
- older than 1 month -- so we know it may have fallen off the radar
- not older than 4 years -- so it hasn't been proven not to be that important
- should be considered in rewrites already planned -- goal should be to turn them into test cases
- seem to affect lots of pages / users / use cases
- seem to affect less common use cases but in a severe way
My example of a great bug to consider: there's a bug / misdesign with Resource Loader that makes it hard to use RTL languages on international sites like Commons. This was actively debated a few months ago but ended in a compromise that didn't work well for Commons. (https://bugzilla.wikimedia.org/show_bug.cgi?id=6100)
On 4/13/11 7:07 AM, Mark A. Hershberger wrote:
This coming week, I'd like to focus on any User Interface bugs. One of the lessons I learned from this last triage, though, is that we want to keep the bug reports current. With the introduction of ResourceLoader, this shouldn't be any trouble, but I want to make it clear that I will remove bugs from triage that haven't seen any activity for over 6 months.
To help with find bugs that I would consider prime candidates for triage, I've created two queries.
The first (http://hexm.de/1y) will find unassigned, open bugs that have been filed against MediaWiki in the past 6 months. About 200 bugs show up.
The second query (http://hexm.de/1z) will find open bugs against MediaWiki modules created in the past 6 months that are, by default, assigned to wikimedia.org email addresses — with those assigned to wikibugs removed. The idea behind this query is to find bugs on MediaWiki modules that the WMF Features team is responsible for. This query finds about 100 bugs.
From this pile of 300 bugs, I need to find about 30 bugs for Monday's triage meeting. Since I expect the Features team from WMF to have a higher turnout at this meeting, I'm trying to find bugs that are relevant to their recent work — bugs that they can fix now.
I'll be going through these lists myself and putting the keyword “triage” on bugs that I think should go into the meeting. But you can get involved, too, if you see a bug from those two lists that I haven't marked for triage and you think it should really be considered, feel free to put the keyword “triage” on it yourself.
Next week, I'll publish the results of the triage and open a new call for bugs.
Mark.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l