Průzkum přání komunity/Aktualizace/Výsledky v roce 2022

This page is a translated version of the page Community Wishlist Survey/Updates/2022 results and the translation is 25% complete.

2022

Ahoj všichni!

Anketa Seznam přání komunity 2022 je u konce! Rádi bychom poděkovali všem, kteří se letošního ročníku zúčastnili, a pod výsledky vyjádřili zvláštní poděkování těm, kteří do průzkumu přispěli vynikajícími příspěvky. Bez vás všech bychom to nedokázali!

Zajímá vás, co se bude dít dál? Seznamte se s naším procesem prioritizace a podívejte se na pořadí prioritizovaných návrhů pro tento rok.

Výsledky za rok 2022

Hlasování

Od 28. ledna do 11. února mohli přispěvatelé s registrovaným účtem hlasovat pro návrhy předložené dříve v lednu.

Průzkumu se zúčastnilo téměř 1600 uživatelů. Bylo podáno 467 návrhů, z toho 142 archivovaných, 55 větších návrhů a 270 návrhů, které se ucházely o hlasy účastníků. Podporu vyjádřilo 9554 hlasů, z toho 8387 hlasů pro soutěžící návrhy. Všem zúčastněným gratulujeme!

Výsledky hlasování jsou k dispozici na stránce Průzkum seznamu přání komunity 2022/Výsledky.

Prioritizace

Jak jsme napsali na FAQ stránce, technická popularita (tedy počet hlasů) je hlavním faktorem při rozhodování, na kterých návrzích budeme pracovat. Je to důležitý faktor, ale ne jediný. Třicet nejlepších návrhů jsme posuzovali ze tří hledisek: technické složitosti, složitosti produktu a designu a dopadu na komunitu.

Technická složitost

Naši inženýři odhadují, kolik úsilí by museli vynaložit na splnění přání. Upřednostňují méně složité (lépe proveditelné) projekty. Kdykoli není něco jasné, snaží se spíše nadhodnocovat než podhodnocovat.

  • Technická závislost - zjišťujeme, zda práce vyžaduje součinnost s jinými týmy nadace Wikimedia. Může se stát, že část práce musí být v plánu jiných týmů nebo že potřebujeme vstupy nebo zpětnou vazbu jiných týmů, než budeme moci přání dokončit. Příkladem jsou změny schématu, bezpečnostní revize, přidání nového rozšíření a aktualizace knihoven třetích stran.
  • Technický výzkum - ptáme se sami sebe, zda víme, jak přistupovat k určitému problému. Někdy potřebujeme zhodnotit a zvážit své možnosti, než začneme přemýšlet o řešení. Někdy si potřebujeme potvrdit, že to, co je třeba udělat, lze udělat nebo že je to v rámci toho, co platforma, na které pracujeme, zvládne.
  • Technické úsilí - ptáme se, jak dobře známe základní kód a jak velký nebo složitý může být úkol. Vysoké skóre náročnosti může také znamenat, že kód, s nímž budeme pracovat, je starý, křehký nebo má určitý stupeň technického dluhu, s nímž se budeme muset vypořádat, než začneme pracovat na našem skutečném úkolu.

Produkt a design

Podobně jako u výše uvedených hodnocení náš designér odhaduje, jaké úsilí je třeba vynaložit na dokončení projektu. Upřednostňují méně složité (lépe proveditelné) projekty. Kdykoli není něco jasné, snaží se spíše nadhodnocovat než podhodnocovat.

  • Výzkumné úsilí návrhu - snažíme se zjistit, jaká úroveň výzkumu je pro každý návrh potřebná. V tomto případě výzkum zahrnuje pochopení problému, a to buď na samém začátku prostřednictvím počátečních zjišťovacích prací (rozsah a podrobnosti projektu, průzkumy nebo rozhovory se členy komunity), nebo později v průběhu procesu prostřednictvím komunitních diskusí a testování použitelnosti. (např. jak uživatelé přispívají s touto novou funkcí a bez ní).
  • Visual design effort – a significant number of proposals require changes in the user interface of Wikimedia projects. Therefore, we check to estimate the change of the user interface, how many elements need to be designed and their complexity. For instance, using existing components from our design system or creating new ones, keeping in mind how many states or warnings need to be conceived to help guide users, including newcomers.
  • Workflow complexity – we ask ourselves how does this particular problem interfere with the current workflows or steps in the user experience of editors. For example, a high score here would mean that there are a lot of different scenarios or places in the user interface where contributors might interact with a new feature. It can also mean that we might have to design for different user groups, advanced and newcomers alike.

Community impact

In contrast to the two perspectives described above, this part is about equity. Practically, it's about ensuring that the majorities aren't the only ones whose needs we work on.

Depending on this score, proposals with similar numbers of votes and similar degrees of complexity are more or less likely to be prioritized. If a given criterion is met, the proposal gets +1. The more intersections, the higher the score. This assessment was added by our Community Relations Specialist.

  • Not only for Wikipedia – proposals related to various projects and project-neutral proposals, are ranked higher than projects dedicated only to Wikipedia. Autosave edited or new unpublished article is an example of a prioritized proposal.
  • Sister projects and smaller wikis – we additionally prioritize proposals about the undersupported projects (like Wikisource or Wiktionary). We counted Wikimedia Commons as one of these. Tool that reviews new uploads for potential copyright violations is an example of a prioritized proposal.
  • Critical supporting groups – we prioritize proposals dedicated to stewards, CheckUsers, admins, and similar groups serving and technically supporting the broader community. Show recent block history for IPs and ranges is an example of a prioritized proposal.
  • Reading experience – we prioritize proposals improving the experience of the largest group of users – the readers. Select preview image is an example of a prioritized proposal.
  • Non-textual content and structured data – we prioritize proposals related to multimedia, graphs, etc. Mass uploader is an example of a prioritized proposal.
  • Urgency – we prioritize perennial bugs, recurring proposals, and changes which would make contributing significantly smoother. Fix search and replace in the Page namespace editor is an example of a prioritized proposal.
  • Barrier for entry – we prioritize proposals about communication and those which would help to make the first contributions. Show editnotices on mobile is an example of a prioritized proposal.

