Community Wishlist Survey/How to create a good proposal

Translate this page

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
Only require doing edits on wiki, even if it's about "technical" edits (in templates, modules, etc.) Are already in Wikimedia Foundation teams' plans Were declined by Community Tech or other Wikimedia Foundation teams in the past Call for removing or disabling a feature that a Wikimedia Foundation team has worked on	Building tools for Wikimedia projects Identifying and improving functionality of important unsupported tools Creating better documentation for these tools so that they can be better used Creating gadgets, bots, and wizards to help users in what they already do Building tools for WikiProjects Modifying existing gadgets and bots so that they can work on more projects Converting heavily-used code written by the community (gadgets and user-scripts) into part of the MediaWiki software

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. However, some proposals require a dedicated team other than Community Tech.

These proposals 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:

Make SecurePoll accessible through local wikis (too large)

"POV Detector" for articles (too large)

Make a mobile application for Wikivoyage (too large)

Watchlist item expiration (large-ish)

Ping users from the edit summary (ideal size)

Copy and paste from diffs (small-ish but not too small)

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:

Add Better Bots (not precise enough and reading between the lines, too large)

Make wiki easier for most people (not one problem, but a principle for a lot of changes)

Implement Artificial intelligence (not one problem, but a principle for a lot of changes)

Better diff handling of paragraph splits

Show all active sessions

Use Wikidata to improve search

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, catagorizing) (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.