Developer Wishlist
You can view the results or discuss how to follow up.
What is the Developer Wishlist?
Despite its importance, DX has not received 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. 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. See FAQ for more.
How does the voting process work?
There are no specific voting criteria: if you consider yourself a MediaWiki or Wikimedia developer, your vote is welcome. This includes bot owners, people working on external tools or gadgets or Lua modules or complex templates, people using the Wikimedia APIs in their own project, people working on developer community outreach or documentation, etc. In case of doubt, err on the side of voting.
The process is a simple approval vote: you can vote on as many proposals as you want (but please only once on each), and the results will be sorted by the total number of supporting votes they receive. There are no "oppose" votes; if you think something is a bad idea, please explain it on the linked Phabricator task instead, so that people intending to work on the proposal in the feature can find your arguments and take them into account.
Votes are counted in the Support section of each proposal. There is also an Endorsements section, which is for feedback on how the problem affects you; it is informational and does not influence the results (but developers picking tasks from the wishlist to work on might take it into account). If you have personally encountered the problem that the proposal is trying to solve (while developing, or while helping/mentoring other developers), please tell about it in the Endorsements section. If you feel you can speak for your whole group (user group, team/department, chapter, institution etc.) on how the problem affects them, you are encouraged to do so. You still can (and should) vote on the proposal after endorsing it.
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!
Timeline
- 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.