Developer Wishlist

Expanded from https://etherpad.wikimedia.org/p/devsummit17-developer-wishlist

What is the Developer Wishlist?
Every year, the MediaWiki community seeks input from MediaWiki developers — of MediaWiki, of extensions, of consumers of the API s (actions / REST / Wikidata), of tools that use the dumps, and elsewhere – to create a high-profile list of desired improvements.

Why run a Developer Wishlist?
Developers are people too! Just like readers and editors, a poor user experience can drive them away and make them spend their time on some other project instead, while a great user experience can allow them to work more focused and more effectively. Developer experience (DX) affects everything from the slope of the learning curve to volunteer and staff retention to work efficiency.

Despite the importance, DX does not get much "official" attention; the continuous integration infrastructure has an owner, but most other related functionality (such as documentation and consistent interfaces, logging and error reporting, debugger and development environment integration) is improved on an ad hoc basis. That tends to result in prioritisation reflecting the needs of the people doing that ad hoc work; even if they want to focus on what is going to have the highest impact, they don't have the resources to figure out what that is.

Wikimedia tool/feature development for experienced editors used to suffer from the same problem, and the Community Wishlist proved to be an effective tool to get around that problem. Maybe that success is something that can be copied; should we try to create a Developer Wishlist that can be used to direct attention to the important platform-level issues the same way the Community Wishlist directs attention to the important feature-level issues?

What is in scope for the Developer Wishlist?
Every idea submitted for the Developer Wishlist should meet some scope and concept criteria.
 * Developer-focussed — 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. 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 wishes
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.

If you want to propose a wish, please check whether a task about it exists already. If you find one, the first step is to add the  tag... More instructions coming soon.

Vote wishes
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.

Where is it going to be advertised?

 * mailing lists (wikitech-l, mediawiki-l/mediawiki-announce, mediawiki-api/mediawiki-api-announce, wikitech-ambassadors, possibly anything else with a decent number of subscribers)
 * banner campaign (mediawiki.org, wikitech, possibly other wikis?)
 * messages to technical village pumps
 * Tech News
 * Phabricator?
 * gerrit?
 * MediaWiki Facebook + Linkedin group(s?)
 * Paid ads? (Stackoverflow can run tag-specific ads; Linkedin, Facebook can run skill-specific ads)
 * IRC messages?
 * direct emails based on Phab/gerrit/whatever account information?