Undersökning: Gemenskapens önskningslista/Uppdateringar/Resultat 2022

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
This page is a translated version of the page Community Wishlist Survey/Updates/2022 results and the translation is 73% complete.

Community Wishlist Survey banner - translatable.svg

2022

Hej allesammans!

Undersökningen: Gemenskapens önskelista 2022 är avslutad! Vi skulle vilja tacka alla som deltog i årets utgåva och uttrycka vår särskilda tacksamhet till dem som utomordentligt bidrog till undersökningen under resultaten. Vi skulle inte kunna ha gjort det utan er alla!

Nyfiken på vad som händer härnäst? Ta reda på mer om var prioriteringsprocess och spana in rankningen av prioriterade förslag för i år.

Resultat 2022

Omröstning

Mellan 28 januari och 11 februari kunde bidragsgivare med ett registrerat rösta på de förslag som skickades in innan januari.

Nästan 1 600 användare deltog i undersökningen. 467 förslag skickades in, varav 142 arkiverades, 55 större förslag och 270 som tävlade om deltagarnas röster. Det finns 9554 stödröster däribland 8387 röster för deltagande förslag. Grattis alla inblandade!

Omröstningens resultat finns tillgängligt på Undersökning: Gemenskapens önskelista 2022/Resultat.

Prioritering

Community Tech Wishes Prioritization Score 2022.svg

Som vi skrev i våra vanliga frågor är teknisk popularitet (antalet röster) huvudfaktor i beslutet över vilka förslag vi kommer arbeta på. Det är en viktig faktor, men inte den enda. Vi bedömer de topp 30 förslagen från tre perspektiv: teknisk komplexitet, produkt- och designkomplexitet och inverkan på gemenskapen.

Teknisk komplexitet

Våra ingenjörer bedömer hur mycket arbete de kommer behöver utföra för att uppfylla en önskan. De prioriterar mindre komplexa (mer arbetbara) projekt. När någonting är oklart kommer de försöka överskatta snarare än underskatta.

  • Technical dependency – we check if the work requires interactions with other Wikimedia Foundation teams. It could be that part of the work needs to be on other teams' roadmap or that we need other teams' input or feedback before we can complete the wish. Examples of these are schema changes, security reviews, adding a new extension, and upgrading third-party libraries.
  • Technical research – we ask ourselves if we know how to approach a particular problem. Sometimes we need to evaluate and consider our options before we can start thinking about a solution. Sometimes we need to confirm that what needs to be done can be done or is within what the platform we are working on can handle.
  • Technical effort – we ask ourselves how familiar we are with the underlying code and how big or complex the task can be. A high-effort score could also mean that the code we'll be working with is old, brittle, or has some degree of technical debt that will have to be dealt with before we can start working on our actual task.

Product and design

Similarly to the assessments above, our designer estimates what effort should be made to complete a project. They prioritize less complex (more workable) projects. Whenever something is not clear, they tries to overestimate rather than underestimate.

  • Design research effort – we seek to understand the level of research needed for each proposal. In this case, the research involves understanding the problem, either at the very beginning through initial discovery work (the scope and details of the project, surveys or interviews with community members), or later in the process through community discussions and usability testing (e.g. how do users contribute with and without this new feature).
  • 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.

Topplista

Betygen kan komma att ändras när vi börjar arbeta på förslagen. Som vi förklarat ovan har vi försökt överskatta snarare än underskatta. Spana in förslagen, prioriteringsordning:

Önskning Popularitetsranking Röster Ingenjörsbetyg Produkt- och designbetyg Inverkan på gemenskapen-betyg Prioriteringsbetyg
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

Om du är intresserad av att se en mer finkornig version av underkomponenterna som utgör prioriteringsbetygen, har vi gjort de individuella underkomponenterna offentliga:

Detta är förslag som vi kommit fram till kommer arbetas på av andra arbetslag på WMF eller tredjeparter med öppen källkod när vi gick igenom processen av att bedöma dess komplexitet:

Uppgifter för andra produktarbetslag
Önskning Popularitetsranking
Deal with Google Chrome User-Agent deprecation 15
Show editnotices on mobile 15
Categories in mobile app 18
Mass uploader 28

Större förslag

Tack för 55 större förslag, de nästan 1200 röster som lades på dem och alla kommentarer ni skrivit! Ni har spenderat mycket tid och detta är mycket viktig kunskap för oss.

Varför skapade vi den här kategorin och vad kommer vi göra härnäst?

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 "Större förslag" 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.

Tack till

Shout Of Gratitude.jpg

Vi skulle vilja uttrycka vår djupaste tacksamhet till alla deltagare. Gemenskapens önskelista är också er framgång.

Några av er har hjälpt oss förbättra undersökningen innan den ens börjat. Några har spenderat ett stort antal timmar på undersökningen. De har översatt dokumentation och förslag, diskuterat förslag och uppmuntrat andra att delta. Några bestämde sig att delta för första gången, och bland dem, fanns det några som påverkade slutresultatet på ett sätt som ingen kunnat förutse.

Vi kan inte göra en fullständig lista över alla som förtjänar att nämnas här. Hjärtlig tack till alla som hjälpt oss på sociala medier, inom sina gemenskaper och varit mindre synliga för oss.

Om du har förslag för nästa undersökning

...och inte vill glömma dem kan du lägga de i sandlådan. Förslag som sparats där räknas inte som inskickade, men andra kan komma ihåg dem och de löper lägre risk att överges.

Följ oss

English cocker Jam.jpg

Tack!

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