Istraživanje o željama zajednice 2021. godine
Ukupno: 268 prijedloga, 1773 doprinositelja, 8596 glasova podrške
Starting this July 2021, the team will start engineering work on the following wishes:
We will also begin the product and design research for the following wish:
We fully expect to be able to complete more wishes than the above. The above list is only what is in our plate starting this July.
How did we arrive at our next steps? We recently completed the 2021 Wish prioritization process.
Sve etape ovoga istraživanja počinju i završavaju u 18,00 UTC (KSV).
- Predloži, diskutiraj i pregledaj prijedloge: 16. studenoga – 30. studenoga 2020.
- Tehnički tim Zajednice pregledava i ustrojava prijedloge: 23. studenoga – 7. prosinca 2020.
- Glasajte za prijedloge: 8. prosinca – 21. prosinca 2020.
- Objava rezultata: 23. prosinca 2020.
We're excited to share an update on the Community Wishlist Survey 2021. This will be our sixth annual survey, and we've decided to update the process:
One backlog per year: The team will now have one backlog per year. This means that, each year, volunteers will vote on our new backlog. They can propose new wishes or re-propose old ones. Once the voting is complete, we'll have one new backlog. This is a change from our old format, which allowed us to work on multiple backlogs per year. With this change, we can simplify our work, ensure the most important wishes get addressed, and reassess old wishes each year.
Status of remaining 2019 and 2020 wishes: There are 3 remaining wishes from the 2019 and 2020 surveys that we have not worked on or addressed yet. Since they received a high number of votes, we will include them in our 2021 backlog. In the 2019 wishlist, there are 2 wishes that will be included: section name in diff and named references in VE. In the 2020 wishlist, there are 4 wishes that we have already begun or have been worked on. There is 1 wish from the 2020 wishlist that we have not worked on yet, so it will also be included in the 2021 backlog: insert attestation using Wikisource as a corpus. You can review our status report for the 2019 wishlist.
Research and regular updates to replace "top 10": We have decided to no longer commit to a number (such as "top 5" or "top 10") in advance. Here's why: Software development teams usually conduct extensive research before committing to a project. This way, they can determine if the project is feasible, understand how long the project may take, and identify potential risks. With the current wishlist process, we don't do that, which often leads to delays, stress, and confusion. We want to fix this.
With the new system, we'll research projects before committing to them. We will evaluate wishes in the order of popularity, going from the top down. During our research phase, we'll analyze the following criteria: popularity (i.e., number of votes), size and scope of the project, level of technical feasibility, risks and dependencies, and potential conflicts with other teams. Once our analysis is complete, we'll share our findings. This means that we'll still work on multiple projects per year. We'll just be more communicative about what we can or cannot take on (and why), and we'll share updates over the course of the year about our roadmap.
Separate leaderboards for categories: We will keep the normal structure of displaying all proposals, sorted by the number of votes, in the main leaderboard. In addition, we will now have separate leaderboards for each category. This way, we can work on proposals that are popular for large communities (from the main leaderboard) and underrepresented communities (from specific leaderboards). We’ll use the criteria described above to help select which proposals we work on.
Why these changes?: We knew that the wishlist process was ready for an upgrade. Wishes have grown bigger and more complex over the years, and we wanted to improve our communication with volunteers. Additionally, we wanted to continue to address the wishes of smaller communities (as we did in the 2020 wishlist) and the high-impact wishes of all Wikimedians (as we did in previous wishlists). This led to a series of conversations on how we could improve the process. From these conversations, we came up with these changes. Overall, we hope these changes make the wishlist process more transparent, sustainable, and impactful. This way, the survey is strengthened for years to come. Thank you, and we look forward to reading your proposals!
Tehnički tim zajednice tim je Zaklade Wikimedija koji se fokusira na potrebe aktivnih suradnika Wikimedije s ciljem izdavanja poboljšanih alata za održavanje i moderaciju. Zajednica Wikimedije kroz godišnje istraživanje o željama zajednice odlučuje na kojim ćemo projektima primarno raditi.
Aktivni suradnici Wikimedije mogu jednom godišnje podnijeti prijedloge funkcija i popravaka za koje smatraju da bi se njima trebao pozabaviti naš tim. Nakon dva tjedna možete glasati za ideje koje Vas najviše zanimaju. Pet najpopularnijih želja istražit će i njima se baviti Tehnički tim zajednice. Možda će se nekim od drugih popularnih želja pozabaviti neki drugi razvojni tim.
Once the survey is closed, the Community Tech team will choose some proposals from the survey to work on. Proposals will be selected based on the following criteria: popularity (i.e., number of votes), size and scope of the project, level of technical feasibility, risks and dependencies, and potential conflicts with other teams. Some of the wishes may be addressed by volunteer developers or other development teams.
Ovaj proces istraživanja razvio je tim Tehničkih želja Wikimedije Njemačka, koji ostvaruje istraživanje želja na wikipediji na njemačkome jeziku. Globalni projekt istraživanja želja podupire tim odnosa sa zajednicama.
Razdoblje predlaganja traje prva dva tjedna istraživanja.
Tokom razdoblja predlaganja, doprinositelji iz svakog od projekata i jezičnih izdanja mogu podnositi prijedloge za ostvarenja i popravke koje bi željeli vidjeti u 2021 godini. Prijedlozi mogu biti podneseni na bilo kom jeziku. Ako podnesete prijedlog u nekom drugom jeziku (osim engleskoga), pokušat ćemo priskrbiti prijevod kako bi se svi mogli upoznati s prijedlogom na što jednostavniji način, kao i glasati o njemu.
Prijedlozi bi trebali biti diskretni i dobro definirani zadatci koji će izravno koristiti aktivnim Wikimedijinim suradnicima. Prijedlozi bi trebali odgovoriti na sljedeća pitanja:
- Koji problem želite riješiti?
- Koji su korisnici zahvaćeni ovim problemom? (suradnici, administratori, uređivači Wikizvora, i sl.)
- Kako je ovaj problem trenutno riješen?
- Koja su predložena rješenja? (ako postoje)
Vaš prijedlog trebao bi biti što je više moguće podrobniji, a posebno u definiciji problema. Nemojte napisati samo da "(mogućnost X) nije ažurna", "potrebno je poboljšanje" ili "postoji mnogo programskih grešaka". To nije dovoljno podataka za razaznati što je potrebno učiniti. Dobar prijedlog objašnjava točno što je problem, te tko je pogođen njime. U redu je ako nemate za predložiti neko posebno rješenje, ili ako imate nekoliko mogućih rješenja ali ne znate koje bi bilo najbolje.
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.
Da, definitivno postoje prijedlozi koji prošle godine nisu primili dovoljan broj glasova podrške, ali zaslužuju drugu priliku.
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.
Each proposal should meet the following criteria:
- The proposal is about a technical change and not for a policy or social change
- The proposal is about the problem and not necessarily ask for a specific solution
- The proposal is a well-defined problem and not a mix and match of different unrelated issues
- The proposal is not already in another team's roadmap or has not been declined by other teams in the past
- The proposal has not been declined by Community Tech or other teams in the past
- The proposal is within the team's scope
The Community Tech team may decline proposals that fail to meet the above criteria.
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 “Mogu li ponovo dati prijedlog iz prethodnoga istraživanja?” above.