Google Summer of Code has ended and, with it, my first chance to mentor a student with Markus Glaser in the process of implementing a new service for MediaWiki users.

At the beginning of the summer, Markus and I worked with Quim Gil to outline the project and find a student to work on it.

Aditya Chaturvedi, a student from the Indian Institute of Technology (“India’s MIT”) saw the project, applied for our mentorship, and, soon after, we began working with him.

We all worked to outline a goal of creating a rating system on WikiApiary with the intention of using a bot to copy the ratings over to MediaWiki.org.

I’m very happy to say that Adiyta’s work can now be seen on WikiApiary. We don’t have the ratings showing up on MediaWiki yet (more on that in a bit) but since that wasn’t a part of the deliverables listed as a success factor for this project, this GSOC project is a success.

As a result of his hard work, the ball is now in our court — Markus and I have to evangelize his ratings and, hopefully, get them displayed on MediaWiki.org.

Unlike some other projects, this project’s intent is to help provide feedback for MediaWiki extensions instead of create a change in how MediaWiki itself behaves. To do this, Aditya and I worked with Jamie Thinglestaad to create a way for users to rate the extensions that they used.

We worked with Jamie for a few reasons. First, Jamie has already created an infrastructure on WikiApiary for surveying MediaWiki sites. He is actively maintaining it and improving the site. Pairing user ratings with current his current usage statistics makes a lot of sense.

Another reason we worked with Jamie instead of trying to deploy any code on a Wikimedia site is that the process of deploying code on WikiApiary only requires Jamie’s approval.

The wisdom of this decision really became apparent at the end when Adiyta requested help getting his ratings to show up using the MediaWiki Extension template.

Thank you, Aditya. It was a pleasure working with you. Your hard work this summer will help to invigorate the ecosystem for MediaWiki extensions.  Good luck on your future endevors.  I hope we can work together again on MediaWiki.

I’m just getting caught up on the latest sexist insensitivity happening in the tech world, but as I was reading @nrrrdcore’s postt There is No Emoji for Martyrdom (update: context) I came across this year old story about Adria Richards being fired for publishing pictures of men who made rude and inappropriate comments, I’m struck by this quote that is attributed to her:

There is something about crushing a little kid’s dream that gets me really angry. Women in technology need consistent messaging from birth through retirement they are welcome, competent and valued in the industry.

Am I reading that wrong, or is she saying that she thinks women need to be told they’re competent when they are clearly not competent?

Does anyone go “from birth through retirement” being told they are welcome — regardless of their gender? Especially when they aren’t helping the people they’re working with to accomplish the goal they’re striving for? How do you say “We welcome you, even though it seems like you’re just getting in the way?”

I was mostly with Adria up until this quote in the story. I’m not going to say she should be able to publish people’s pictures on Twitter without any consequences, but she felt threatened, or at least angry, and she reacted. What she did is understandable in that context. From reading this tiny slice of the story, I can only assume that she felt making a statement was more valuable to her than continued employment. And I can respect that. It takes some real self-assurance to decide to tke that sort of stand.

But this quote of hers seems wrong to me. Maybe as I look at the story, I’ll see get some context that is missing right now — something that would frame the statement better. But the statement by itself seems insidious — that we should tell women they are valued in the field simply for being women?

Now, I’m very aware that there is a real gender imbalance in the tech community — especially in the free software world where I make my home. And I’m keen to make sure my three daughters will be able to succeed in whatever they decide to do — I’ll be especially interested in they really take an interest in my chosen profession.

But the reality is that the world crushes people’s dreams all the time. Anyone who goes from birth to retirement and gets the consistent message that they are welcome and competent is being fooled. I don’t want that for any of my children. If they need to be told to improve or that they just aren’t doing what is needed, then that’s fine. I’ve been told that more than once and I’ve managed to survive and I certainly want my children to be tough enough to survive and thrive as well.

Altaner.jpg The nolug mailing list has been taken over by the perpetual whine again: “New Orleans Sucks.” Even though I still love the city and sometimes dream of living there again, when it comes to crime or politics there are many ways that it does, indeed, suck. But the thing that got me to move away — before Katrina came and made the problems worse — was opportunity. I had to post my experience with New Orleans and opportunity.

TL;DR: Even freetards need people skills.

I am telling you why I love and miss New Orleans. It has nothing to do with tech or politics. I don’t live in NOLA because of opportunity, remember?

