Liste de souhaits de la communauté/Comment faire un souhait
Comment rédiger un bon souhait
Nous aimerions recueillir vos suggestions d'amélioration des projets Wikimédia. En tant que Commtech, nous souhaitons pouvoir diviser notre travail en petites tâches ; les demandes doivent donc concerner des projets plus importants qu'un simple bug, mais dont la mise en œuvre technique ne devrait pas prendre plus d'un an. Conscients que la suppression d'un outil peut représenter une charge de travail considérable, nous prenons également en compte les demandes suggérant la suppression d'une technologie afin d'évaluer l'intérêt qu'elles suscitent. Dans tous les cas, nous nous efforcerons de trier les tâches collectivement au sein de la Fondation et de les transmettre aux parties prenantes internes concernées afin de les sensibiliser aux besoins de la communauté.
Priorisation
Afin de pouvoir hiérarchiser les demandes reçues, nous les comparons aux objectifs stratégiques définis dans le Plan annuel. Il n'est pas obligatoire de lire le Plan annuel avant de formuler une demande, mais vous pouvez le faire si vous souhaitez mieux comprendre le processus de tri. De plus, nous prenons également en compte trois facteurs principaux pour déterminer s'il convient d'étudier et d'essayer de mettre en œuvre une demande :
- les souhaits qui ont un impact clair et mesurable sur la communauté, telles que l'augmentation de l'engagement (modifications, recherches, découvertes, etc.), par opposition aux suggestions pour lesquelles il peut être plus difficile de mesurer l'impact du travail (voire impossible) ;
- Les souhaits pour lesquels il n'existe aucune solution de contournement permettant d'atténuer le problème sous-jacent par opposition à ceux pour lesquels il existe une solution de contournement (intuitive ou non) ;
- Les souhaits qui concernent un large éventail de fonctionnalités ou d'utilisateurs essentiels par opposition aux souhaits qui ne concernent qu'un nombre restreint d'utilisateurs (par exemple, une fonctionnalité en phase de développement, les utilisateurs expérimentés).
Critères plus spécifiques:
| Priorité | Impact | Sécurité | Portée communautaire |
|---|---|---|---|
| La plus haute | Impact mesurable OKR | No workaround and may further deteriorate | Widespread and reproducible for a core feature or set of users |
| High | Non-core metrics are trackable or likely correlated | Complex workaround degrades UX or creates technical debt | Reproducible for sure, but not widespread enough for most users |
| Medium | Unclear whether wish would have any measurable impact | Intuitive workaround exists for users to circumvent issue | Not consistently reproducible - might be a niche use case |
| Low | No measurable impact | No severity - just a way to better polish a feature | Scope is unknown or may be unique use case |
This is not an exhaustive list, but just to give you transparency about what goes through our triage process. Regardless of how many votes a wish receives, we do triage everything and you can help us by providing more context with the tips above.
Wishes out of scope
It’s unlikely we will work on technical edits or work that requires policy changes. In many cases, creating a whole new application or algorithm might be out of scope. The WMF will not create gadgets or bots, but you're welcome to add wishes for gadgets/bots for consideration by members of the community.
Se concentrer sur le problème, pas sur une solution précise
While there is no official rubric for writing a "good wish," we encourage wish proposers to articulate a single problem they face without providing an explicit solution, so that volunteers and staff have space to problem-solve together. Potential solutions can be discussed and cocreated on the talk page and as an outcome of these conversations the wish description can be updated and extended, based on shared learnings.
Wishes that demonstrate empathy and show a user's challenges and goals avoids the pitfalls of being too niche or specific, and where other users may nitpick the solution.
In the example below, both the problem-led and solution-led wish examples hint at improving "new editor" experiences.
The problem-led example leaves the solution open-ended and invites collaboration, whereas the solution-led example might receive negative feedback from contributors who resist renaming a user sandbox. For wishes about problems that can be addressed in a multitude of technical ways, it is recommended to not make the solution(s) too narrow and to avoid describing just one of multiple mutually exclusive possible solutions.
Ainsi, le souhait lié à un problème a plus de chance d'être affecté à un domaine d'intérêt.
| Souhait guidé par un problème (encouragé) | Souhait guidé par une solution (déconseillé) | |
|---|---|---|
| Titre | Faciliter la création d'un premier article pour les nouveaux arrivants | Renommer le bac à sable en « Éditeur de brouillon » |
| Description | Especially for new editors, it can be hard to find a user sandbox. Once they find their sandbox, new editors see a number of disclaimers that make it hard to gain confidence in writing a good quality article. This impacts a newcomer's ability to onboard to Wikipedia and feel confident as a contributor. This is in part by design – we need to be mindful of patroller workflows – but the experience hinders our ability to onboard new editors. | The term “Sandbox” is confusing to new users. Let's rename it to “Draft editor” so that people are more likely to draft an article. |
| Type | Changement de système | Demande de fonctionnalité |
| Projet | Wikipédia | Wikipédia |
| Utilisateurs concernés | Les nouveaux contributeurs et, en aval, les patrouilleurs qui examinent les nouvelles éditions | Contributeurs |
| Tâches Phabricator | facultatif | T123456 |
Wishes that combine multiple problems should also be avoided. It may be that voters agree with some problems and ideas, but disagree on others. Likewise, the Foundation and stakeholders may find multifaceted wishes challenging to tackle if they involve multiple software components.