I’m very happy to be working with the Open Culture non-profit, the Wikimedia Foundation. Still, despite our almost-rabid openness, there is still some ways that we could improve. One of those ways is fixing bugs in Wikipedia and MediaWiki. We’ve been fairly good about fixing the most onerous problems, but until recently there was no bugmeister in charge of the bug database. As a result, some things slipped and, when they did, the person who reported the issue felt ignored. Since becoming bugmeister, Rob Lanphier has been helping me figure out how to manage the bugs and get the community involved. I put his most recent suggestion into play with an Open Call for Parser Bugs, inviting the community to help set the agenda for our next weekly bug triage. The results have been great. Almost 20 bugs (in addition to my initial 10) were tagged in the first day. Since we already have a “parser” keyword, some people have asked why I chose this theme. It is true that developers who want to fix parser bugs (a vanishingly small number of developers) could just look at bugs already tagged “parser”. But if we just focused on the “parser” keyword, we wouldn’t find bugs like #468: Preceding text and single apostrophes are not included in links and we might lose steam before getting to the bugs that really matter to people. This last bit, what I like to call the cheerleader aspect of the bugmeister’s job, is fairly important. An open source software (OSS) developer’s attention is a precious commodity. If the developer is only scratching her own itch, she isn’t going to do a lot of things. Paid OSS developers, like those employed by the WMF, are the first step beyond a self-interested development focus, but even that is not enough. A developer is hired to work on a particular project, within a particular group, but significant parts of Wikimedia’s software are not written by anyone at the foundation. Without a bugmeister, a liaison between the community using the software and the developers working on the software, might crop up in parts of the code that are not maintained by any active (whether paid or not) developers. And no one would notice. So the bugmeister acts as a proxy for the community. What does the community want that people working on the software haven’t focused on yet? To be a good proxy, I need to involve the community in my triage meetings. This is the first step of this great journey. (Note: I do not think that developers of free software are only self-interested. But I do think we do tend towards self-interestedness in our actions without a motivation to raise our awareness of others. Thanks to Jeroen De Dauw for pointing this interpretation of what I wrote out to me.)