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

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 :

É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