Community Wishlist Survey/Prioritization/nl
Dit artikel is geschreven voor de vrijwilligers, enthousiastelingen van Community Wensenlijst enquête en geavanceerde bijdragers. Wij, Community Tech, willen beschrijven hoe we ons werk aan voorstellen plannen nadat de stemfase is afgelopen. We hopen onze processen van softwareontwikkeling uit te leggen. We krijgen graag feedback over de duidelijkheid van dit document.
Bij elke editie van deze wensenlijst wordt een nieuwe lijst van voorstellen opgezet, gesorteerd naar het aantal stemmen. Door de jaren heen hebben we geleerd dat het niet het beste idee is om te werken aan de top 10.
In plaats daarvan hebben we een methode ontwikkeld om de voorstellen te prioriteren. We beoordelen ze systematisch en transparant. De prioritering helpt ons te beslissen hoe we te werk gaan, zodat we zoveel mogelijk voorstellen kunnen voltooien. Er zijn een paar aannames:
- De populariteit van een voorstel moet een zeer belangrijke factor zijn bij onze selectiebeslissing, maar niet de enige.
- Het is het beste om aan de voorstellen in een strategische volgorde te werken en er zoveel mogelijk te voltooien.
- Engineers en ontwerpers moeten met elkaar kunnen werken zonder elkaar te blokkeren. Bijvoorbeeld, terwijl de ontwerper het voorstel onderzoekt en visuele componenten voor voorstellen genereert, richten de engineers zich op voorstellen die puur technisch zijn.
- Het is beter om met de gemeenschappen op transparante wijze te communiceren in plaats van de details te verbergen. Zichtbaarheid bouwt vertrouwen en dialoog op.
Samenvatting van de criteria
Bij het prioriteiten stellen, bekijken we de 30 meest populaire voorstellen. Wij gaan hieronder geen enkele voorstel herzien, omdat wij niet meer dan dertig wensen per jaar kunnen doen. We scoren de voorstellen op basis van populariteit, technische en product- en ontwerpcomplexiteit, evenals impact op de gemeenschap. De samenvatting van de criteria:
Zodra elk voorstel is geteld, rangschikken we ze en werken we volgens deze rangschikking. Alleen dan kunnen wij:
- Werken aan het maximale aantal wensen met de middelen die wij hebben.
- Ervoor kiezen om de grootste impact te hebben, waarbij met onderhoud en complexiteit rekening wordt gehouden.
We raadplegen ook andere teams van de Foundation en onderzoeken of zij al aan projecten in verband met voorstellen werkten.
Technische complexiteit
Criteria
Our engineers estimate how much effort they would need to put into granting a wish. They prioritize less complex (more workable) projects. Whenever something is not clear, they try to overestimate rather than underestimate.
- 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.
Schaal
Elk van deze is op een schaal van 1-6 gerangschikt:
| 1 - Laagste complexiteit |
|
|---|---|
| 2 - Laag gemiddelde complexiteit |
|
| 3 - Gemiddelde complexiteit |
|
| 4 - Gemiddeld hoge complexiteit |
|
| 5 - Hoge complexiteit |
|
| 6 - Erg hoge complexiteit |
|
Product en Ontwerp complexiteit
Criteria
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.
Schaal
Elk van deze is op een schaal van 1-6 gerangschikt:
| 1 - Laagste complexiteit |
|
|---|---|
| 2 - Laag gemiddelde complexiteit |
|
| 3 - Gemiddelde complexiteit |
|
| 4 - Gemiddeld hoge complexiteit |
|
| 5 - Hoge complexiteit |
|
| 6 - Erg hoge complexiteit |
|
Impact op gemeenschap
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. [[Community Wishlist Survey 2022/Editing/Autosave edited or new unpublished article|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. [[Community Wishlist Survey 2022/Bots and gadgets/Tool that reviews new uploads for potential copyright violations|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. [[Community Wishlist Survey 2022/Admins and patrollers/Show recent block history for IPs and ranges|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. [[Community Wishlist Survey 2022/Editing/Select preview image|Select preview image]] is an example of a prioritized proposal.
- Non-textual content and structured data – we prioritize proposals related to multimedia, graphs, etc. [[Community Wishlist Survey 2022/Multimedia and Commons/Mass uploader|Mass uploader]] is an example of a prioritized proposal.
- Urgency – we prioritize perennial bugs, recurring proposals, and changes which would make contributing significantly smoother. [[Community Wishlist Survey 2022/Wikisource/Fix search and replace in the Page namespace editor|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. [[Community Wishlist Survey 2022/Mobile and apps/Show editnotices on mobile|Show editnotices on mobile]] is an example of a prioritized proposal.
Resultaten 2022 gerangschikt op prioriteringsscore
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 |
|---|---|---|---|---|---|---|
| [[Community Wishlist Survey 2022/Editing/Autosave edited or new unpublished article|Autosave edited or new unpublished article]] | 29 | 69 | 1.0 | 0.3 | 2 | 2.66 |
| [[Community Wishlist Survey 2022/Miscellaneous/Get WhatLinksHere's lists in alphabetical order|Get WhatLinksHere's lists in alphabetical order]] | 22 | 74 | 1.3 | 0.3 | 2 | 2.63 |
| [[Community Wishlist Survey 2022/Search/Enable negation for tag filters|Enable negation for tag filters]] | 26 | 71 | 2.0 | 0.3 | 2 | 2.47 |
| [[Community Wishlist Survey 2022/Wikisource/Fix search and replace in the Page namespace editor|Fix search and replace in the Page namespace editor]] | 11 | 93 | 2.3 | 0.7 | 2 | 2.47 |
| [[Community Wishlist Survey 2022/Multimedia and Commons/Improve SVG rendering|Improve SVG rendering]] | 5 | 108 | 4.0 | 0.8 | 3 | 2.44 |
| [[Community Wishlist Survey 2022/Anti-harassment/Notifications for user page edits|Notifications for user page edits]] | 2 | 123 | 1.3 | 1.7 | 1 | 2.38 |
| [[Community Wishlist Survey 2022/Miscellaneous/Check if a page exists without populating WhatLinksHere|Check if a page exists without populating WhatLinksHere]] | 14 | 89 | 2.7 | 0.7 | 2 | 2.38 |
| [[Community Wishlist Survey 2022/Bots and gadgets/Tool that reviews new uploads for potential copyright violations|Tool that reviews new uploads for potential copyright violations]] | 4 | 109 | 4.3 | 2.7 | 4 | 2.21 |
| [[Community Wishlist Survey 2022/Reading/IPA audio renderer|IPA audio renderer]] | 9 | 97 | 3.0 | 2.7 | 3 | 2.15 |
| [[Community Wishlist Survey 2022/Reading/floating table headers|floating table headers]] | 24 | 73 | 1.0 | 2.7 | 2 | 2.14 |
| [[Community Wishlist Survey 2022/Admins and patrollers/Mass-delete to offer drop-down of standard reasons, or templated reasons.|Mass-delete to offer drop-down of standard reasons, or templated reasons.]] | 25 | 72 | 1.0 | 2.7 | 2 | 2.14 |
| [[Community Wishlist Survey 2022/Editing/Formatting columns in table|Formatting columns in table]] | 19 | 77 | 4.0 | 0.3 | 2 | 2.11 |
| [[Community Wishlist Survey 2022/Editing/Select preview image|Select preview image]] | 8 | 100 | 3.0 | 2.0 | 2 | 2.07 |
| [[Community Wishlist Survey 2022/Translation/Add DeepL as a machine translation option in ContentTranslation|Add DeepL as a machine translation option in ContentTranslation]] | 20 | 75 | 3.3 | 0.0 | 1 | 2.06 |
| [[Community Wishlist Survey 2022/Search/Change default number of search results displayed|Change default number of search results displayed]] | 12 | 92 | 2.0 | 1.7 | 1 | 2.05 |
| [[Community Wishlist Survey 2022/Editing/Better diff handling of paragraph splits|Better diff handling of paragraph splits]] | 1 | 157 | 3.3 | 2.3 | 1 | 2.04 |
| [[Community Wishlist Survey 2022/Mobile and apps/Table sorting on mobile|Table sorting on mobile]] | 17 | 83 | 2.3 | 1.7 | 1 | 1.92 |
| [[Community Wishlist Survey 2022/Miscellaneous/Enhanced Move Logs|Enhanced Move Logs]] | 10 | 96 | 2.7 | 2.3 | 1 | 1.79 |
| [[Community Wishlist Survey 2022/Bots and gadgets/Gadget: Who is active|Gadget: Who is active]] | 26 | 71 | 1.3 | 4.0 | 2 | 1.76 |
| [[Community Wishlist Survey 2022/Admins and patrollers/Show recent block history for IPs and ranges|Show recent block history for IPs and ranges]] | 3 | 120 | 4.0 | 3.7 | 2 | 1.61 |
| [[Community Wishlist Survey 2022/Admins and patrollers/Reminders or edit notifications after block expiration|Reminders or edit notifications after block expiration]] | 20 | 75 | 3.3 | 3.2 | 2 | 1.57 |
| [[Community Wishlist Survey 2022/Wikidata/Autosuggest linking Wikidata item after creating an article|Autosuggest linking Wikidata item after creating an article]] | 12 | 92 | 3.3 | 3.8 | 2 | 1.53 |
| [[Community Wishlist Survey 2022/Mobile and apps/Full page editing|Full page editing]] | 30 | 67 | 2.0 | 3.7 | 1 | 1.42 |
| [[Community Wishlist Survey 2022/Miscellaneous/Allow filtering of WhatLinksHere to remove links from templates|Allow filtering of WhatLinksHere to remove links from templates]] | 6 | 106 | 5.0 | 3.3 | 2 | 1.40 |
| [[Community Wishlist Survey 2022/Citations/Automatic duplicate citation finder|Automatic duplicate citation finder]] | 6 | 106 | 3.0 | 4.2 | 1 | 1.36 |
| [[Community Wishlist Survey 2022/Editing/VisualEditor should use human-like names for references|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:
| Wish | Popularity Rank |
|---|---|
| [[Community Wishlist Survey 2022/Anti-harassment/Deal with Google Chrome User-Agent deprecation|Deal with Google Chrome User-Agent deprecation]] | 15 |
| [[Community Wishlist Survey 2022/Mobile and apps/Show editnotices on mobile|Show editnotices on mobile]] | 15 |
| [[Community Wishlist Survey 2022/Mobile and apps/Categories in mobile app|Categories in mobile app]] | 18 |
| [[Community Wishlist Survey 2022/Multimedia and Commons/Mass uploader|Mass uploader]] | 28 |
Terminologie
Ongemodereerd gebruikersonderzoek
Gebruik een hulpmiddel zoals UserTesting.com om "mocks (alleen de Unit)" van onze voorgestelde ontwerpwijzigingen te laten lopen en te zien of we de juiste wensoplossing ontwerpen -- het wordt "ongemodereerd" genoemd omdat we gebruikers laten klikken en zien dat onze ontwerpen zinvol zijn zonder dat we het aan hen hoeven uit te leggen
Kwantitatieve gegevensverzameling
Het proces van het verzamelen van gegevens om te begrijpen hoe gebruikers interacteren met de huidige gebruikersinterface om de pijnpunten van de wens te begrijpen - of het nu gaat om gegevens over klikken, bezoeken, downloads, sessies, enz.
Kwalitatieve gegevensverzameling
Het begrijpen van de wens en het achterliggende probleem door rechtstreeks met gebruikers te praten, hetzij via interviews of via een enquête aan het begin van het oppakken van de wens om de pijnpunten te begrijpen en te verduidelijken hoe een oplossing wordt aangepakt
Gebruikers zoeken voor het testen
Het proces van het vinden van gebruikers die de kennis hebben die nodig is om deel te nemen aan onze gebruikerstests en ons de informatie geven die we nodig hebben om te begrijpen of onze ontwerp- en productbeslissingen in de juiste richting gaan. Sommige wensen zijn voor geavanceerde gebruikers, die moeilijk te vinden zijn en niet beschikbaar zijn in hulpmiddelen zoals UserTesting.com
Code-refactoring
Het proces om de bestaande code meer onderhoudbaar te maken zodat andere mensen bij kunnen dragen aan de code, evenals het verwijderen van technische onduidelijkheden en fouten.
Databaseschema wijzigingen
De wijziging van een verzameling logische structuren van een relationeel database geheel of gedeeltelijk. Wanneer een wijziging van een bestaande database nodig is, moet deze worden ontworpen en vervolgens goedgekeurd door een team van buiten CommTech. Dit kost meestal meer tijd en voegt structurele complexiteit toe aan het project.
Code van derden
Code die buiten het Community Tech-team is geschreven, voorbeelden zijn API's of bibliotheken.