Developer Wishlist/FAQ

What is this about?

Developers are people too! Just like readers and editors, a great user experience contributes to their productivity and motivation, while a poor user experience might drive them away. The Developer experience (DX) affects everything from the learning curve to work efficiency and retention, both for volunteers and professionals.

Despite its importance, DX has not get much attention in our projects. In a context of lack of clear priorities and dedicated resources, most of the improvements are addressed on an ad hoc basis by developers scratching their own itch.

Wikimedia tool/feature development for experienced editors used to suffer from the same problem, and the Community Wishlist proved to be an effective process to get around that problem. Inspired in that precedent, the Developer Wishlist aims to direct our attention to the requests considered most important by the own MediaWiki developers and the Wikimedia technical community at large.

What kind of proposals are appropriate for the wishlist?

Every idea submitted for the Developer Wishlist should meet some scope and concept criteria.

• Developer-focused — It should be something that benefits developers, with the least disruption.
  • Why: The wishlist is aimed at improving the developer experience. Tasks which fall outside of that should be highlighted in other ways.
  • Bad example: "Replace all uses of while loops with foreach loops because they're cooler."
  • Good example: "Ensure the agreed coding standards are applied through pre-merge continuous integration tests for consistency."
• User-neutral — It should not significantly change things for end users of the software, and should not be in scope for the Community Wishlist Survey.
  • Why: There are already processes for getting changes made that impact users — Wikimedia's Community Wishlist Survey and its Annual Planning Process. It's important to respect users' concerns and their time, to not bypass those processes.
  • Bad example: "Replace the diffing system with my preferred one."
  • Good example: "Refactor the API for providing diffs so that I can extend it efficiently and cleanly."
• Actionable — It should be something that has a specific outcome where it can be judged to have been "done".
  • Why: Tasks which cannot ever be completed are demotivating for developers to take on. Because they are very large, they make it impossible to ensure everyone agrees on which bit is important. This removes the ability for voting developers to prioritise important areas.
  • Bad example: "Have great documentation."
  • Good example: "Add examples to the documentation for how to extend EditPage.php for a custom ContentHandler."
• Doable — It should be something that will take a developer in their volunteer time a few days, or up to a month to be "done".
  • Why: Most of the improvements made to the MediaWiki platform for developers are done by volunteers (including staff on their volunteering own). Though very big tasks can and do get taken on by the Wikimedia Foundation's teams, it's much better to break up tasks into smaller components which don't create single points of failure for execution.
  • Bad example: "Rewrite MediaWiki in Ruby."
  • Good example: "Provide a set of Ruby bindings for these key parts of MediaWiki: …."

What's going to happen once the results are in?

The results will be publicized in channels which are used for choosing tasks (e.g. hackathons, developer outreach projects, WMF quarterly planning). The Developer Wishlist is a community effort, and there is no team committed to work on it, so no one will be required to take it into account, but many people already invest significant amounts of time into improving the developer experience; we expect they will be interested in learning what's the most impactful way of spending that time.

In other words, the wishlist is an experiment in bottom-up coordination of efforts. In a year, we'll see how well it worked!

What is the timeline?

This timeline for the 2017 wishlist:

• 2017-01-09: Developer Wishlist session at the Wikimedia Developer Summit 2017 concludes with a decision to run a first survey by February 15.
• 2017-01-16: Call for wishes opens (via the #devwish17 Phabricator project). Triage and discussions happen as new proposals arrive.
• 2017-01-31: Call for wishes closes on 23:59 UTC. Triage and discussions continue with the goal of starting the voting phase.
• 2017-02-06: Voting phase opens.
• 2017-02-14: Voting phase closes on 23:59 UTC.
• 2017-02-15: Developer Wishlist Survey results announced.