(Starting) A philosophy of bugs on an Open project

Being a bugmeister is a new thing for me.  As someone pointed out, the title seems to be made up and almost exclusive to Open Source projects.  There is a paucity of information on How to bugmeister.  What is involved? What are the metrics for measuring my success or failure? What power do I have, besides irritating developers and administrators with bugs?

As it turns out, the answer to the last question is probably close to “none.”  But that power can be used to great effect.

Priority

To help me understand how much to bother developers with bugs, I’m using the priority field.  Developer’s should know that bugs assigned to them that are higher priority should be fixed sooner.  From a developer’s point of view, this seems like a good way to find out what bug should be fixed next.  (Note that fixing bugs is only part of a developer’s work.)

This means of course that putting a high priority on bugs that haven’t been assigned to anyone (or that have only been auto-assigned by Bugzilla) doesn’t make much sense.

This conflicts with the bug reporters’ intuitive feel about “their” bug.  They may be extremely frustrated by the buggy behavior.  Why should the priority of the bug be low when (obviously) it mattered enough to them to bother reporting it on Bugzilla?  If they are especially irritated by the bug, then they’ll see it as a very high priority bug.

From the perspective of the Foundation, though, where there are millions of users for Wikipedia and only a relatively small number of paid developers, a different understanding of priority is needed.  If only one or two editors is affected, that bug has a lower priority than one that affects hundreds of thousands of readers.

Added to the problem is an already existing database of bugs from the past nine years.

Priority and Getting Your Bug Fixed

Today, someone suggested to me that the priority of a bug should increase the longer it has been open rather than decrease.  This particular bug had been open for 18 months with relatively little discussion and no duplicates.

From the few months I’ve been on the job, a bug only a few people has noticed in over a year is, almost by definition, a low priority.

This is not to say that their irritation with the issue is meaningless, so it is here that the political savvy of the bugmeister is tested.

I have to figure out how to communicate how the people concern with a bug can get their bug noticed when it has been ignored for so long.

If users are irritated enough that they think their issue should be a higher priority, then they have two ways of getting the problem resolved.

The first is to show that the bug affects a substantial number of people and that the irritation is more than what is shown by the people who have registered an interest in having this bug be fixed.

The second is to find a developer familiar with the MediaWiki code and get them to fix the code.  The wonderful thing about Wikipedia is that this person doesn’t even have to be inside the WMF.  Plenty of developers outside the WMF have commit access.  Someone without commit access can even supply a fix by attaching a patch to the bug. When this happens, I review and apply the patch.  Then other people have the chance to review the patch and, if it fixed the problem, the fix would be deployed on Wikimedia properties.

Note, though, that bumping the priority on an old issue does not get it solved.  That is only really effective for irritating the bugmeister.