Scaling up Software development for Wikimedia websites (Part I: Human resources)

During the past few weeks, I have been thinking about a more structured way to manage software and product development within the Wikimedia community. The result is a list of ideas and recommendations I have compiled and submitted to the relevant staff members at the Wikimedia Foundation. I am also publishing them here in order to allow for a wider feedback. This article is the third of a series dedicated to this topic.

Disclaimer: The content of this article reflects only my personal opinion and is not an official plan or communication of the Wikimedia Foundation.

Brighton University usability lab by Danny Hope640 590x394 Scaling up Software development for Wikimedia websites (Part I: Human resources)

User research is critical in order to understand the users and design products that make sense to them. (CC-by by Danny Hope)

I am not going to give specific advice about how many developers the Wikimedia Foundation should hire: there are other people more knowledgeable about how many we need, and what they should work on. However, there are other key positions that I think are need to scale up.

Our human resources are currently focusing on what happens after the code has been written: we review it, we try to ensure quality, we try to automate testing, we file bugs, etc. However, there is little preparation before the development is actually done. This has led to a developer-driven design, resulting in an interface based on the implementation model. We need a more systematic approach to User experience and development management if we want to scale up properly.

Product management & Design

In the Software development world, Product managers and Designers are the most common bridges between users and engineers. Product managers identify the needs of users and prioritize features & improvements; their goal is to translate the users’ experience and feedback into explicit requirements to meet the users’ expectations. It is then the role of the designers to create innovative, well-thought solutions to address these issues and meet the requirements. Finally, developers provide feedback about the technical feasibility of these solutions, and implement them the best way possible. This is of course a simplistic summary, but it helps get the point across.

“Designer” can have a lot of different meanings. A lot of people think that “design” is just making things pretty. When I talk about designers, I think mainly of Interaction Designers, i.e. people who design solutions to improve the user experience and the way the product interacts with the user.

The community of MediaWiki users is amazingly large, partly because they include participants from all Wikimedia Websites. Similarly, MediaWiki also benefits from a large base of volunteer developers. Product managers and designers have been the missing piece in this picture; their bridging role is critical, simply because there aren’t any volunteers to take up this task. Admittedly, some users are also developers, and some developers keep themselves informed of the users’ wishes. But without product managers, clear requirements & prioritization are missing. And without designers, the technical solutions created by the developers don’t meet the users’ expectations and mental model.

In my experience, developers prefer to focus on the actual development and rarely enjoy meta-activities related to it. They usually dislike project management and writing product specifications, and rightly so: it is not their job. However, a successful software product strategy cannot rely only on development. We benefit from a large community of volunteer developers, but we lack management & design resources; it is the role of the Foundation to supplement this lack. It doesn’t mean we shouldn’t expand our development team: our number of paid core developers is ridiculously small. It only means we should also invest where the weakness lies.

Recommendation: Recruit Product managers and Designers to strengthen the development cycle of our technological platform

Research team

The Multimedia usability project has relied heavily on initial research in order to gather as much information as possible about users and their goals. A lot of useful information was already available, but a lot of specific metrics were also missing; collecting and analyzing them took a lot of time and it will still take months to get all the metrics we need. Research is critical in order to make the right decisions, especially about design. Research is the only way know our users in order to make the best design & management decisions. Good research is the best basis on which product managers, designers and developers can then respectively specify, design and build awesome solutions.

Right now the only researcher we have is Erik Zachte as Data analyst, but his job seems to essentially focus on providing operational metrics. While this work is much needed, we also need some more specific data on a case by case basis. I see at least three other positions needed:

  • A UX research specialist, who would conduct regular in-house low-cost usability testing, and generally manage UX studies
  • A Metrics engineer, who would develop integrated metrics in the software and be able to extract specific information from the database on a case by case basis.
  • A Community specialist, with a good knowledge of social psychology and online interaction, who would especially focus on improving the interaction between participants by identifying the community issues and proposing ways to fix them.

Recommendation: Build a Research team to guide design & strategic decisions about our technological platform

Volunteer developers

