Entries in Life

Sumana Harihareswara, our Community Development Coordinator, is a very valuable person to have around. She’s helped me incredibly during the weekly bug triage and uses her experience and insights from the Gnome project to great effect.

On my philosophy of bugs post, she asked a couple of great questions and made some really useful suggestions:

• How high-quality is the bug database overall? That is, what proportion of open bugs contain adequate reproducibility steps, and are currently reproducible?Sumana follows this up with a helpful anecdote of her experience from 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?” Given the number of open bugs on this project — 1620, 70% of which were opened before 1.16 came out — this sounds like a good thing for me to do, to weed out the unreproducible bugs. Guess I have my work cut out for this week!
• 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.She’s right again, of course. I’ve had reading the white paper on my TODO list for a bit. Looks like it is time to get it done.

Sometimes

Reading Terry Pratchett’s Feet of Clay to the kids after dinner.

MediaWiki runs the world’s largest and best known wikis. As a result of Wikipedia’s popularity and usefulness and the community’s passion, I can’t think of another piece of software that has gotten better i18n support. Projects like translatewiki.net and the Narayam extension have sprung up to improve the i18n support. This makes it Free Software‘s best argument: give people ownership of the software and they will make sure that it runs better. We all have better software as a result.

Despite this support, MediaWiki and Wikipedia lack in some pretty important areas. One of the areas that this is most obvious is in languages that are written right-to-left (RTL) instead of left-to-right (LTR). We do try to fix these problems, but almost all of our developers work in LTR languages, so we don’t notice the problems as quickly. The problems don’t stare us in the face every day and wiki users in RTL languages like العربية (arabic), فارسی (farsi), and עברית (hebrew) don’t have proper support.

Each of those languages has a wiki with over 100,000 articles in it. I can’t help but think that some of the people who contributed to these larger wikis would also have the skills necessary to fix some of the RTL bugs that have probably annoyed them.

I think that perhaps RTL developers and LTR developers don’t communicate enough. So, if you’re an RTL developer, let me tell you clearly: We want you! You have something that our current MediaWiki developers don’t have — something that we desperately need. Find a bug, submit a patch, and your code can be running on Wikipedia!

Some bugs to get you started:

• titles of articles with LTR titles in RTL wikis may be displayed incorrectly in categories and special pages
• “top left corner” in message may be wrong in RTL wikis.
• the directionality (RTL/LTR) of definitions must match the directionality of the language in which they’re written
• Also, see the RTL tracking bug for all sorts of RTL issues.

For the first time in quite a while, we’re early for Pascha!

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.

Today, in response to a query in wikitech-l, I realized no one had laid out a set of steps for getting an extension deployed on Wikimedia sites.  I wrote out my first draft and a few people in Ops pointed out a number of things that I had missed.  Together, we came up with a fairly complete guide.

This is the second or third time this has come up in the past month.  For example, I’ve directed Santhosh in the steps towards deployment of his WebFonts extension which you can see in action on GerardM’s blog.

The process for getting an extension deployed has been pretty opaque and scary.  Hopefully this documentation will help the WMF developers, people in Operations, and volunteer developers get things done more smoothly.

Lily and I took advantage of the first day of really warm weather to plant some strawberries.

I’ve got to say that Pawan Sinha‘s TED talk had me going. He leveraged the congenital blindness of some Indian children to learn about how we see (spoiler: it’s motion). In the process he achieved a very Humanistic goal: he gave children sight. I once was blind, but now I see. Our goals work best when we do this: we focus on how they can actually help people now instead of in the great by-and-by. More focus on the now is a good thing.

Nice! Another WordPress advantage is that there is an app to allows me to post photos and write from my phone. I doubt I’ll do that  much writing but you might see more photos.