The leaderboard

These scores may change when we start working on the proposals. As we explained above, we have tried to overestimate rather than underestimate. Check out the proposals, in order of prioritization:

Wish Popularity Rank Votes Engineering Score Product and Design Score Community Impact Score Prioritization Score
Autosave edited or new unpublished article 29 69 1.0 0.3 2 2.66
Get WhatLinksHere's lists in alphabetical order 22 74 1.3 0.3 2 2.63
Enable negation for tag filters 26 71 2.0 0.3 2 2.47
Fix search and replace in the Page namespace editor 11 93 2.3 0.7 2 2.47
Improve SVG rendering 5 108 4.0 0.8 3 2.44
Notifications for user page edits 2 123 1.3 1.7 1 2.38
Check if a page exists without populating WhatLinksHere 14 89 2.7 0.7 2 2.38
Tool that reviews new uploads for potential copyright violations 4 109 4.3 2.7 4 2.21
IPA audio renderer 9 97 3.0 2.7 3 2.15
floating table headers 24 73 1.0 2.7 2 2.14
Mass-delete to offer drop-down of standard reasons, or templated reasons. 25 72 1.0 2.7 2 2.14
Formatting columns in table 19 77 4.0 0.3 2 2.11
Select preview image 8 100 3.0 2.0 2 2.07
Add DeepL as a machine translation option in ContentTranslation 20 75 3.3 0.0 1 2.06
Change default number of search results displayed 12 92 2.0 1.7 1 2.05
Better diff handling of paragraph splits 1 157 3.3 2.3 1 2.04
Table sorting on mobile 17 83 2.3 1.7 1 1.92
Enhanced Move Logs 10 96 2.7 2.3 1 1.79
Gadget: Who is active 26 71 1.3 4.0 2 1.76
Show recent block history for IPs and ranges 3 120 4.0 3.7 2 1.61
Reminders or edit notifications after block expiration 20 75 3.3 3.2 2 1.57
Autosuggest linking Wikidata item after creating an article 12 92 3.3 3.8 2 1.53
Full page editing 30 67 2.0 3.7 1 1.42
Allow filtering of WhatLinksHere to remove links from templates 6 106 5.0 3.3 2 1.40
Automatic duplicate citation finder 6 106 3.0 4.2 1 1.36
VisualEditor should use human-like names for references 22 74 3.3 4.0 1 1.12

In addition, if you are interested in viewing a more granular version of the sub-components that make the prioritization scores, we've made the individual sub-components public:

These are proposals which we found will be worked on by other teams at the WMF or third-party open source when we went through the process of estimating their complexities:

Tasks for other Product teams
Wish Popularity Rank
Deal with Google Chrome User-Agent deprecation 15
Show editnotices on mobile 15
Categories in mobile app 18
Mass uploader 28

Larger suggestions

Thank you for 55 Larger suggestions, nearly 1200 votes you cast for them, and all the comments you added! You dedicated a lot of time, and this is a huge amount of important knowledge for us.

Why did we create this category and what will we do next?

From the beginning in 2015, we have been explaining that the Community Wishlist Survey has a specific scope. Not every good proposal submitted in the first phase can become our project. We avoid committing to something we cannot do.

At the same time, it is impossible (and not fair!) to expect that submitted proposals that were great ideas but out of our scope should end up in the Archive. In past editions, we archived proposals not meeting the criteria before voting. This time, we decided to create the "Větší návrhy" category and put it next to the regular categories. We wanted to respect the effort put into submitting them, and allow you to express your interest in these projects even if we won't be able to work on them. To avoid misconceptions, we didn't put the larger suggestions onto the Results page.

Now, having these suggestions and votes, we will be able to understand your needs better. We will share the results with our leaders and colleagues at the Product department of the Wikimedia Foundation. We can't promise they will work on these projects soon. They will be informed, though, and perhaps will be inspired when making their plans.


Gratitude

We would like to express our deepest gratitude to all participants. The Community Wishlist Survey is your success as well.

Some of you helped us to improve the Survey before it began. Some spent an outstanding number of hours during the Survey. They were translating the documentation and the proposals, discussing the proposals, and encouraging others to take part. Some decided to take part for the first time, and among them, there were some who affected the final results in a way no one could have expected.

We are not able to make a full list of everyone who deserves to be mentioned here. Heartfelt appreciation to everyone who helped us on social media, within their own communities, and was less likely to be noticed by us.

If you have proposals for the next Survey

...and don't want to forget them, add them to the sandbox. Proposals saved there do not count as submitted, but they will be in other people's minds and will be less likely to be abandoned.

Follow us

Thank you!

Natalia, Karolin, Dayllan, MusikAnimal, Sam, Harumi, Szymon, Nicolas, Dom, Ima, and James – Community Tech