Wikimedia blog

News from the Wikimedia Foundation and about the Wikimedia movement

Lead our development process as a product adviser or manager

Would you like to decide how Wikimedia sites work? You can be a product adviser or a product manager, as a volunteer, and guide the work of Wikimedia Foundation developers.

What is a product manager? As Howie Fung, the head of WMF’s product team, recently explained, when we create things on our websites or mobile applications that readers or editors would use,

there are a basic set of things that need to happen when building a product….
  1. Decide what to build
  2. Design it
  3. Build it
  4. Measure how it’s used (if you want to improve the product)
Roughly speaking, that’s how we organize our teams when it comes to building features. Product Managers decide what features to build, Designers design the feature, Developers build the feature, and Analysts measure how the features perform.

So, a product manager works with the designers, developers, and analysts to identify and solve user problems, while representing the users’ point of view. As Fung put it,

there should be someone responsible for ensuring that the various ideas come together into a coherent whole, one that addresses the problem at hand. That responsibility lies with the Product Manager.

Why do you need volunteers? While the Wikimedia Foundation has hired full-time product managers for the most pressing features our engineers are developing, that leaves us with several ongoing projects that don’t get enough product management. The WMF needs your help to: track the progress of these improvements; comment on tasks or proposals; reach out to the Wikimedia reader and contributor communities to ask for feedback via wikis, mailing lists, and IRC; help developers see what users’ needs are; and set priorities on bugs and features, thus deciding what developers ought to work on next. Here are a few of those activities:

  • File storage, especially regarding Wikimedia Commons. Engineers have been trying to improve our storage system using the Swift distributed filestore but need your help to make sure we do it right.
  • Prioritizing shell requests. When Wikimedians request configuration changes to the wikis, systems administrators can use help understanding which of them are urgent and which of them don’t actually have the necessary consensus.
  • Operations requests from the community. It’s not just shell requests. Right now we have 93 open bugs requesting attention from our systems administrators, and those requests could use prioritization and organization.
  • Data dumps. Wikimedia offers many ways to download Wikimedia data at dumps.wikimedia.org. Your help would improve tools related to import, or conversion to SQL for import, to make it easier for others to use these datasets.
  • Wikimedia Labs. The sandboxes in Wikimedia Labs will host bots, tools, and test and development environments; can you organize the advice on the roadmap and what those communities will need?
  • Admin tools development: WMF engineer Chris Steipp works on tools to help fight vandalism and spam, including major bugfixes and minor feature development to make lives of stewards and local sysops a little easier. What’s most urgent on his TODO list?

Volunteer product manager Jack Phoenix put together a detailed roadmap that was incredibly useful to guide the work of Wikimedia engineers on features like anti-spam tools.

Has anyone tried this? The first Wikimedia volunteer product manager was User:Jack Phoenix, who created the admin tools roadmap this summer, detailing a rationale for what should be done when. Jack originally signed up because:

this is just something that I know pretty well and hence why I want to be a part of this project and the team….
I want editors to be able to focus on editing — content creation, tweaking, fine-tuning… — instead of having to play whack-a-mole against spambots and vandals all the time. I have plenty of experience in playing whack-a-spambot, and I’m hoping to use that experience to improve WMF sites and also third-party sites…

It’s perfectly fine for the role of volunteer product manager to be a time-limited engagement. For example, Jack did amazing work for three months creating the roadmap. In retrospect, Jack Phoenix has estimated that to manage a product as broad as the admin tools suite, and to do it well, would take at least an hour per day if not two or three; due to time constraints, Jack has now stepped down from the role and is seeking a successor. Thanks for laying the groundwork, Jack! While we’re sad to see Jack go, we’re thankful for the roadmap and we continue to benefit from it.

If that kind of commitment sounds too burdensome, consider becoming a volunteer product adviser first. You’d do some of the same tasks as a product manager, to help check that the feature we’re building actually meets Wikimedians’ needs, and give your own opinion as well. But there wouldn’t be ownership or leadership attached, and the time commitment wouldn’t be as strong.

What next? The goal of the Engineering Community Team is to have at least two Wikimedia volunteers engaged in product management work by the end of December. Talk with us and check out whether this is something you’d like to try!

To get involved, contact Sumana Harihareswara or Guillaume Paumier.

Sumana Harihareswara
Engineering Community Manager

3 Responses to “Lead our development process as a product adviser or manager”

  1. Rob Lanphier says:

    Heya….you just gave me an idea! We could use a volunteer product manager of volunteer product management, and that person can maintain a well-manicured list of projects. :-) (only half-kidding, actually)

    File management is admittedly not the best example of the easiest area to engage a volunteer in the process, but it can be done. Now that we have Swift in production, we’re currently evaluating how it’s working for us (kinda so-so; it’s working, but not as well as we’d hoped), and comparing alternatives for the next stage of buildout. We could use a little help organizing the comparison. We have 375 bugs in file management areas that could really use a good triage effort with someone with solid end-user knowledge in the area. Solving the communication problem (e.g. interviewing the developers, and publishing what you learn) is also very valuable.

    Every area has some element of these: feature request triage, bug triage, communication assistance, general project management. Maybe only one of these areas is interesting to you (e.g. feature triage), and that’s fine. We’re just looking for ways that people can chip in without being developers.

  2. bawolff says:

    Perhaps more volunteers would come if the people involved better communicated their needs. To pick one example on your list: “File storage, especially regarding Wikimedia Commons. Engineers have been trying to improve our storage system using the Swift distributed filestore but need your help to make sure we do it right.” – All communications about that indicate it is not only done [and furthermore has been done for months now], but also deployed. Although not totally switched over the main reason its not totally switched over is more paranoia and watching closely to make sure that no unnoticed issues cause everything to blow up then anything else [Or at least that is what public comments about swift would seem to indicate]. If various wmf teams want volunteer help, the first step would not be implying that all work is already done.

    • Sumana Harihareswara says:

      I understand your concerns here. We need to be doing better at communicating what’s finished and what’s in what state. But I think it’s possible to improve that kind of communication in parallel, probably with the help of the volunteer product manager/adviser.

      With regard to Swift, the initial move is done but there are always more iterative improvements to make and bugs to fix, and we need to take care of improvements and fixes for deployed software as well; does that help clarify?

      If you have any other examples of Wikimedia technology where engineers might be accidentally sending the wrong signals (especially items I listed), please mention them so we can fix that communication.

Leave a Reply