Jump to content

Enquête sur les souhaits de la communauté/Priorisation

From Meta, a Wikimedia project coordination wiki
This page is a translated version of the page Community Wishlist Survey/Prioritization and the translation is 70% complete.

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 :

photo of prioritization score
Évaluation de la priorité des propositions des technologies communautaires

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
  • La solution technique est très simple ; le problème existe dans une partie limitée de l’expérience utilisateur et du code source
  • La solution peut déjà exister, avoir été déjà développée par un membre de la communauté sous forme de gadget, extension ou code dans une dépôt public.
  • Les membres de les techniciens de l’équipe Technologie communautaire sont familier avec le code.
  • Les tests de qualité nécessaires sont limités à une seule tâche.
2. Complexité moyenne basse
  • La solution technique est simple ; le problème existe dans une partie limitée de l’expérience utilisateur et du code source.
  • La solution peut déjà exister, avoir été déjà développée par un membre de la communauté sous forme de gadget, extension ou code dans une dépôt public.
  • Les membres de les techniciens de l’équipe Technologie communautaire sont familier avec le code.
  • Presque aucune maintenance requise.
  • Un réusinage minimal du code est nécessaire.
  • Dépendances possible à des codes tiers.
  • Les tests de qualité nécessaires sont limités à cinq tâches.
3. Complexité moyenne
  • La solution technique reste ouverte ; le problème existe dans plusieurs parties de l’expérience utilisateur et dans une ou plusieurs parties du code source ou plusieurs dépôts.
  • Aucune solution n’existe, ou une solution partielle.
  • Les membres de l’équipe Technologies communautaires ont une connaissance limitée ou sont peu familiers avec le code.
  • Un peu de maintenance est nécessaire.
  • Un réusinage du code peut être nécessaire.
  • Ajout potentiel de dépendances à des codes tiers.
  • Des tests qualité sont nécessaires avant publication, représentant plus de 5 tâches.
4. Complexité moyenne haute
  • La solution technique reste ouverte ; le problème existe dans plusieurs parties de l’expérience utilisateur et dans une ou plusieurs parties du code source ou plusieurs dépôts.
  • La solution n’a pas été implantée.
  • Les membres de l’équipe Technologies communautaires ont une connaissance limitée ou sont peu familiers avec le code.
  • De la maintenance est nécessaire.
  • Certains changements dans la structure de la base de données sont peut-être nécessaires.
  • Un réusinage du code est nécessaire.
  • Des changements dans des composants de sécurité ou d’authentification sont nécessaires (identification, marques de fonctionnalité, contrôles d’accès).
  • Ajout potentiel de dépendances à des codes tiers.
  • Des tests qualité sont nécessaires avant publication, représentant plus de 5 tâches.
5. Complexité haute
  • La solution technique a des inconnues ; le problème existe dans plusieurs parties de l’expérience utilisateur et dans une ou plusieurs parties du code source ou plusieurs dépôts.
  • Un système ou un nouvel outil doit peut-être être développé.
  • Les membres de l’équipe Technologie communautaire ne connaissent pas le code.
  • De la maintenance est nécessaire.
  • Certains changements dans la structure de la base de données sont peut-être nécessaires.
  • Un réusinage du code est nécessaire.
  • Des changements dans des composants de sécurité ou d’authentification sont nécessaires (identification, marques de fonctionnalité, contrôles d’accès).
  • Ajout potentiel de dépendances à des codes tiers.
  • Des tests qualité sont nécessaires avant publication, représentant plus de 5 tâches.
6. Complexité très haute
  • La solution technique a beaucoup d’inconnues ; le problème existe dans plusieurs parties de l’expérience utilisateur et dans une ou plusieurs parties du code source ou plusieurs dépôts.
  • Un système ou un nouvel outil doit peut-être être développé.
  • Les membres de l’équipe Technologie communautaire ne connaissent pas le code concerné par le souhait.
  • De la maintenance est nécessaire.
  • Un réusinage substantiel du code est nécessaire.
  • Des changements complexes dans la structure de la base de données sont peut-être nécessaires.
  • Un réusinage substantiel du code est nécessaire.
  • Des changements dans des composants de sécurité ou d’authentification sont nécessaires (identification, marques de fonctionnalité, contrôles d’accès).
  • Ajout de dépendances à des codes tiers.
  • Des tests qualité sont nécessaires avant publication, représentant plus de 10 tâches.

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
  • La solution de la conception est intégrée dans la proposition de souhait elle-même-- c'est une solution technique et aucune modification de l'interface utilisateur n'est nécessaire
  • Aucune collecte de données n'est nécessaire
  • Aucune collection d'enquêtes de la part d'utilisateurs de découverte
  • Aucune recherche d'utilisateurs non modérée
  • Aucune conception
2 - Complexité moyenne basse
  • Les modifications sont isolées sur une seule page à l'intérieur de l'expérience avec un nombre limité d'états (c'est-à-dire que les modifications n'affectent qu'une page / un projet wikimedia)
  • Cela nécessite peu ou pas de collecte de données initiales pour comprendre le comportement et le degré d'efforts via une enquête ou des données quantitatives
  • Cela nécessite peu ou pas de recherche non modérée
  • Avant de répondre au souhait, nous avons déjà collecté les données nécessaires pour prendre des décisions éclairées en matière de produit et de conception
3 - Complexité moyenne
  • Avant de répondre au souhait, nous recueillons déjà « la plupart » des données pour prendre des décisions éclairées sur les produits et la conception, mais nous pouvons avoir besoin de suivre de nouvelles données avant de commencer à comprendre le problème.
  • Cela nécessite une recherche d'utilisateurs non modérée, mais il n'est pas difficile de "sourcer" des utilisateurs pour ces flux
  • Cela peut toucher plus d'une page dans l'expérience, mais cela est généralement limité à un sous-ensemble de l'expérience et simple
  • Ceci est limité à la conception pour un type de besoin d'utilisateur
4 - Medium Large Complexity
  • Prior to tackling the wish, we already collect some of the data to make informed product & design decisions but may require tracking new data prior to starting to understand the problem
  • Requires unmoderated user research but it is not difficult to “source” users for those flows
  • May touch more than one page in the experience but it is generally limited to a subset of the experience and straightforward
  • Requires a survey at the beginning of wish
  • Limited to designing for two types of user needs
  • Touches more than one page in the experience but it is generally limited to a subset of the experience and straightforward
5 - Large Complexity
  • Requires qualitative discovery and quantitative data collection
  • Requires unmoderated user research and the users for the research are hard to source given the complexity of wish
  • Can require designing new technical information into the UI
  • Requires touching multiple pages in the flow
  • Requires a survey at the beginning of wish
  • Requires touching multiple pages in the flow and or has cross-project implications
  • Impacts across multiple user states, for example
    • Éditeurs
    • Readers
    • Proofreaders etc.
6 - Extra Large Complexity
  • Requires investigation by the process of qualitative discovery and quantitative data collection
  • Potentially controversial implications that must be mitigated by working with communities
  • Requires unmoderated user research and the users for the research are hard to source given the complexity of designs
  • Requires designing for a “learning curve” or introducing new technical information into the UI
  • Requires touching multiple pages in the flow and or has cross-project implications
  • Impacts across multiple user states and across needs:
    • Éditeurs
    • Lecteurs
    • Contributeurs
    • Nouveaux venus

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

Tâches pour d'autres équipes de développement
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.