We benefit from a fantastic community of volunteer developers, but we underestimate their potential; I think we are not doing enough to support their work and engage them into our activities. In 2007, the Foundation hired Cary Bass to try and coordinate the large pool of volunteers willing to help us with meta activities. Similarly, we need a Dev community manager to care for our volunteer developers. We need someone who knows the developer community very well, and knows their strengths and weaknesses in order to find the right person for each job. We need someone who can help orient new volunteers, organize real-life meet-ups and manage projects such as the Google Summer of Code.

Recommendation: Recruit a Community manager to coordinate the efforts of volunteer developers.

Read also in this series

Posted in Design, Featured, Wikimedia Technology | Tagged , , , , | 2 Comments

Wikimedia User experience programs: a systematic approach

During the past few weeks, I have been thinking about a more structured way to manage software and product development within the Wikimedia community. The result is a list of ideas and recommendations I have compiled and submitted to the relevant staff members at the Wikimedia Foundation. I am also publishing them here in order to allow for a wider feedback. This article is the second of a series dedicated to this topic.

Disclaimer: The content of this article reflects only my personal opinion and is not an official plan or communication of the Wikimedia Foundation.

Japanese Tea pot by Denis Savard640 590x393 Wikimedia User experience programs: a systematic approach

A Japanese teapot. Friends of Donald Norman will understand. CC-by by Denis Savard

Investing in UX is a Good Idea

Over the years, the design of MediaWiki has been solely driven by software developers. This has caused an unfortunate technology-based approach of the front-end and the features (implemented or missing), relying mostly on the implementation model. The consequence is that the interface & features are too far from the users’ mental model. The Wikipedia and Multimedia Usability projects have tried to address the most pressing concerns resulting from this hiatus between the software and the users’ expectations.

For all these reasons, I am really happy to see the Wikimedia Foundation investing further in User Experience (UX). However, I see little added value in having an UX department separate from the main development cycle. There are at least two reasons to keep them as one.

UX should be a systematic approach

A more systematic approach is necessary in order to improve the usability of Wikimedia projects perennially; good, usable design needs to happen before the actual implementation of any feature, in the early stages of the product (or component) development. Otherwise, we will always be running after the train, and never catch it. A separate entity made sense when these UX programs had a specific scope and time frame, but it was because they were tied to specific grants. In a more permanent setup, I see no reason to separate UX programs from the “regular” development processes; targeted actions can be carried out by specific projects inside the development team, rather than by a separate team altogether.

Everything is UX

More generally, all the activities of our Technology department are about User experience; everything we do is UX. Software development aims to fix bugs, develop new features, improve others, and remove hindrances. The sole goal of all of these activities is to improve the user experience by making the software better and closer to users’ needs. Even Operations are about UX: the goal of the Operations team is to make sure the information can be accessed reliably and reasonably fast by an audience as large as possible; in short, the point of Operations is to ensure we actually provide a user experience.

As a consequence, I recommend to make UX a systematic part of the product or component development cycle, not a separate parallel entity.

Read also in this series

Posted in Design, Featured, Wikimedia Technology | Tagged , , , , , | Leave a comment

Wikimedia & MediaWiki bugs, issues and requests

During the past few weeks, I have been thinking about a more structured way to manage software and product development within the Wikimedia community. The result is a list of ideas and recommendations I have compiled and submitted to the relevant staff members at the Wikimedia Foundation. I am also publishing them here in order to allow for a wider feedback. This article is the first of a series dedicated to this topic.

Disclaimer: The content of this article reflects only my personal opinion and is not an official plan or communication of the Wikimedia Foundation.

bug sunflower 590x392 Wikimedia & MediaWiki bugs, issues and requests

Bug on a sunflower. (CC-by by Louise Docker)

Bugs & Bugzilla

Right now, the bug tracker we use is based on Bugzilla and located at bugzilla.wikimedia.org. Many major free projects use a generic “bugs” or “issues” prefix or suffix in their URL: bugs.kde.org, bugs.gentoo.org, issues.apache.org, www.debian.org/Bugs. Some projects use the “bugzilla” prefix like we currently do, like bugzilla.gnome.org. The latter is an example of a choice based on the implementation model: the name reflects the technical implementation of the bug tracker, not its actual purpose. A better name would be closer to the user model and describe the actual goal of the platform: to report and manage bugs and issues related to a specific project. If we do change our tracker, the current name will have to change too, because it is specific to a given tool.