I should clarify. I did post about politics. And even while living there, I was bothered by politics. But politics didn’t make me move.

Even rampant crime — my wife and I were robbed at gunpoint once — didn’t make us move.

It was opportunity. At the time, I was working as the “anti-spam” guy for McDermott. When they replaced my Solaris MTA with a Barracuda appliance and terminated the contract, I really wanted to continue working as a fairly-well-paid person working with Unix.

Most of the readily available jobs that met my criteria in NOLA at that time required an Oracle certification. I did think about getting one — the cost-benefit ratio for an Oracle Certification is pretty good and demand was there — but I am too much of what Fake Steve Jobs calls a “freetard” to get one. The GPL really does mean something to me.

We sold our house in Carrolton, and, for a few weeks, I worked as a Perl subcontractor for a guy in San Francisco on a mod_perl project he had.

After that, I went to work on a presidential campaign in Little Rock.

Even though the campaign was a flop and the pay was abysmal, it was one of the best decisions of my career: I made a number of friends from around the country and worked closely with them over the course of a few months. Those relationships led to more opportunties than I would otherwise have, living here in rural Pennsylvania.

So, yes, NOLA sucks as far as opportunities. Any place outside of a major metropolitan area like New York or San Francisco probably sucks a similar amount, at least for Tech jobs.

Which brings me to my point: It isn’t WHERE you are or even WHAT you know so much as WHO you know and HOW connected you are. You can have great tech skills and still be stuck with a job in a New York City bodega if you don’t know how to leverage them.

Yes, a person in the right place with the right set of technical skills can do amazing things. But if he doesn’t have any way to build and maintain some relationships that will help him when his current situation is finished, he’ll be stuck.

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:

Posted in wmf.

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.

Posted in wmf.

A friend of mine asked me for a job recommendation.  He got the job, so I’ll assume that anything I said about him didn’t hurt him.  Today, I talked to him.  He is managing the JetPack project for Mozilla Labs. After he mentioned it today, I went to look at it.  After poking around a bit, I have to say, it is some exciting stuff.

Jetpack is a project to make it easy to build Firefox 4 add-ons using common web technologies like HTML, JavaScript, and CSS. Our goal is to enable anyone who can build a web site to participate in making the Web a better place to work, communicate, and play. 

I’ve been thinking about some ways to start getting my kids into programming (yes, still).  I believe one of the most important things to start children in programming.  This comes from recalling my own youthful start on a Commodore 64 and then a more “business-y” TRS-80 Model 4p, both of which came with BASIC interpreters, both of which had magazines published for them that were filled with pages of BASIC to type in and run. My parent’s recently gave me back a copy of  BASIC Computer Language: It’s Easier Than You Think!.  This past weekend, in a fit of Father/Son bonding, I installed a copy of SmallBasic and let my son go at it.  He read a few chapters but went straight to the back to type in the castle program.  I had to help him convert the graphics code, but it didn’t take long before he was trying a few different things on there. BASIC is long gone.  Visual Basic is all tied up in the Bill Gates mentality and, as a righteous freetard, I can’t let my son develop those sorts of defaults.  His school is already doing the job well enough by getting them to use PowerPoint. So, instead of BASIC, I think JavaScript — a language that gives instant gratification, is on every desktop, and has sample programs all over the web — is probably as close as I can get to the heady days of programming I remember from my own youth. Why do I want to teach them?  I could give you the pragmatic explanation that dvfmama has: they’ll be surrounded by computers all their lives, they may as well understand how to get them to do things.  And there is that.  It is just part of being a modern, literate person to have some understanding of programming — whether that programming happens on a spreadsheet or a web page.  But more than that, I remember feeling a thrill and thinking “Wow, look what I made the computer do!” Honestly, I don’t want my children to miss out on that thrill. So, I’m gonna take a look at JetPack this weekend.  Let’s see what it can do.

Working on free software projects isn’t easy. Just because you’re giving away your work for anyone to use doesn’t mean that anyone is going to take it, no questions asked. Take my MediaWiki work as an example. I am being paid for the work, but it is freely licensed and I’m learning about the standards of quality that the community has formed around the code. Frankly, before becoming involved in such a serious PHP-based project, I didn’t have a very high opinion of PHP. Even Rasmus (creator of PHP) doesn’t seem to live in a pure php world and, as a result, thinks of systems where PHP is merely the web frontend instead of almost the entire system. So working with others who have been neck-deep in PHP for years, building one of the top-10 sites on the net entirely in PHP, and gaining intimate familiarity with the quirks of PHP, has been a wonderful experience. But MediaWiki isn’t the only free software project I’m involved in. I also contribute to Emacs occasionally. (For those not so familar with Emacs vs Vi, let’s just say this is like the social situation between Republicans and the Democrats or the Roman Catholics and Southern Baptists: You live next door to them, but you know they’re going to hell.) And it is my most recent commits to Emacs that have gained me noteriety. Yesterday, I was catching up on some blog reading (Planet Emacs, thankyouverymuch) and came across a nifty use of loccur.el. But it used defadvice instead of a hook (and hooks are better — no this is different than emacs vs vi, I swear). I looked at the code and thought, “Hey, I can make a tiny little contribution to Emacs here!” So I made a couple of small changes. Little did I know what a problem that was going to be. Óscar Fuentes used my commit message as an example of how not to write a commit message. This was not the first time I’ve been so honored. Three weeks ago, I made a mistake committing to the bzr repository for emacs and was again used as an example for the Emacs-devel community of how not to make a commit. There are two reasons I’m such a stellar example for the other Emacs developers. First, I’ve been using bzr for a couple of years while working on the iHRIS Suite. This experience (2 years more than most Emacs developers) naturally made me think I had things under control. So I didn’t bother reading over Bzr for Emacs Devs. Second, Emacs recently switched its source-control system (after much debate and some effort on speed the bzr side) from the ancient, worn, CVS to bzr. So people are still adapting their work flow. I just happened to make some commits that were particularly egregious and ended up being great examples of what people should avoid. So, yes, Free Software is a great thing, but that doesn’t mean the developers don’t take it seriously. And being reprimanded in public isn’t the most pleasent experience. But at least I can blog about it!

Almost two years ago, when I started working at IntraHealth, dcm told me about IntraHealth Open. Being a neck-bearded freetard, the idea really appealed to me: Use open source in the education of students in developing countries across Africa to build a workforce that could support the IT infrastructure of the continent without using Western consultants. The use of Free and Open Source Software (FOSS) is essential to the goal. Using software that is freely licensed for perpetuity avoids the "First Hit is Free" model many software companies use to get developing countries hooked on their software. Building the use and understanding of FOSS into the curricula gives the students the skills they need to use software on the job. And deploying freely-licensed software like Ubuntu, OpenOffice, iHRIS Suite and OpenMRS into these developing countries will create a local demand for workers who can use, understand, and maintain the very software they’ve learned about in school. I’m very excited about the new IntraHealth OPEN initiative. You can even take part. Senagalese musician Youssou N’Dour is working with other musicians to help raise funds for the OPEN initiative by making his music and remixes of it available for free download under a Creative Commons license. So go download some music and consider making a donation to IntraHealth OPEN. UPDATE: Listen to dcm talk about Open in the Launchpad podcast.

m4s0n501

One of the never-ending subjects of Free Software is “Where are the Women?” While I see it as mostly a non-problem — that is, there are some obvious problems that need to be fixed with time, but no one is going to rectify them right now — I’m doing what I can to encourage my daughters and son in the field. In the meantime, The Decline of Women in Computer Science from 1940-1982 has some fascinating anecdotes:

Computing was unique, however, in the sense that the fledgling profession was still in its infancy and had no strong pre-war gender socialization.  This fact must have helped the women in that the returning men lacked programming expertise, and clearly had no expectation of “returning” to a programming job.  The lack of structure in the industry was also a boon to women programmers who wanted to continue working even after they became pregnant and had children.  Most notably, “Computations, Inc., of Harvard, Massachusetts (outside Route 128), formed in 1958 by Elsie Shutt and several other programmer-mothers who worked part-time and largely at home on problems contracted out to them by their former employers, such as Minneapolis-Honeywell and Raytheon”.  These women, widely known as the “Pregnant Programmers” were mentioned by speaker Richard H. Bolt at the M.I.T Symposium on American Women in Science and Engineering in 1964.  Bolt, who was a lecturer in Political Science at M.I.T and also a former Associate Director of the National Science Foundation (NSF) from 1960-1963, also mentioned the following:

“I asked one of the unmarried women, a computer programmer in industry, if she thought a woman’s activities as a mother and homemaker would interfere with her opportunities in a career.  ‘One good thing about programming,’ she said, ‘is that you can work part time.’”