Community Wishlist Survey/How to create a good proposal
What makes a good proposal? These instructions are to ensure the proposals have the best chance at being selected for completion.
Within the Community Tech area of activity
The proposal should be about a technical need of active Wikimedia editors. It should require engineering work and NOT be about a policy or social change.
The Community Tech team declines proposals if they |
Proposals requiring engineering work include |
---|---|
|
|
Less than a year-long project, more than a bug
The Community Wishlist Survey is limited to the capabilities of the Community Tech team. The team is grateful for "big ideas" for the Foundation and doesn't ignore them.
The team is grateful for "big ideas" for the Foundation and doesn't ignore them. However, some proposals require a dedicated team other than Community Tech.
However, some proposals require a dedicated team other than Community Tech. They will be moved to a separate page and will not be voted upon. Later, the link to that page will be shared with other Wikimedia Foundation teams.
Examples:
|
|
Pick one specific problem and describe it in detail
Provide context around why the problem is important for users. A good proposal explains exactly:
- What the problem is,
- Who's affected by it.
- Add screenshots, links, and talk pages detailing the discussion about the problem space, if possible.
This will help Community Tech to understand where to begin their work.
Don't just say that "(x feature) is out of date", "needs to be improved", or "has a lot of bugs". That's not enough information to figure out what needs to be done.
Proposals may be submitted in any language. Community Tech encourages the volunteers to translate them so everyone can read and vote on it more easily. Read more on Review phase.
Examples:
|
Don't worry about finding the solution
You don't have to suggest ways for resolving the problem. It will be the Community Tech task to find solutions.
Prescribing the solution can sometimes be a constraint. For example, voters could mistakenly support a solution that later in the year could turn out to be impossible to build, and Community Tech would solve the problem differently.
Examples:
- Tags (ala evernote, searchable, catagorising) (no information on the problem)
- Bulk upload program (no information on the problem)
Talk to other community members
You may want to bring attention to your idea, and be part of a conversation about the idea happening elsewhere. Gather feedback and share the proposal. You can do this early on, before the voting phase. This way, contributors can know about the problem and remember to participate and vote for it when the time comes.
Also, see our promotional materials. You may use them.
Avoid proposals that were declined in the past
Here's a list of some of the projects that got many votes. Community Tech was committed to work on them but had to decline them. It is unlikely, if not impossible, that the team could work on them this year.
Survey edition | Rank in the results | Projects | Explanation |
---|---|---|---|
2019 | #2 | Dark mode | Overlaps with another team's project. The overlapping project is Desktop Improvements. Read more. |
2019 | #6 | Put mw.toolbar back | The issue had largely been resolved without any Community Tech intervention. Also, it is the Community Tech policy not to undo changes made by other teams. Read more. |
2019 | #8 | Article reminders | This is too technically complex. Also, it would have to be done by another Wikimedia Foundation team. There are other ways to see the same result. Read more. |
2019 | #10 | 2FA available for all concerned editors | This is too technically complex. Also, it would have to be done by another Wikimedia Foundation team. Read more. |
2017 | #6 | Article Alerts for more languages | This is too technically complex. Also, the Community Tech is not able to build and maintain such a tool. Read more. |
2016 | #1 | Global gadgets | This is too technically complex. Also, the Community Tech is not able to build and maintain such a tool. |
2015 | #3 | Central repository for gadgets, templates, and Lua modules | |
2015 | #6 | Allow categories in Commons in all languages | Overlaps with another team's projects. The overlapping projects are Structured Data on Commons and Structured Data Across Wikimedia. |
2015 | #4 | Cross-wiki watchlist | This is too technically complex. Read more. |
2015 | #8 | Global cross-wiki talk page | Overlaps with other teams' projects. The overlapping projects are Flow/Structured Discussions and Cross-wiki notifications. Read more. |
2015 | #10 | Add a user watchlist | Used in bad faith, this tool could make it easier to harass users. Read more. |