Komunuma enketo pri listo de deziroj 2016
Total: 265 proponoj, 1132 kontribuantoj, 5037 subtenaj votoj
Curious about what happens next? Check out the Community Wishlist Survey 2016 FAQ.
- Donu, pridiskutu kaj reviziu proponojn: Nov. 7–20, 2016
- La Teknologia Komunumo recenzas kaj ordigas la proponojn: Nov. 21–27
- Votado por la proponoj: Nov. 28–Dec. 12
- Survey analysis: Dec. 13–14
- Rezultoj publikiĝas: 15-a de decembro
- Trarigardo kaj takso de pintaj deziroj per la komunuma teknika teamo: fino de decembro
- Prezento de la komenca takso: komenco de januaro 2017
- Laborado pri deziroj: januaro–decembro 2017!
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.
Quite a few! Here's a brief list.
- Wish #2: Improved diff comparisons—The nightmare diff in the proposal was a small change made in a huge paragraph, which highlighted the paragraph and obscured the change. A WMF developer updated the diff engine; now it shows what actually changed.
- Wish #5: Numerical sorting in categories—Community Tech implemented support for numerical sorting and has deployed the feature to 18 different wikis so far; we're currently offering the feature to any wikis that want to try it.
Community Tech is currently working on wish #4, Cross-wiki watchlist, and there are more wishes that have been addressed by volunteers and other teams.
Some of the top 10 wishes weren't feasible for various reasons; you can see all the wishes on the Survey Results page, with links to project pages and discussions.
La propona fazo konsistas el la unuaj du semajnoj de la enketo.
In the proposal phase, contributors from every project and language can submit proposals for features and fixes that you'd like to see in 2016. 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. Proponoj enhavu respondojn pri la jenaj demandoj:
- Kio estas la problemo kiun vi volas solvi?
- Kiujn uzantojn rilatas la problemo? (redaktantoj, administrantoj, Vikifontaro-redaktantoj ktp.)
- Kiel oni traktas la problemon nun?
- Kiuj estas la proponataj solvoj? (se estas iuj ideoj)
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.
Sendi proponon estas nur komenco de la proceso. La dusemajna propona fazo estas la tempo dum kiu la komunumo povas kune prilabori kaj prezenti ideon de propono tiel, ke ĝi sukcesos dum voĉdona fazo. Kiam la propono estas sendita ĉiuj estas invititaj komenti kaj helpi plibonigi ĝin - per demandado kaj sugestoj pri ŝanĝoj. Similaj proponoj povas esti kombinitaj; tre vastaj proponoj povas esti dividitaj en pli specifajn partojn. La celo estas krei proponon, kiu plej verŝajne sukcesos dum voĉdona fazo.
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.
Jes, vi povas submeti proponon kiu ne havis sufiĉon da subteno en pasintaj jaroj, sed meritas duafojan provon.
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.
Note also that the proposals are occasionally rotated to ensure all get fair visibility. This is done by simply moving the top proposal to the bottom.
It's common that most of the proposals that end up in the top 10 are for the biggest projects — the big Wikipedias, and Commons. There are many smaller groups and projects that don't have enough "voting power" to boost their proposal into the top 10, but are doing important work for our movement.
Our team has a commitment to work on projects that help out smaller groups, including campaign and program organizers, GLAM participants, smaller projects like Wikisource and Wiktionary, and stewards and CheckUsers.
Having smaller projects' proposals in the Wishlist Survey is important — it helps our team and the Wikimedia Foundation broadly know what people in smaller groups need. So yes, please come and post your proposals, even if you don't think you'll get into the top 10!
The Support-vote rankings create a prioritized backlog of wishes, and the Community Tech team is responsible for evaluating and addressing the popular wishes. To do that, Community Tech investigates all of the top wishes, and look at both the technical and social/policy risk factors.
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.
…instead of addressing other wishes from older surveys?
The main reason why we're making the survey an annual event is that we want to include more people! More people know about the team and the survey now, and after a year where many of the top wishes were completed, we're expecting that people will be even more interested and excited about participating. We want to give everyone a chance to bring new ideas.
We also want to make sure that older ideas are still wanted. 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.
If there are wishes from last year's survey that you think deserve another shot, see “Ĉu mi povas resubmeti proponon jam proponitan en antaŭaj enketoj?” above.