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.
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.
Photo gallery
unfoldscience: scientific communication
Journal en français
Believe it or not, I was thinking about the “dev community manager” the day before yesterday. It’s a role that should be filled. We’ve got a lot of raw talent floating around #mediawiki, and it would help if there was someone to herd the sheep.
Yeah, I’ve been thinking about that as well. The idea has been floated around before as a volunteer position – I’m not sure that’d work as well as a staff member. In any event, This is a very convincing argument to do it – I hope Guillom can make this happen from within the Foundation.
I was also considering the difference in the experience of filing a bug against MediaWiki vs my recent experiences filing bugs against the Gerrit code review tool for git. In the latter case, I spoke directly with a core developer about the issue, and proposed solutions. After figuring out what was a bug and what wasn’t, and what direction the solution should take, I filed bugs with those details. In comparison, filing a bug against MediaWiki provided (in most cases) zero feedback until months down the road – often that feedback is that the issue won’t be fixed. Instead, we should try to provide immediate feedback on every bug as they are filed – in particular whether the bug is accepted or not. Even better would be providing an opportunity to figure that out before the bug is even filed. I can’t immediately think of something more disheartening than having your bug rejected, or simply ignored. This is especially true for UX issues, which until recently have not been taken seriously. Even now, UX work is focused on the vector skin, and maybe a bit on FlaggedRevs (now that enwiki is involved, UX issues might be taken seriously – nobody cared about these problems earlier). This role could be filled by whoever is tasked with the “development community co-ordinator” and could make a big difference in how our tracker is used.
Finally, we need to ensure projects like AbuseFilter or LQT are taken to completion. Currently these projects lack polish (to be fair, LQT is still in the works), simply because the UX issues can be swept aside as insignificant in comparison to completing the core development. That isn’t good enough & the Foundation should be providing guidance with the aim of completing that missing polish.