User:SGrabarczuk (WMF)/CWS22/FAQ

Community Wishlist Survey 2022

edit

January 3 - February 4

edit

Participation

edit

Why should I participate?

edit

Have you ever needed to see an improvement in the functionality of the Wiki software? Do you have an idea for a new tool to make the platforms more usable and functional? Do you want to support someone else's idea for such an improvement? Participating in the Survey is just the way to make that happen.

By participating in the Community Wishlist Survey, you can affect what platform changes the Community Tech, a Wikimedia Foundation team is working on. You can also work with the Community Tech to build these tools.

How can I participate?

edit

You can participate in multiple ways. Technical knowledge or many years of wiki experience are not necessary:


People with registered accounts on any of the Wikimedia projects:

Proposing an idea for an improvement
(read more about what types of proposals are the best)

Voting on the proposals once the voting phase begins
(three weeks after the Proposal phase opens)

Participants can vote for as many proposals as they want.

Anyone:

Discussing ideas on their proposal pages to make them better

Translating documentation and/or the proposals to help more people participate

Spreading the word about the Wishlist or individual proposals to help more people participate

Proposal phase

Review phase Voting phase After voting
10 January – 23 January 2022

What happens during the proposal phase?

edit

In the proposal phase, contributors from every project and language can submit proposals for features and fixes that you'd like to see in 2022.

Community Tech limit the number of proposals per user to four. If you have more than four ideas, feel free to encourage others to propose an idea.

How to create a proposal

edit

In a nutshell

edit

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

edit

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

edit

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

edit

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

edit

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

edit

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

edit

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.

<Social media materials>

Wishes declined in the past

edit

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!


What happens after the proposal is submitted?

edit

The community can collaboratively work on a proposal that presents the idea in a way that's most likely to succeed in the voting phase.

When a proposal is submitted, everyone is invited to comment on that proposal, and help to make it better — asking questions, and suggesting changes.

Similar proposals can be combined; very broad proposals should be split up into more specific ideas.

The goal is to create the best possible proposal for the voting phase.

The person who submits a proposal should expect to be active in that discussion, and help to make changes along the way.

Can I resubmit a proposal from previous surveys?

edit

Yes.

If you decide to copy a proposal from the old survey into the new survey, Community Tech expects you to "adopt" that proposal—meaning that you'll be actively participating in the discussion about that idea, and willing to make changes to the proposal in order to make it a stronger idea when it moves to the voting phase.

You may also submit some proposals that were archived in past years. For example, you may go through unclear proposals, describe them better, and submit them.

It's helpful if you want to post a link to the previous discussion, but please don't copy over the votes and discussion from last year. If there are good points that people made in last year's discussions, include the suggestions or caveats in the new proposal.

If a wish was declined by the Community Tech team, it is not eligible for another submission unless it has been changed significantly.

Examples:

Can I work on an idea before the proposal phase?

edit

Yes.

The 2022 edition starts in January. You can start working on an idea using the Community Wishlist Survey sandbox. This may allow you to make the details public and invite others to draft an idea with you.

What does "out of scope" mean?

edit

It means out of the area of activity of the Community Tech team.

See also How to create a proposal for detailed explanations.

Proposal phase

Review phase

Voting phase After voting
17 January – 28 January 2022


After the proposal phase, the Community Tech team will review the proposals before the voting phase begins.

The team checks if any proposals have to be declined. If there are any issues that prevent proposals from being accepted into the voting phase, they try to contact the proposals' authors and ask additional questions.

If a proposal is correct, Community Tech members mark it for translation. Then, anyone can translate the proposal to make it understandable for more people.

Proposal phase Review phase

Voting phase

After voting
28 January – 11 February 2022

How do I vote?

edit

The only votes that are counted are Support Support votes.

The final list of wishes will be ranked in order of the most Support votes. If you are the proposer, a support vote is automatically counted for your proposal.

