(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.


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.

3 thoughts on “(Starting) A philosophy of bugs on an Open project”

  1. The questions at the beginning of your post got me thinking:

    * How high-quality is the bug database overall? That is, what proportion of open bugs contain adequate reproducibility steps, and are currently reproducible?

    I don’t know the answer to this one regarding the MediaWiki bugbase; what are your thoughts? When I was actively triaging Empathy bugs, I was able to clear out a big backlog by testing the repro steps in old open bugs and sending the reporter a kind boilerplate notice basically saying: “not reproducible in the current stable version; have you upgraded?” It took very little time, thanks to the pre-written text. I figure one goal of the bug database is that every open bug should be a ready, inviting problem for a developer to solve, regardless of priority.

    * What are the strategic priorities of our community and our product? The WMF product whitepaper is probably useful here. We have the ability to think of priority in a more sophisticated way than simply predicting numbers of admins and users affected; we can also weight the importance of the feature.

    Maybe in a few months you’ll be ready to write a new chapter and contribute it to Karl Fogel’s book _Producing Open Source Software_!

  2. First of all word “bug” here does not mean “bug” in the traditional sense, but “request for something to be done which we believe needs a bugzilla entry raised.” So sometimes they are requests to change a setting on a given project, sometimes they are about an enhancement, sometimes they are a traditional bug.

    Most of the bugs I believe are unlikely to have “quietly gone away”, although I only watch maybe half a dozen so I could be wrong.

    The other point that Sumana makes is, however, critical. “What are the priorities for our community and product?” The English Wikipedia, for example, suffers badly from the lack of a decent way to cite different page-numbers from the same work, without creating multiple footnotes. There is a bug raised for this, which includes patch code, yet the bug has been languishing for some time.

    To gauge the importance of these types of bugs the main options available to a bugmeister (apart form deep intimate understanding of the projects themselves) are: firstly engage with the communities at venues such as Village Pump (technical), and secondly use the “votes” on Bugzilla.

    Users such as Xeno, Amalthea, MSGJ, X!, RedRose64, Happy Melon, and others will have a good idea of where a MediaWiki bug is a sticking point for the community.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.