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:

Prioriteitsscore voor technische voorstellen

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

Onze ingenieurs schatten hoeveel inspanning ze nodig hebben om een wens te vervullen. Zij geven prioriteit aan minder complexe (meer haalbare) projecten. Wanneer er iets niet duidelijk is, proberen ze te overschatten in plaats van te onderschatten.

• Technische afhankelijkheid – we controleren of het werk interacties met andere teams van de Wikimedia Foundation vereist. Het kan zijn dat een deel van het werk op het bordje van andere teams moet liggen of dat we de input of feedback van andere teams nodig hebben voordat we de wens kunnen voltooien. Voorbeelden hiervan zijn schemawijzigingen, beveiligingsbeoordelingen, het toevoegen van een nieuwe extensie en het upgraden van bibliotheken van derden.
• Technisch onderzoek – we vragen ons af of we weten hoe we een bepaald probleem moeten aanpakken. Soms moeten we onze opties evalueren en overwegen voordat we kunnen beginnen na te denken over een oplossing. Soms moeten we bevestigen dat wat gedaan moet worden, ook kan worden gedaan of binnen wat het platform waar we aan werken aankan.
• Technische inspanning – we vragen ons af hoe bekend we zijn met de onderliggende code en hoe groot of complex de taak kan zijn. Een hoge inspanningsscore kan ook betekenen dat de code waarmee we gaan werken oud en broos is, of een zekere mate van technische achterstand heeft die moet worden aangepakt voordat we aan onze eigenlijke taak kunnen beginnen.

Schaal

Elk van deze is op een schaal van 1-6 gerangschikt:

1 - Laagste complexiteit	De technische oplossing is zeer eenvoudig: het probleem bestaat in een beperkt deel van de gebruikerservaring en de codebase Een oplossing kan al bestaan, ontwikkeld door een gemeenschapslid in de vorm van een al bestaand gadget, extensie of code in een openbaar repository De leden van het team Community Tech kennen de code. Lichte QA-test vereist, slechts 1 taak waard QA
2 - Laag gemiddelde complexiteit	De technische oplossing is discreet - het probleem bestaat zowel in een ingesloten deel van de gebruikerservaring als in de codebase Een oplossing kan al bestaan, ontwikkeld door de gemeenschap in de vorm van een al bestaande gadget, extensie of code in een openbaar repository De leden van het team Community Tech kennen de code. Bijna geen onderhoud nodig Minimale code refactoring is vereist Mogelijke codeafhankelijkheden van derden Lichte QA-onderzoek vereist, minder dan 5 taken waard met QA
3 - Gemiddelde complexiteit	Technische oplossing heeft een open einde - het probleem bestaat in meerdere delen van de gebruikerservaring, evenals in een of meerdere delen van de codebase of repositories Gedeeltelijke oplossing of geen oplossing bekend De leden van het Community Tech team hebben beperkte kennis van of zijn onbekend met de code Bijna geen onderhoud nodig Het is mogelijk dat code-refactoring nodig is Mogelijk afhankelijkheden van derden toe te voegen QA-test voor de release, 5+ taken voor QA
4 - Gemiddeld hoge complexiteit	De technische oplossing is open-ended - het probleem bestaat in meerdere delen van de gebruikerservaring evenals één of meerdere onderdelen van de codebase of repositories De oplossing is niet geïmplementeerd De leden van het Community Tech team hebben beperkte kennis van of zijn onbekend met de code Onderhoud vereist Er kunnen databaseschema wijzigingen nodig zijn Code refactoring is vereist Wijzigingen van de authenticatie/beveiligingscomponenten zijn vereist, d.w.z. authenticatie, functievlaggen, toegangscontroles Mogelijk afhankelijkheden van derden toe te voegen QA-test voor de release, 5+ taken voor QA
5 - Hoge complexiteit	De technische oplossing heeft onbekende... het probleem bestaat in meerdere delen van de gebruikerservaring evenals één of meerdere onderdelen van de codebase of repositories Het kan nodig zijn een systeem of een nieuw hulpmiddel te ontwikkelen De leden van het Community Tech team kennen de code niet Onderhoud vereist Er kunnen databaseschema wijzigingen nodig zijn Code refactoring is vereist Wijzigingen van de authenticatie/beveiligingscomponenten zijn vereist, d.w.z. authenticatie, functievlaggen, toegangscontroles Mogelijk afhankelijkheden van derden toe te voegen QA-test voor de release, 5+ taken voor QA
6 - Erg hoge complexiteit	De technische oplossing heeft veel onbekende dingen. Het probleem bestaat in meerdere delen van de gebruikerservaring en in één of meerdere onderdelen van de codebase of repositories. Het kan nodig zijn een systeem of een nieuw hulpmiddel te ontwikkelen De leden van het Community Tech team kennen de betreffende code niet Onderhoud vereist Substantieel code-refactoring nodig. Er kunnen moeilijke databaseschema wijzigingen nodig zijn Substantieel code-refactoring nodig. Wijzigingen van de authenticatie/beveiligingscomponenten zijn vereist, d.w.z. authenticatie, functievlaggen, toegangscontroles Mogelijke codeafhankelijkheden van derden QA-test voor de release, 10+ taken voor QA

