Community Wishlist/How to write a good wish
How to write a good wish
[edit]We would like to hear about suggestions for improvements to Wikimedia projects. As Commtech, we want to be able to split our work into smaller bits, wishes should be bigger than a bug, but take less than a year in terms of engineering work. In any case, we will try to triage work collectively as a Foundation and forward it to the relevant internal stakeholders to raise awareness about community needs.
To be able to prioritise work, as we need some way to prioritise, we cross-check incoming wishes with strategic goals targeted through the Annual Plan. It’s not a prerequisite to read the Annual Plan before making a wish, but you can do so if you want to further understand the triage process. As we are aware of the fact that sunsetting a tool can be a considerable amount of work, we do also take in wishes that suggest removing technology to understand the interest.
It’s unlikely we will work on technical edits or work that requires policy changes. In many cases, creating a whole new application or algorithm might be out of scope. The WMF will not create gadgets or bots, but you're welcome to add wishes for gadgets/bots for consideration by members of the community.
While there is no official rubric for writing a "good wish," we encourage wish proposers to articulate a single problem they face without providing an explicit solution, so that volunteers and staff have space to problem-solve together.
Wishes that demonstrate empathy and show a user's challenges and goals avoids the pitfalls of being too niche or specific, and where other users may nitpick the solution.
In the example below, both the problem-led and solution-led wish examples hint at improving "new editor" experiences.
The problem-led example leaves the solution open-ended and invites collaboration, whereas the solution-led example might receive negative feedback from contributors who resist renaming a user sandbox.
Thus, the problem-led wish might have a higher chance of being assigned to a focus area.
| Problem-led Wish (encouraged) | Solution-led Wish (discouraged) | |
|---|---|---|
| Title | Make it easier for newcomers to create their first article | Rename sandbox to “Draft editor” |
| Description | Especially for new editors, it can be hard to find a user sandbox. Once they find their sandbox, new editors see a number of disclaimers that make it hard to gain confidence in writing a good quality article. This impacts a newcomer's ability to onboard to Wikipedia and feel confident as a contributor. This is in part by design – we need to be mindful of patroller workflows – but the experience hinders our ability to onboard new editors. | The term “Sandbox” is confusing to new users. Let's rename it to “Draft editor” so that people are more likely to draft an article. |
| Type | System change | Feature request |
| Project | Wikipedia | Wikipedia |
| Users affected | New editors and, downstream, patrollers who review new edits | Editors |
| Phab tasks | optional | T123456 |
Wishes that combine multiple problems should also be avoided. It may be that voters agree with some problems and ideas, but disagree on others. Likewise, the Foundation and stakeholders may find multifaceted wishes challenging to tackle if they involve multiple software components.
