Developer Wishlist

The Wikimedia technical community seeks input from developers for developers, to create a high-profile list of desired improvements. The scope of the survey includes the MediaWiki platform (core software, APIs, developer environment, enablers for extensions, gadgets, templates, bots, dumps), the Wikimedia server infrastructure, the contribution process, and documentation.

We are organizing the first edition of the Developer Wishlist in Phabricator. Get involved! Current proposals can be found in the Developer Wishlist (2017) board. Scroll down to add a new one.

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.

Scope
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  loops with   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: …."

Propose ideas
Developer Wishlist proposals are submitted as Phabricator tasks associated with the Developer Wishlist (2017) milestone ( alias). If you need help using Phabricator, please check Phabricator:Help. Before adding a new proposal, please look at the existing ones to avoid duplicates.

Add a proposal

That's it! From that point, be ready for possible questions and feedback from other contributors. You might get help to sharpen the idea, improve the description, add other related tags... The task might be merged with another one, or maybe split into different ones. The common goal of these changes is to improve the proposals before the beginning of the voting phase.

Vote ideas
The voting process is being discussed at T155462.

Timeline
This timeline welcomes feedback and is still subject to potential changes.
 * 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. Triage and discussions happen as new proposals arrive.
 * 2017-01-31: Call for wishes closes. Triage and discussions continue with the goal of starting the voting phase.
 * 2017-02-06: Voting phase opens.
 * 2017-02:14: Voting phase closes.
 * 2017-02-15: Developer Wishlist Survey results announced.