User:SGrabarczuk (WMF)/CWS22/How to create a proposal

Community Wishlist Survey 2022

January 3 - February 4

How to create a proposal

In a nutshell

What makes a good proposal? These instructions are to ensure volunteers' 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.

Proposals requiring engineering work include	The Community Tech team declines proposals if they
Creating gadgets, bots, and wizards to help users in what they already do 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 Building tools for WikiProjects Identifying and fixing issues with most important old tools for experienced users, such as AbuseFilter Creating better documentation for these tools so that they can be better utilized	Only require doing edits on wiki, even if it's about edits in "technical" namespaces (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

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. 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:

Watchlist item expiration (large-ish)

Ping users from the edit summary (ideal size)

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

Wiktionary app (too large)

Wikivoyage app (too large)

Centralization of templates (too large)

Pick one specific problem and describe it in detail

Provide context around why the problem is important for experienced 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:

Better diff handling of paragraph splits

Show all active sessions

Use Wikidata to improve search

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)

Don’t invest in looking for 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)

Pick a title that reflects the problem

Titles are key during the voting phase. When volunteers are deciding what to vote for, they have to consider the proposal in hand against many others. If your title does not reflect the problem that it speaks about, volunteers may be misled when voting.

Avoid using abstract words.
Pick a descriptive title that reflects the problem.

Instead of saying “Improve the OCR tool” say “Make the transcription tools more correct”.

Examples:

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.

Wishes declined in the past

Hi everyone. We are the Wikimedia Foundation Web team. As you may have read in our previous message, over the past year, we have been getting closer to switching every wiki to using the new Vector 2022 skin. In our previous conversations with Wikisource communities, we had identified an issue with the Index namespace that prevented switching the skin on. This issue is now resolved.

We are now ready to continue and will be deploying on Wikisource wikis on March 25th.

To learn more about the new skin and what improvements it introduces, please see our documentation. If you have any issues with the skin after the change, if you spot any gadgets not working, or notice any bugs – please comment below! We are also open to joining the Wikisource Community meetings to talk to you directly. Thank you!