Product en Ontwerp complexiteit

Criteria

Net als bij de bovenstaande beoordelingen, schat onze ontwerper in welke inspanning moet worden geleverd om een project te voltooien. Ze geven prioriteit aan minder complexe (meer werkbare) projecten. Als er iets niet duidelijk is, proberen ze te overschatten in plaats van te onderschatten.

• Inspanningen op het gebied van ontwerponderzoek – we proberen inzicht te krijgen in het onderzoeksniveau dat nodig is voor elk voorstel. In dit geval omvat het onderzoek het begrijpen van het probleem, hetzij helemaal aan het begin door middel van het eerste ontdekkingswerk (de reikwijdte en details van het project, enquêtes of interviews met leden van de gemeenschap), of later in het proces door middel van gemeenschapsdiscussies en bruikbaarheidstesten (bijv. hoe dragen gebruikers bij met en zonder deze nieuwe functie).
• Visuele ontwerpinspanning – een aanzienlijk aantal voorstellen vereist wijzigingen in de gebruikersinterface van Wikimedia-projecten. Daarom controleren we om de verandering van de gebruikersinterface in te schatten, hoeveel elementen er moeten worden ontworpen en hun complexiteit. Bijvoorbeeld het gebruik van bestaande componenten uit ons ontwerpsysteem of het maken van nieuwe, rekening houdend met het aantal staten of waarschuwingen dat moet worden bedacht om gebruikers, inclusief nieuwkomers, te helpen.
• Workflow complexiteit – we vragen ons af hoe dit specifieke probleem de huidige workflows of stappen in de gebruikerservaring van editors verstoort. Een hoge score hier zou bijvoorbeeld betekenen dat er veel verschillende scenario's of plaatsen in de gebruikersinterface zijn waar bijdragers interactie kunnen hebben met een nieuwe functie. Het kan ook betekenen dat we moeten ontwerpen voor verschillende gebruikersgroepen, zowel gevorderden als nieuwkomers.

Schaal

Elk van deze is op een schaal van 1-6 gerangschikt:

1 - Laagste complexiteit	Design Solution is ingebed in het wensenvoorstel zelf. Het is een technische oplossing en er zijn geen UI-wijzigingen nodig. Geen gegevensverzameling nodig Geen gebruikersenquête nodig Geen ongemodereerd gebruikersonderzoek Geen ontwerp
2 - Laag gemiddelde complexiteit	Veranderingen worden geïsoleerd naar slechts één pagina binnen de ervaring met een beperkt aantal statussen (d.w.z. veranderingen raken slechts een pagina / één wikimedia project) Het vereist weinig of geen onderzoek om gedrag en pijnpunten te begrijpen via enquête of kwantitatieve gegevens Weinig tot geen onderzoek vereist Voordat we de wens aanpakten, hebben we al de gegevens verzameld die nodig zijn om geïnformeerde product- en ontwerpbeslissingen te nemen.
3 - Gemiddelde complexiteit	Voordat we de wens aanpakken, verzamelen we al 'de meeste' gegevens om weloverwogen product- en ontwerpbeslissingen te nemen, maar het kan zijn dat we nieuwe gegevens moeten bijhouden voordat we het probleem beginnen te begrijpen Het vereist ongemodereerd gebruikersonderzoek, maar het is niet moeilijk om gebruikers daarvoor als bron te vinden Kan meer dan één pagina in de ervaring raken, maar het is over het algemeen beperkt tot een subset van de ervaring en eenvoudig Beperkt tot het ontwerpen voor één type gebruikersbehoefte
4 - Gemiddeld hoge complexiteit	Voordat we de wens aanpakken, verzamelen we al 'een deel van de gegevens' om weloverwogen product- en ontwerpbeslissingen te nemen, maar het kan zijn dat we nieuwe gegevens moeten bijhouden voordat we het probleem beginnen te begrijpen Het vereist ongemodereerd gebruikersonderzoek, maar het is niet moeilijk om gebruikers daarvoor als bron te vinden Het kan meer dan één pagina in de ervaring aanraken, maar is over het algemeen beperkt tot een deel van de ervaring en eenvoudig Er is een enquête nodig bij het gaan oppakken van de wens Beperkt tot het ontwerpen voor twee types gebruikersbehoeften Raakt dan één pagina in de ervaring, maar is over het algemeen beperkt tot een deel van de ervaring en eenvoudig
5 - Hoge complexiteit	Vereist kwalitatief onderzoek en kwantitatieve gegevensverzameling Vereist ongemodereerd gebruikersonderzoek en de gebruikers voor het onderzoek zijn moeilijk te vinden gezien de complexiteit van de wens Kan vereisen dat er nieuwe technische informatie in de gebruikersinterface wordt ontworpen Vereist het bekijken van gevolgen voor meerdere pagina's in de stroom Er is een enquête nodig bij het gaan oppakken van de wens Vereist het bekijken van gevolgen voor meerdere pagina's in de stroom en/of heeft het implicaties in andere projecten Impact in meerdere gebruikersrollen, bijvoorbeeld Bewerkers Lezers Proeflezer enz.
6 - Erg hoge complexiteit	Vereist onderzoek door het proces van kwalitatief onderzoek en kwantitatieve gegevensverzameling Potentieel controversiële gevolgen die moeten worden verminderd door samen te werken met gemeenschappen Vereist ongemodereerd gebruikersonderzoek en de gebruikers voor het onderzoek zijn moeilijk te vinden gezien de complexiteit van de ontwerpen Vereist ontwerpen voor een "leercurve" of het introduceren van nieuwe technische informatie in de gebruikersinterface Vereist het bekijken van gevolgen voor meerdere pagina's in de stroom en/of heeft het implicaties in andere projecten Impact in meerdere gebruikersrollen en tussen behoeften, bijvoorbeeld Bewerkers Lezers Bijdragers Nieuwkomers

Impact op gemeenschap

In tegenstelling tot de twee hierboven beschreven perspectieven, gaat dit deel over rechtvaardigheid. In de praktijk gaat het erom ervoor te zorgen dat de meerderheden niet de enigen zijn aan wiens behoeften we werken.

Afhankelijk van deze score worden voorstellen met een vergelijkbaar aantal stemmen en een vergelijkbare complexiteit min of meer prioriteit gegeven. Als aan een bepaald criterium wordt voldaan, krijgt het voorstel een +1. Hoe meer kruisingen, hoe hoger de score. Deze beoordeling is toegevoegd door onze specialist in de gemeenschapsbetrekkingen.

• Niet alleen voor Wikipedia – voorstellen met betrekking tot verschillende projecten en projectneutrale voorstellen, worden hoger gerangschikt dan projecten die alleen aan Wikipedia zijn gewijd. [[Community Wishlist Survey 2022/Editing/Autosave edited or new unpublished article|Autosave edited or new unpublished article]] is een voorbeeld van een voorstel met prioriteit.
• Zusterprojecten en kleinere wiki's – we geven ook prioriteit aan voorstellen over de minder ondersteunde projecten (zoals Wikisource of Wiktionary). We hebben Wikimedia Commons als een van deze geteld. [[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 een voorbeeld van een voorstel met prioriteit.
• Kritische ondersteunende groepen – we geven prioriteit aan voorstellen die zijn bedoeld voor stewards, CheckUsers, beheerders en soortgelijke groepen die de bredere gemeenschap dienen en technisch ondersteunen. [[Community Wishlist Survey 2022/Admins and patrollers/Show recent block history for IPs and ranges|Show recent block history for IPs and ranges]] is een voorbeeld van een voorstel met prioriteit.
• Leeservaring – we geven prioriteit aan voorstellen die de ervaring van de grootste groep gebruikers – de lezers – verbeteren. [[Community Wishlist Survey 2022/Editing/Select preview image|Select preview image]] is een voorbeeld van een voorstel met prioriteit.
• Niet-tekstuele inhoud en gestructureerde gegevens – we geven prioriteit aan voorstellen met betrekking tot multimedia, grafieken, enz. [[Community Wishlist Survey 2022/Multimedia and Commons/Mass uploader|Mass uploader]] is een voorbeeld van een geprioriteerd voorstel.
• Urgentie – we geven prioriteit aan eeuwige bugs, terugkerende voorstellen en wijzigingen die het bijdragen aanzienlijk soepeler zouden maken. [[Community Wishlist Survey 2022/Wikisource/Fix search and replace in the Page namespace editor|Fix search and replace in the Page namespace editor]] is een voorbeeld van een voorstel met prioriteit.
• Barrière voor toegang – we geven prioriteit aan voorstellen over communicatie en voorstellen die zouden helpen om de eerste bijdragen te leveren. [[Community Wishlist Survey 2022/Mobile and apps/Show editnotices on mobile|Show editnotices on mobile]] is een voorbeeld van een voorstel met prioriteit.

Resultaten 2022 gerangschikt op prioriteringsscore

Deze resultaten kunnen veranderen wanneer we aan de voorstellen beginnen te werken. Zoals we hierboven hebben uitgelegd, hebben wij eerder geprobeerd te overschatten dan te onderschatten. De voorstellen worden in prioritaire volgorde geanalyseerd:

Wens	Populariteit	Stemmen	Engineering score	Product- en ontwerp score	Gemeenschapsimpact score	Prioriteit 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

Als u geïnteresseerd bent in het bekijken van een meer gedetailleerde versie van de subcomponenten die de prioriteitsscores maken, hebben we de afzonderlijke delen openbaar gemaakt:

• Complexiteit van het product en het ontwerp
• Technische complexiteit
• Gemeenschapsimpact

Dit zijn voorstellen waarvan wij vonden dat andere teams van de WMF of open source van derden er aan zullen werken wanneer we hun complexiteit hebben geraamd:

Taken voor andere productteams

Wens	Populariteit
[[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.