Total: 72 proposals, 423 個貢獻者, 1749 support votes
All phases of the survey begin and end at 18:00 UTC.
- 提交、討論同修訂提案: 10月21日 – 2019年11月11日
- 社群技術審查同組織提案 （包括咗留畀維基媒體技術會嘅時間設定）: 11月5日 – 2019年11月19日
- 提案投票: 11月20日 – 2019年12月2日
- 結果公佈: 2019年12月6日
The Community Tech team is a Wikimedia Foundation team focused on the needs of active Wikimedia contributors for improved curation and moderation tools. The projects that we primarily work on are decided by the Wikimedia community, through the annual Community Wishlist Survey.
Once a year active Wikimedia contributors can submit proposals for features and fixes that you'd like our team to work on. After two weeks, you can vote on the ideas that you're most interested in.
The proposal phase is the first two weeks of the survey.
In the proposal phase, contributors from every project and language can submit proposals for features and fixes that you'd like to see in 2020. Proposals may be submitted in any language. If you submit a proposal in a language other than English, we will attempt to get it translated so everyone can read and vote on it more easily.
Proposals should be discrete, well-defined tasks that will directly benefit active Wikimedia contributors. Proposals should answer the following questions:
- What is the problem that you want to solve?
- Which users are affected? (editors, admins, Wikisource editors, etc.)
- How is this problem being addressed now?
- What are the proposed solutions? (if there are any ideas)
Your proposal should be as specific as possible, especially in the problem statement. 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. A good proposal explains exactly what the problem is, and who's affected by it. It's okay if you don't have a specific solution to propose, or if you have a few possible solutions and you don't know which is best.
Submitting a proposal is just the beginning of the process. The two-week proposal phase is a time that 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. Because of that, we're going to limit proposals to three per account. If you post more than three proposals, we'll ask you to narrow it down to three. Bring your best ideas!
Similarly, only registered users can make proposals to ensure they can watchlist the discussion and respond to questions. Just as with voting, you should be an active editor on at least one Wikimedia project. If you do not meet this criteria, or you have hit your proposal limit but have more ideas, you can seek other users to adopt your proposals.
One more note: Proposals that call for removing or disabling a feature that a WMF product team has worked on are outside of Community Tech's possible scope. They won't be in the voting phase.
Yes, you may submit some proposals that didn't get enough support votes in past years, and deserve a second try.
If you decide to copy a proposal from the old survey into the new survey, we expect 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. As we said above, there's a limit of three proposals per person, and posting a proposal from last year counts.
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.
After the proposal phase, we take a break to review the proposals before the voting phase begins.
All active contributors can review and vote for the proposals that they want to support. You can vote for as many different proposals as you want. To ensure fair voting, only registered users can vote, and votes by very new accounts may be removed.
The only votes that are counted are 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.
However, lively discussion is encouraged during the voting phase. If you want to post an Oppose or 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.
A reasonable amount of canvassing is acceptable. 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 or user group. Obviously, this shouldn't involve sockpuppets, or badgering people to vote or to change their vote. But a good-faith "get out the vote" campaign is absolutely okay.
The Community Tech team may decline proposals that fail to meet the above criteria.
The 2020 Community Wishlist Survey is now complete! We want to thank everyone for their participation in this year’s survey. It was a very civil and smooth process, and we appreciate all of the help that we received. Now, we’re delighted to announce the top 5 wishes from the survey:
- Improve export of electronic books (Wikisource)
- New OCR tool (Wikisource)
- Migrate Wikisource specific edit tools from gadgets to Wikisource extension (Wikisource)
- Inter-language link support via Wikidata (Wikisource)
- Insert attestation using Wikisource as a corpus (Wiktionary)
Here’s what comes next: We’ll begin analyzing these five wishes after the new year. During our analysis, we’ll consider various factors, including possible dependencies and risks. Once we’ve completed this analysis, we’ll determine which wish to address first. We’ll create a project page on Meta-Wiki for that wish, which will outline the project vision. We’ll also ping all the wish voters, so everyone can share their suggestions and questions on the Talk page. From that point, updates will be found on the project page. The first project page should be launched in the next few months (no set date yet), but you can visit the Community Tech page for updates in the meantime.
As a team, our goal is to address every top wish in the Community Wishlist Survey. This means that we analyze each wish and determine if it’s workable (i.e., within scope, no major conflicts with other teams, etc). In many cases, the wish is workable. We then continue with the research and planning, followed by development, testing, and deployment. However, we sometimes identify significant issues or risks associated with a wish. In such cases, we investigate alternatives and ways to mitigate the risks. As a last resort, we sometimes decline certain wishes, but only after we rule out other options. Above all, we make sure to address each wish and share our findings with the community.
As this year draws to a close, we want to thank you, again, for participating in the survey! It was a fantastic experience for the team (and we hope for you too!). After the new year, we’ll begin reaching out with plenty of questions, ideas, and updates. We’re excited to begin the work to improve Wikisource and Wiktionary. Until then, we wish you a happy new year, and we look forward to collaborating with all of you!