Enquête sur les souhaits de la communauté/Priorisation
Cet article est écrit pour les bénévoles, les enthousiastes de l'enquête des souhaits de la communauté et les contributeurs avancés. Nous, Community Tech, voulons décrire comment nous planifions notre travail sur les propositions une fois la phase de vote terminée. Nous espérons expliquer nos processus de développement de logiciels. Les commentaires sur la clarté de ce document sont les bienvenus.
Après chaque édition de l'enquête des souhaits de la communauté, il y a une nouvelle liste de propositions triées par le nombre de votes. Au fil des ans, nous avons appris que s'engager à travailler sur les 10 meilleurs n'est pas la meilleure idée.
Au lieu de cela, nous avons développé une méthode pour prioriser les propositions. Nous les évaluons de manière systématique et transparente. La priorisation nous aide à décider comment travailler afin de pouvoir terminer autant de propositions que possible. Il y a quelques hypothèses :
- La popularité d'une proposition devrait être un facteur très important dans notre choix de sélection, mais pas le seul.
- Il est préférable de travailler sur les propositions dans un ordre stratégique et d'en terminer autant que possible.
- Les ingénieurs et les concepteurs designers doivent pouvoir travailler ensemble sans se bloquer mutuellement. Par exemple, pendant que le designer recherche la proposition et génère des composants visuels pour les propositions, les ingénieurs se concentrent sur les propositions qui sont purement techniques.
- Il est préférable de communiquer de manière transparente avec les communautés plutôt que de cacher les détails. La visibilité construit la confiance et le dialogue.
Critères de sélection
Pour hiérarchiser les souhaits par priorité, nous examinons les 30 souhaits les plus populaires. Nous n’allons pas au-delà, car nous n’avons pas les moyens de réaliser plus de 30 souhaits par an. Nous évaluons les propositions en fonction de leur popularité, leur complexité technique de réalisation et conception, ainsi que leur impact communautaire. Voici un résumé des critères :
Lorsque toutes les propositions ont été évaluées, nous les classons et travaillons selon ce classement. C’est seulement ensuite que nous pouvons :
- travailler sur le plus de souhaits possible compte-tenu de nos ressources ;
- choisir d’avoir le plus grand impact en prenant en compte la maintenance et la complexité.
Nous consultons aussi les autres équipes de Wikimedia et vérifions s’ils ne travaillent pas déjà sur des projets liés aux propositions.
Complexité technique
Critères
Nos ingénieurs estiment l'effort qu'ils doivent fournir pour réaliser un souhait. Ils donnent la priorité aux projets moins complexes (plus faciles à réaliser). Lorsque quelque chose n'est pas clair, ils essaient de surestimer plutôt que de sous-estimer.
- Dépendance technique - nous vérifions si le travail nécessite des interactions avec d'autres équipes de la Wikimedia Foundation. Il se peut qu'une partie du travail doive figurer sur la feuille de route d'autres équipes ou que nous ayons besoin de la contribution ou du feedback d'autres équipes avant de pouvoir réaliser le souhait. Il peut s'agir par exemple de modifications du schéma, d'examens de sécurité, de l'ajout d'une nouvelle extension et de la mise à niveau de bibliothèques tierces.
- Recherche technique — nous nous demandons si nous savons comment aborder un problème particulier. Parfois, nous devons évaluer et examiner nos options avant de commencer à réfléchir à une solution. Parfois, nous devons confirmer que ce qui doit être fait peut être fait ou que la plateforme sur laquelle nous travaillons peut le faire.
- Effort technique — nous nous demandons à quel point nous sommes familiers avec le code sous-jacent et à quel point la tâche peut être importante ou complexe. Un score d'effort élevé peut également signifier que le code avec lequel nous allons travailler est vieux, fragile ou présente un certain degré de dette technique qui devra être traité avant que nous puissions commencer à travailler sur notre tâche réelle.
Échelle
Chaque proposition est classée sur une échelle de 1 à 6 :
| 1. Complexité la plus basse |
|
|---|---|
| 2. Complexité moyenne basse |
|
| 3. Complexité moyenne |
|
| 4. Complexité moyenne haute |
|
| 5. Complexité haute |
|
| 6. Complexité très haute |
|
Complexité de conception et réalisation
Critères
De la même manière que pour les évaluations ci-dessus, le concepteur estime les efforts à fournir pour mener à bien un projet. Il donne la priorité aux projets moins complexes (plus faciles à réaliser). Lorsque quelque chose n'est pas clair, il essaie de surestimer plutôt que de sous-estimer.
- Effort de recherche de conception — nous cherchons à comprendre le niveau de recherche nécessaire pour chaque proposition. Dans ce cas, la recherche implique de comprendre le problème, soit au tout début par un travail de découverte initial (la portée et les détails du projet, des enquêtes ou des interviews avec les membres de la communauté), soit plus tard dans le processus par des discussions avec la communauté et des tests d'utilisation (par exemple, comment les utilisateurs contribuent-ils avec et sans cette nouvelle fonctionnalité ?).
- Effort de conception visuelle — un nombre significatif de propositions nécessite des changements dans l' interface utilisateur des projets Wikimedia. Par conséquent, nous vérifions, afin d'estimer le changement de l'interface utilisateur, combien d'éléments doivent être conçus, ainsi que leur complexité. Par exemple, en utilisant des composants existants de notre [de conception] ou en en créant de nouveaux, en gardant à l'esprit combien d'états ou d'avertissements doivent être conçus pour guider les utilisateurs, y compris les nouveaux venus.
- Complexité du flux de travail - nous nous demandons dans quelle mesure ce problème particulier interfère avec les flux de travail actuels ou les étapes de l'[expérience utilisateur] des rédacteurs. Par exemple, un score élevé ici signifierait qu'il y a beaucoup de scénarios ou d'endroits différents dans l'interface utilisateur où les contributeurs pourraient interagir avec une nouvelle fonctionnalité. Cela peut également signifier que nous devrons peut-être concevoir un design pour différents groupes d'utilisateurs, qu'ils soient avancés ou nouveaux.
Échelle
Chaque proposition est classée sur une échelle de 1 à 6 :
| 1. Complexité la plus basse |
|
|---|---|
| 2 - Complexité moyenne basse |
|
| 3 - Complexité moyenne |
|
| 4 - Medium Large Complexity |
|
| 5 - Large Complexity |
|
| 6 - Extra Large Complexity |
|
Community Impact
Contrairement aux deux perspectives décrites ci-dessus, cette partie concerne l'équité. En pratique, il s'agit de s'assurer que les majorités ne sont pas les seules dont les besoins sont pris en compte.
En fonction de ce score, les propositions ayant un nombre de votes similaire et un degré de complexité similaire ont plus ou moins de chances d'être prioritaires. Si un critère donné est rempli, la proposition obtient +1. Plus il y a d'intersections, plus le score est élevé. Cette évaluation a été ajoutée par notre spécialiste des relations communautaires.
- Pas seulement pour Wikipédia — les propositions liées à divers projets et les propositions neutres par rapport au projet sont mieux classées que les projets consacrés uniquement à Wikipédia. [[Community Wishlist Survey 2022/Editing/Autosave edited or new unpublished article|Autosave edited or new unpublished article]] est un exemple de proposition classée par ordre de priorité.
- Projets frères et petits wikis - nous donnons également la priorité aux propositions concernant les projets non soutenus (comme Wikisource ou Wiktionary). Nous avons compté Wikimedia Commons comme l'un de ces projets. [[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]] est un exemple de proposition classée par ordre de priorité.
- Groupes de soutien essentiels — nous donnons la priorité aux propositions dédiées aux stewards, aux CheckUsers, aux admins et aux groupes similaires qui servent et soutiennent techniquement la communauté au sens large. [[Community Wishlist Survey 2022/Admins and patrollers/Show recent block history for IPs and ranges|Show recent block history for IPs and ranges]] est un exemple de proposition classée par ordre de priorité.
- Expérience de lecture — nous donnons la priorité aux propositions améliorant l'expérience du plus grand groupe d'utilisateurs : les lecteurs. [[Community Wishlist Survey 2022/Editing/Select preview image|Select preview image]] est un exemple de proposition classée par ordre de priorité.
- Contenu non textuel et données structurées — nous donnons la priorité aux propositions liées au multimédia, aux graphiques, etc. [[Community Wishlist Survey 2022/Multimedia and Commons/Mass uploader|Mass uploader]] est un exemple de proposition classée par ordre de priorité.
- Urgence — nous donnons la priorité aux bugs pérennes, aux propositions récurrentes et aux changements qui rendraient la contribution beaucoup plus fluide. [[Community Wishlist Survey 2022/Wikisource/Fix search and replace in the Page namespace editor|Fix search and replace in the Page namespace editor]] est un exemple d'une proposition classée par ordre de priorité.
- Barrière à l'entrée — nous donnons la priorité aux propositions concernant la communication et à celles qui aideraient à faire les premières contributions. [[Community Wishlist Survey 2022/Mobile and apps/Show editnotices on mobile|Show editnotices on mobile]] est un exemple d'une proposition classée par ordre de priorité.
2022 Results ranked by Prioritization Score
Ces scores peuvent changer lorsque nous commencerons à travailler sur les propositions. Comme nous l'avons expliqué ci-dessus, nous avons essayé de surestimer plutôt que de sous-estimer. Consultez les propositions, par ordre de priorité :
| Vœu | Classement de popularité | Votes | Score sur la complexité technique | Score sur le produit et le design | Score d'impact sur la communauté | Score de priorisation |
|---|---|---|---|---|---|---|
| [[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 |
En outre, si vous souhaitez consulter une version plus détaillée des sous-éléments qui composent les scores de priorisation, nous avons rendu publics les sous-éléments individuels :
Il s'agit de propositions dont nous avons constaté qu'elles seraient travaillées par d'autres équipes de la WMF ou par des tiers en open-source lorsque nous avons procédé à l'estimation de leur complexité :
| Vœu | Classement de popularité |
|---|---|
| [[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 |
Helpful Terminology
Unmoderated user research
Using a tool like UserTesting.com to run “mocks” of our proposed design changes and see if we are designing the right wish solution-- it’s called “unmoderated” because we let users click around and see our designs makes sense without having to explain it to them
Quantitative data collection
The process of collecting data to understand how users are interacting with the current UI to understand the wish’s pain points -- be it data regarding clicks, visits, downloads, sessions etc. Data is often limited when we first tackle a wish due to lack of tracking it prior to wish, or nonexistent data due to privacy reasons
Qualitative data collection
Understanding the wish’s problem space by talking directly to users, be it interviews or via a survey at the beginning of the wish to understand the pain points and clarify how to tackle a solution
“Sourcing” users
The process of finding users who have the knowledge required to participate in our user tests and give us the information we need to understand if our design and product decisions are headed in the right direction. Some wishes are for advanced users, which are hard to source and not available in tools like UserTesting.com
Code refactoring
The process of making the existing code more maintainable so that other people may contribute to the code, as well as removing technical debt and bugs.
Database schema changes
The alteration to a collection of logical structures of all or part of a relational database. When a change to an existing database is needed, it must be designed and then approved by a team external to CommTech. This usually takes more time and adds structural complexity to the project.
Third party code
Code written outside of the Community Tech team, examples include APIs or libraries.