Participants can vote for as many proposals as they want. To ensure fair voting, only registered users can vote, and votes by very new accounts may be removed.

Can I post an Oppose, Neutral, or discuss?

edit

Yes.

Discussion is encouraged during the voting phase. If you want to post an Oppose Oppose or Neutral Neutral vote with a comment, then feel free to do so.

These discussions can help people to make up their mind about whether they want to vote for the proposals. The discussions also provide useful input to guide the work that will happen through the year.

Can I ask others to vote for my proposal?

edit

Yes.

You've got an opportunity to sell your idea to as many people as you can reach. Feel free to reach out to other people in your project, WikiProject, affiliate, or group of users. A good-faith "get out the vote" campaign is absolutely okay.

Proposal phase Review phase Voting phase

After voting

14 February 2022

How do you select which proposals to work on?

edit

Once the survey is closed, the Community Tech team will choose some proposals from the survey to work on.

Popularity of a proposal is the main factor in the selection decision, but not the only one. If a proposal has many support votes, Community Tech also takes into consideration:

Technical complexity

Product and Design complexity

Historically underserved needs and community impact

Software engineering effort that needs to be invested.

This includes reviewing code, legal, and security limitations, database updates, etc.

Effort that needs to be invested into user testing.

Should the launch be gradual or not gradual? How long should it take?

Is the proposal about under-supported Wikimedia projects?

Would it work across different wikis?

How many people would benefit from the improvement?

Is it about the support for non-textual content?

The final score is a combination of all the above. Next, the Community Tech begins to work on the proposals with the highest final scores.

Some of the wishes may be addressed by volunteer developers or other development teams.

Why is the number of votes not the only criterion?

edit

There was a time when Community Tech promised the “top N” wishes and tried to grant them between July and June. Sometimes wishes took longer than anticipated due to complexity. Other times it meant the team was rushing to get something finished. Also, this meant the team could get into situations of “over-promising” which could limit volunteers' trust.

In 2020, Community Tech stepped away from promising a total number of wishes they would grant.

How can I stay informed about the progress of the work?

edit

What if a lot of people vote to support a bad idea?

edit

The Oppose and Neutral votes are very helpful in raising potential downsides. For controversial wishes, Community Tech balances the voting with a more consensus-based review.

As an example, this worked in the 2015 survey: The wish to "add a user watchlist" received a lot of votes but also some heartfelt Oppose votes. Community Tech listened to all sides, and made a decision on whether to pursue the project or not.

Why are you doing a new survey this year…

edit

…instead of addressing other wishes from older surveys?

Community Tech wants to keep our priorities in line with the communities' priority needs!

As software evolves, so do the user’s needs. Sometimes a really good wish from last year isn’t so important anymore, or the description has simply become outdated. Conducting the survey annually helps reconfirm what the community needs.

Do you only build new things?

edit

No.

Community Tech also spends part of our time maintaining features they built in the past. This may, and sometimes does affect how effectively the team finishes their work on new changes.

What's the history of the CWS?

edit
Danny Horn presenting the CWS at Wikimania 2017
The creation of the Community Tech team is a direct outcome of requests from core contributors for improved support for moderation tools, bots, and the other features that help the Wikimedia projects succeed.

This survey process was developed by Wikimedia Deutschland's Technical Wishes team, who run a wishlist survey on the German-language Wikipedia.

In November, 2015, Community Tech conducted the first Community Wishlist Survey, to help identify the features and fixes that are most important to Wikimedia editors. The team invited contributors from all Wikimedia projects to submit proposals. After two weeks of collecting proposals, the team asked them to vote on the proposals they were most interested in. The process has been repeated every year since.

How can I change things for next year?

edit

If you've got suggestions to improve the process, feel free to write on the survey talk page. We'd be happy to talk about any ideas that you have!

Contact

edit

Questions or feedback are welcome. You can ask them on the talk page or at Talk to Us meetings.

You can also contact: