Community Wishlist Survey/Prioritization/nl

This page is a translated version of the page Community Wishlist Survey/Prioritization and the translation is 100% complete.

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

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	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

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	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 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