Recommendation: Use a generic descriptive prefix rather than one based on the tool we use.

Wikimedia & MediaWiki

Another current issue is the confusion caused by the similar names used for the organization (Wikimedia) and the software (MediaWiki). A good example of this confusion is the number of MediaWiki users who join the #wikimedia IRC channel instead of #mediawiki to ask for software support. The confusion is even worsened by the fact that we have a unique bug tracker located at bugzilla.wikimedia.org, dealing with issues related to both Wikimedia websites and the MediaWiki software.

There are obviously strong ties between Wikimedia projects and MediaWiki: all Wikimedia projects use the MediaWiki software, and the MediaWiki software is primarily developed with Wikimedia projects in mind. However, there is also a growing community of MediaWiki users who are not Wikimedia users and we should provide them with tools relevant to them. This might be for instance a support forum dedicated to MediaWiki users.

Wikimedia projects and MediaWiki are separate products and they should be acknowledged as such: as a consequence, the separation between bugs in the MediaWiki software, and Wikimedia-specific operations & configuration requests should be made more explicit. Obviously, we would prefer to have a unique back-end to support both sites, particularly to be able to move bugs and requests from one platform to another, but this is easily configurable. Possible names could be dev.mediawiki.org and tech.wikimedia.org; both are currently unused. They are pretty wide prefixes, because we may host a real project management platform there, rather than just bug trackers.

Recommendation: Offer two different public-facing platforms for MediaWiki- and Wikimedia-related issue tracking.

Read also in this series

Posted in Featured, Wikimedia Technology | Tagged , , , | 3 Comments

More Wikimedia documents!

Last week-end, I attended my first meet-up of Wikimedians from the San Francisco Bay Area. It happened at the same time as a meeting of the Board of Trustees of the Wikimedia Foundation. It also happened at the same place, i.e. the office of the Foundation (where I work).

A couple of topics were discussed during the meet-up, notably the next Maker Faire, the next meet-ups and the possibility of organizing a regional Wikimedia conference later this year, probably around November. I am also going to try and promote Commons as much as possible while I’m here.

WMCON swag 2009 9124 640 590x393 More Wikimedia documents!

Preparation for Maker Faire also include generic pins & stickers. (CC-by-sa by Elke Wetzig)

As people were talking about the need for various kind of documents and goodies to hand out at the Maker Faire, I realized that we could actually organize some sort of Marketing Marathon during the next meet-up. The goal would be to write together the content of documents, based on pre-arranged templates so that it fits with the design.

I have to admit my other responsibilities within the Wikimedia movement have distracted me quite a bit from the Wikimedia documents initiative I launched in May last year. It would probably have helped a lot if some people had responded to my call for volunteers. Not only would it have saved time, but it also helps immensely when other people are interested in your work: it puts some friendly pressure on you.

The Marketing Marathon proposal was well received and we agreed to organize it as part of the preparation for the Maker Faire during the next meet-up. I now have volunteers willing to help, and a draft timeline with the next meet-up and the Maker Faire. Besides, I hope to benefit from the research made by the Bookshelf project, which already answered one of my questions: what standard format to use for documents intended for an international use.

If you would like to help, or if you think you have good ideas, feel free to contact me.

Posted in Marketing, Wikimedia Movement | Tagged , , , , | Leave a comment

IRC office hours: Multimedia usability project

A lot of people have shown interest in the Multimedia usability project and it turns out that many questions are similar. I would like to answer as many questions as possible, but on the other hand I also have to optimize the time devoted to such activities. A good venue for this kind of Q/A is the Wikimedia “IRC office hours”, a weekly event during which a Wikimedia staff member answers questions on IRC.

As a consequence, I will be available on IRC to answer questions related to the Multimedia usability project this Thursday, February 4, 2010 @ 1700 UTC. You can use the fixed time world clock to check the time in your timezone. Please join us in #wikimedia-office on Freenode using your favorite IRC client; you may also use web-based clients (check out the IRC office hours page on meta-wiki for more information on how to do that).

Looking forward to your questions.

Posted in Multimedia Usability | Tagged | Leave a comment