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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Neil Kandalgaonkar |) <neilk(a)wikimedia.org>