Liste des souhaits de la communauté/Liste des souhaits de la communauté 2027

Updated Community Wishlist Process 2027/2028

Below you will find an updated version of the new wishlist process, taking into account the feedback we’ve received. I've added "Updated!" to the sections that have significant changes. If you'd like to see in detail all that changed, I set this up in a way that lets you view a clear diff.

Stage 1: Triage

While wishes can already be submitted now, there will be a widely advertised call for wish submissions in the last 2 weeks of the submission period in October/November. After the wish submission window closes, a working group will come together to triage the wishes submitted before that date. We need to do it this way logistically, because we want to start working on wishes as early as February in this first cycle and because we want to respect the end of year holiday season when volunteers and staff have less availability. This means that wish submission will be closed between early November 2026 and mid January 2027.

 

We heard your feedback that ideally wish submission and voting should be close together. In future years we plan to reduce the time between these two phases to a ~2 week window for triage, likely with the next cycle happening between early January and early March 2028. Note that we considered keeping wish submission open during the voting period, but because we want triage to be completed before the vote so that all wishes have an equal opportunity to get assessed, we decided against that.

Working Group

The working group will include community members familiar with the wishlist process and the mediawiki codebase alongside WMF staff:

• Community members, ideally to include people from:
  • Small and medium-sized Wikipedias
  • Large Wikipedias
  • Sister projects (e.g., Wiktionary, Wikisource, Commons, Wikidata, etc.)
• Wikimedia Foundation staff who are on the teams that will be working on wishes:
  • Product managers and engineers from relevant product and engineering teams, such as Editing, Moderator Tools, PSI, Readers & Apps, and Content Transform.
  • Movement Communications

Updated!

Volunteers will be invited to contact us to indicate their interest in participating in this group, or to let us know about other volunteers who could be interested in joining. We will share a post with details within the next couple of weeks. We want the working group to consist of about equal numbers of staff and volunteers and to have representation from a diverse set of wikis, so while we don’t have a defined cap for how many people can participate, we may have to end up setting a limit if we get too much interest.

Triage activities

The working group will be active once a year for about 4 weeks to triage wishes in the period leading up to the vote. This process is intended to be relatively high level;  it is not meant to define in detail exactly how the wish would be implemented from an engineering perspective. That deeper planning will follow in the post-vote and implementation stages. For this first year, the group will convene primarily in November for wish triage. Once voting is complete in January, they will be asked for input on the final plan as well prior to posting it publicly for feedback from the community.

During triage, the working group will focus on:

• Deduplication: Wishes that are substantially similar will be identified and merged, with both original submissions retained for reference.
• Updated! Preliminary effort estimation: The working group will assign a relative size estimate to each wish (e.g., XS, S, M, L, XL). Sizing is relative, not absolute: it reflects the level of work required, meaning how a wish compares in effort to others, not a commitment to a timeline. Definitions are as follows:
  • S - not complex at all
  • M - mostly clear, but some complexity, solvable by one team
  • L - some complexity, potentially requiring help from multiple teams
  • XL - very complex, likely requiring multiple teams
• Updated! Clarification and refinement: Wishes will be linked to related phab tickets, prior work, or existing wishes. Working group members will ask clarifying questions to the wishers. Where relevant, the working group will add context about why a wish has not been addressed previously. Ensuring that we understand the desired impact of the wish is part of clarification and refinement as well. This includes assessing whether wishes undo previous work or go counter to other planned work, making tradeoffs clear and linking contradicting wishes, where possible.
• Grouping and merging / big investments: Where multiple wishes address the same underlying need, the working group may group or merge them and identify large underlying needs in the wishes (e.g. “these several wishes are all basically asking for an edit check system”). All constituent wishes will remain visible and attributed, and where possible duplicates will be closed.
• Updated! Wishes don’t carry over: Only the top 10 wishes in terms of vote count from the prior wish year that would have been next up to be prioritized will be rolled into the next wish year to be voted on again (so that they don’t need to be resubmitted). Votes from the prior year will carry through and editors who voted on the wish before cannot submit another vote, but they can remove support if they wish to do so. For all other wishes, wish submitters will be asked to re-submit their wish, so that we can keep the wish backlog a manageable size. Note that in the first voting period happening this coming January 2027, we will include open wishes from the existing wishlist to ensure we include the wishes submitted during the months we’re in now.
• Updated! Potential impact assessment: If pursuing this wish will sideline some other work that communities need, we’ll make that trade-off clear on the wish, including if the WMF currently would not have the needed resources to implement the wish (meaning it might not be possible to actually fulfill the wish). If data is available to determine the potential impact of a wish (such as the number of users who would see it), the working group will add this information to the wish so that the community can factor it in when casting their votes. They will note when a wish might have a positive impact for a given wiki or set of users but create a negative impact for another wiki or set of users.
• Updated! Removal of wishes:  A wish may be removed if it falls within the below criteria:
  • Wishes that are legally prohibited, or could put WMF staff, contributors or readers at risk.
  • Wishes that would reduce accessibility.
  • Wishes that break with prior community consensus.
  • Wishes that go against the Founding principles .
  • Wishes that would require vast amounts of resources that are unambiguously out of proportion to the benefits the wish would bring.
  • Wishes that are meant as trolling, spam, or are on topics beyond technical wishes.

However, we would not decline a wish only because it’s large in size or because the relevant WMF team already has different plans. In those cases it is important to understand the vote count prior to determining whether or where the wish could fit onto a roadmap.

For each wish, someone from the working group will publicly note the reason for declining it. The goal of this exercise would be to identify that a wish-as-submitted is not going to be possible, and try to discuss with the wish submitter to find a feasible path for the wish. If there isn’t such a path, then the wish may be declined.

Updated!

One important change to call out for this iteration is that we specifically removed “wishes that undo previous work”, “wishes that provide a positive impact for one set of users and a significant impact for others”, “wishes where many support them but many likely oppose them” from this list. Rather than considering declining them during triage, the working group will add trade-offs to the wish, so that the community has all necessary information when deciding on what route to go by casting their vote. I still believe that it is important that any wishes we know for sure wouldn’t get worked on (as per updated list above) are removed before volunteers start voting to make vote count as powerful as possible in determining how wishes should get prioritized.

Updated! Wish Statuses

We heard your feedback that the previous status labels were confusing and too corporate. Below is a new set of labels we think will work better. Please speak up if you still find any of them confusing or misleading.

• Proposed wish: All wishes come in with this status. Following triage, this status will again be used for all wishes that have not been prioritized or declined and are not well suited for community development.
• Needs clarification: This wish requires additional clarification and context from the community, and the working group will be pursuing it with the wish submitter and potentially others interested in the wish.
• Declined: The wish falls within the reasons for removal and therefore cannot be actioned by WMF and is not recommended for a volunteer to implement.
• Help welcome: Wishes that have not been prioritized by the WMF due to vote count, or have not yet been voted on, but are specifically well suited for the community to pick up.
• Prioritized by WMF: The wish has been prioritized by WMF for the current or upcoming fiscal year as a result of the wishlist vote, but work has not yet started. The description on the talk page should indicate when it’s prioritized for, i.e. which quarter or fiscal year. Wishes that are prioritized by community members or affiliates but not WMF should not use this status. They should move directly to “in progress” when work begins.
• In progress: Work is in progress on the wish, or current work is inspired by needs articulated in the wish. Wishes that get done by the community or affiliates should also get this status once they are in progress. If the WMF is conducting experiments or research into the feasibility and impact of this wish, the wish should still be marked as “in progress”, with details about the experiment or research included in the custom response on the wish page.
• Done: Wish has been fulfilled explicitly, or aspects of it are sufficiently addressed by alternative solutions, as described in the wish prior to the vote. Details about how the wish was completed should be included in the custom response on the wish page, including if the wish was completed by a volunteer.

Stage 2: Voting

Following triage, there will be an open voting period, advertised with banners across Wikimedia projects. The following rules will govern voting (these are roughly the same as how voting worked early in the wishlist’s existence):

• Votes are cast on individual wishes, not on groups or categories of wishes.
• Voters will be able to support a wish by clicking the “Support wish” button as in the last iteration of the wishlist.
• Updated! Opposing comments can be added by commenting on the Talk page of the wish.
• All logged-in Wikimedia users may vote, including users whose home wiki operates its own wishlist (such as communities served by Wikimedia Deutschland). Participation in a local wishlist process does not exclude a contributor from also participating in the global Wishlist. Temp Accounts are excluded.
• There is no limit to the number of votes per volunteer, but each volunteer can only vote for each wish once.

Stage 3: Post-vote

Prioritization should be in the hands of the community via the votes, meaning the votes are what prioritize the wishes. After sorting wishes by vote count, the Foundation will work through the list to determine the specific set of wishes that we’ll plan to work on.

We want to make sure that smaller and sister projects also get attention, so, each wish would be categorized into one of three project families:

• Large Wikipedias or covering all wikis
• Small and medium-sized Wikipedias
• Sister projects, including Commons, Wikidata, Wikisource, and Wiktionary

Once sorted by project family, we would look at top voted wishes per family to see if any wishes with high votes in smaller projects should be pulled in alongside top voted wishes from larger wikis, for example if a wish for a small community has a disproportionate impact. We understand this is imperfect but we also didn’t find a way to solve it all through the feedback we received. For that reason, we will try this version out this first time to keep it simple. We can learn from this approach and make changes once we know what did or did not work well and try out something else next year.

Reasons other than moving wishes up from a different project family that could prompt us to not entirely follow the vote count are, for example:

• Multiple top voted wishes require the same team's expertise. For example, if two top-voted wishes are both large wishes that require the Editing team, it may not be possible to do both.
• As mentioned back in the Triage section, we're going to indicate when wishes don't look like there can be enough resources, but allow voting on them anyway to make sure we understand how important the wish is for the community. If we don’t have the resources to fulfill the wish, we may have to decline it at this stage and we will include a clear explanation for why.
• Determining whether to accomplish a smaller set of large wishes or a larger set of smaller wishes.

Updated!

Reasons that would NOT be enough for declining a wish:

• Teams need to change their plans: We know and expect that this process will result in work that we don’t already plan on doing.
• Wishes don’t align with our annual plan / goals: Again, we expect to work on things that otherwise would not have been prioritized, meaning we will very likely work on wishes that do not contribute to meeting our targets.

For any changes we would make to the order of the list, such as to prioritize a lower vote count wish from a smaller project, the WMF would provide transparent reasoning prior to implementation. The working group will be invited to consult in this process as well. After that, the community will be asked to provide feedback on the final list prior to us getting started on the work.

Stage 4: Implementation

• Implementation of wishes and iteration of the process based on feedback from this cycle will be coordinated through the Wishlist Program, led by the Lead Program Manager we’re currently hiring and executed by the various WMF teams with the required subject matter expertise.
• The new wish submission period for the next voting cycle begins once wishes from the current cycle have been prioritized. The new wishes can be submitted year round until the next voting period takes place.
• If top voted wishes are for large audiences that do not typically participate in the wishlist (like readers or new editors), WMF may pursue research and concept testing of the idea before deciding to build further. This is the same standard applied internally to our own feature ideas for these audiences. It’s possible that in doing the research and testing, we discover that the wish won’t have a positive impact. We would then talk with the people who wrote and voted for the wish about those findings and what to do next.
• Updated! After looking at successful wish years (thanks to @Barkeep49 for the suggestion) we determined that we can commit to accomplishing something like 2-5 Small, 2-5 Medium, and 1-2 L or 1XL wishes. Here is the breakdown for the years we looked at:
  • 2018 (2017 Survey): 1S, 5M, 2.5L, 2XL
  • 2019 (2018 Survey): 2S, 2.5M, 1L, 1 XL
  • 2021 (2020 Survey): 2S, 2M, 1L

Note that we’re unable to give an exact wish count, because that depends on the wishes submitted each year. For example, if all top voted wishes are small or medium, we may only do small and medium wishes (but more of them!). If the top voted wish is XL, we would be able to deliver a few small and medium wishes as well, but we would likely not be able to commit to 2 XL wishes in a year (see definitions for sizes under Wish triage activities).

Potential timeline

For this year’s cycle, we plan to have the wish submission period in late October/early November and the triage process completed by late November. To respect the end-of-year holiday season, voting would happen in early to mid January. Prior to finalizing the list of wishes, it will be posted on meta in early February for community feedback. The goal is to have a list of wishes ready for our annual planning process beginning in February 2027 to inform our plans for the 2027/28 fiscal year (July 2027 through June 2028). We also want this first vote to prioritize wish work for the final months of the current fiscal year (so through June 2027), so that wish work can reflect community priorities as soon as possible.

Futur de la liste des souhaits de la communauté

Bonjour, je m’appelle Sonja et je dirige certaines des équipes de la Fondation qui seront chargées de prendre en charge les projets issus de la liste de souhaits dans le cadre du nouveau processus. Comme vous le savez peut-être, la liste de souhaits de la communauté a été initialement conçue comme un processus annuel permettant aux contributeurs de Wikimédia de proposer et de voter pour des améliorations techniques qu’ils aimeraient voir mises en œuvre par la Fondation Wikimédia. Son objectif principal est, et a toujours été, d’améliorer l’expérience d’édition en apportant les modifications et en ajoutant les fonctionnalités spécifiquement demandées par la communauté. Ces dernières années, le processus sous-jacent à la liste de souhaits a évolué, et beaucoup d’entre vous nous ont fait savoir qu’il ne répondait plus aux besoins de nombreuses personnes de la communauté. C’est pourquoi la Fondation élabore actuellement, en collaboration avec la communauté, un nouveau processus visant à améliorer la manière dont les souhaits sont triés, soumis au vote et classés par ordre de priorité, de manière transparente, et équilibrée entre les familles de projets et les éditions linguistiques, et en tenant compte de ce que la Fondation est en mesure de réaliser. Je souhaiterais recueillir l’avis de la communauté plus particulièrement sur ces trois étapes du processus de la liste de souhaits :

• La phase de triage, c'est-à-dire la manière dont les souhaits sont précisés, organisés et filtrés avant le vote
• La phase de vote, qui définit notamment qui peut voter et comment les votes sont organisés
• La phase post-vote, qui définit notamment comment garantir l'équité dans la hiérarchisation des tâches

En lisant les propositions ci-dessous, n’hésitez pas à donner votre avis : dites-nous si vous pensez que cela fonctionnera bien ou s’il existe des moyens de les améliorer. Ce premier cycle de vote est conçu comme une première étape pour tester un nouveau processus, et d’autres occasions vous seront offertes de faire part de vos commentaires au fur et à mesure, afin que nous puissions définir ensemble la meilleure méthode à adopter pour les années à venir.

Phase 1 : triage

Bien que la liste de souhaits reste ouverte toute l'année pour l'envoi de nouveaux souhaits, un appel à soumission sera largement diffusé au cours des deux dernières semaines de la période de soumission, en octobre/novembre. Une fois la période de soumission terminée, un groupe de travail se réunira pour trier les souhaits envoyés. Ce groupe de travail sera composé de membres de la communauté connaissant bien le processus de la liste de souhaits et le code source de MediaWiki, ainsi que de membres du personnel de la Fondation :

• des membres de la communauté (environ quatre ou cinq personnes), comprenant idéalement :
  • une personne issue d'une des Wikipédia de petite et moyenne taille
  • une personne issue d'une des grandes Wikipédia
  • une personne issue des projets-frères (par exemple, Wiktionnaire, Wikisource, Commons, Wikidata, etc.)
• des membres du personnel de la Fondation Wikimédia faisant partie des équipes qui travailleront sur les souhaits :
  • des chefs de produit et des ingénieurs issus des équipes de produit et d'ingénierie concernées, telles que Editing, Moderator tools, Product Safety and Integrity (PSI), Readers & Apps, et Content Transform.
  • Communications du mouvement (Movement Communications)

Activités de triage

Le groupe de travail sera actif une fois par an en novembre, pendant 2 à 4 semaines entre le moment de la présentation des souhaits et le moment de leur vote. Il se concentrera sur :

• Dé-duplication : les souhaits qui présentent des similitudes substantielles seront identifiés et fusionnés, les deux soumissions originales étant conservées à titre de référence.
• Estimation préliminaire de l'effort requis  : le groupe de travail attribuera à chaque demande une estimation de taille relative (par exemple, XS, S, M, L, XL). Cette classification est relative et non absolue : elle reflète le niveau de travail requis, c'est-à-dire la comparaison de l'effort nécessaire pour cette demande par rapport à d'autres, et ne constitue pas un engagement quant à un calendrier.
• Clarification et affinement : les demandes seront associées aux tickets Phabricator correspondants, aux travaux antérieurs ou à des demandes existantes. Les membres du groupe de travail poseront des questions de clarification aux auteur·ice·s des demandes. Le cas échéant, le groupe de travail ajoutera des informations expliquant pourquoi une demande n'a pas été traitée auparavant. S'assurer que nous comprenons bien l'impact souhaité de la demande fait également partie du processus de clarification et d'affinement.
• Regroupement et fusion / investissements importants  : lorsque plusieurs souhaits répondent au même besoin sous-jacent, le groupe de travail peut les regrouper ou les fusionner et identifier les besoins sous-jacents majeurs qui se dégagent de ces souhaits (par exemple : « ces différents souhaits demandent tous, au fond, la mise en place d'un système de vérification des modifications »). Tous les souhaits qui composent le groupe resteront visibles et attribués à leurs auteurs, et, dans la mesure du possible, les doublons seront supprimés.
• Les souhaits ne sont pas reconduits : au cours des années qui ont précédé l’ouverture de la liste de souhaits sur toute l’année, les souhaits qui n’avaient pas été traités n’étaient pas reportés dans les nouveaux votes de souhaits. Cette mesure visait à maintenir le nombre de souhaits en attente à un niveau gérable et à garantir que les souhaits les plus pertinents pour l’année en question soient traités. Nous recommandons de revenir à cette structure, ce qui signifie que seuls les souhaits nouvellement soumis au cours du cycle actuel seront inclus dans le tri et le vote à venir. Les souhaits des années précédentes qui n’ont pas encore été réalisés devront être soumis à nouveau s’ils revêtent toujours de l’importance pour les utilisateur·ice·s. Les résultats des votes précédents ne seront pas reportés. Cependant, lors de la première période de vote qui aura lieu en janvier prochain, nous inclurons les souhaits en attente de la liste de souhaits existante afin de nous assurer d’intégrer les souhaits soumis durant les mois en cours.
• Évaluation de l'impact potentiel : si la mise en œuvre d'un souhait devait entraîner la mise en veille d'autres travaux dont les communautés ont besoin, nous indiquerons clairement ce compromis dans la suggestion. Et si des données permettent de déterminer l'impact potentiel d'une suggestion (comme le nombre d'utilisateurs qui en bénéficieraient), le groupe de travail ajoutera ces informations à la suggestion afin que la communauté puisse en tenir compte lors du vote.
  • Exemple : seule l'équipe chargée de la fiabilité du site (SRE) pourrait mettre en œuvre ce souhait, mais si elle le faisait, des tâches essentielles de détection des bots seraient reportées, ce qui entraînerait un risque important pour les performances. Cette information serait ajoutée à la suggestion afin qu'elle puisse être prise en compte lors du vote.
• Suppression de souhaits : un souhait sera supprimé si il répond aux critères suivants :
  • Des souhaits qui sont légalement interdits ou qui pourraient mettre en danger le personnel de la Fondation, les contributeur·ice·s ou le lectorat.
  • Des souhaits qui annulent les travaux précédents ou contredisent d'autres travaux prévus. Ces souhaits peuvent toutefois constituer le point de départ pour des conversations importantes avec la communauté.
    • Exemple : une suggestion vise à mettre à jour l'assistant de création d'articles de Wikipédia en anglais afin de le rendre plus accessible aux novices, mais une partie de cette suggestion consiste à conserver le caractère ouvert de l'édition au sein de l'assistant. Parallèlement, nous travaillons sur un nouveau processus beaucoup plus guidé destiné à aider les novices à créer de nouveaux articles. Ces deux approches sont contradictoires et nécessiteraient des discussions plus approfondies.
    • Exemple : un souhait demande de désactiver l'éditeur visuel. Nous rejetterions un tel souhait pour plusieurs raisons : bien que de nombreux bénévoles puissent voter pour ce souhait, ils sont bien plus nombreux à ne pas souhaiter que cela se produise ; de plus, une grande partie du travail que nous effectuons actuellement nécessite l'éditeur visuel (par exemple, les contrôles d'édition - Edit check), de sorte que sa désactivation réduirait à néant de nombreux efforts passés, actuels et prévus.
  • Les souhaits qui proposent des fonctionnalités ou des changements nécessitant au préalable un consensus important au sein de la communauté, c’est-à-dire des souhaits soutenus par de nombreuses personnes, mais auxquels beaucoup d’autres s’opposeraient probablement.
  • Tout en offrant un impact positif pour un wiki ou un ensemble d'utilisateur·ice·s donné, les souhaits qui créent un impact négatif pour un autre wiki ou un groupe d'utilisateur·ice·s, par exemple un souhait qui fait une différence positive pour les personnes expérimentés, mais une grande différence négative pour les novices.
  • Les souhaits déposés en vue de troller, spammer ou qui portent sur des sujets qui dépassent les souhaits techniques.

Cependant, nous ne rejetterions pas un souhait uniquement parce qu’il est de grande envergure ou parce que l’équipe de la Fondation concernée a déjà d’autres projets. Dans ces cas-là, il est important de prendre conscience du nombre de votes avant de déterminer si le souhait peut être intégré à une feuille de route, et le cas échéant, à quel endroit.

Pour chaque souhait, un membre du groupe de travail exposera publiquement la raison de son rejet. L’objectif de cet exercice serait d’identifier qu’un souhait, tel qu’il a été soumis, ne sera pas réalisable, et d’essayer de discuter avec la personne qui l’a formulé afin de trouver une voie réalisable pour ce souhait. S’il n’existe pas de telle voie, le souhait pourra alors être rejeté. Je pense qu’il est important que tous les souhaits dont nous savons avec certitude qu’ils ne seront pas pris en compte soient retirés avant que les bénévoles ne commencent à voter, afin que le vote ait le plus de poids possible dans la détermination de l’ordre de priorité des souhaits.

Discuss

Status labels

I'm also interested in hearing people's thoughts about status labels that would be used during the triage process, and their definitions. Here is what we're thinking about for English (translations would have to follow later, likely in collaboration with the community):

• Needs clarification: This wish requires additional clarification and context from the community.
• Declined: The wish cannot be actioned by WMF and is not recommended for a volunteer.
• Patch welcome: Wishes that have not been prioritized by the WMF due to vote count, but are specifically well suited for the community to pick up.
• Prioritized by WMF: The wish has been prioritized by WMF for the current or upcoming fiscal year as a result of the wishlist vote, but work has not yet started. The description on the talk page should indicate when it’s prioritized for, i.e. which quarter or fiscal year.
• In progress: Work is in progress on the wish, or current work is inspired by needs articulated in the wish. Wishes that get done by the community or affiliates should also get this status once they are in progress.
• Done: Wish has been fulfilled explicitly, or aspects of it are sufficiently addressed by alternative solutions. Details about how the wish was completed should be included in the custom response on the wish page, including if the wish was completed by a volunteer or an affiliate and whether the wish was completed as part of a larger effort.
• (NO STATUS): Everything else. All wishes come in with no status. Following triage, this status will again be used for all wishes that have not been prioritized or declined and are not well suited for community patches.

Discuss

Phase 2 : Vote

À l'issue du triage, une période de vote ouverte sera organisée, annoncée par des bannières sur l'ensemble des projets Wikimédia. Les règles suivantes régiront le vote (elles sont globalement identiques à celles qui s'appliquaient au début de l'existence de la liste de souhaits) :

• Les votes portent sur des souhaits individuels, et non sur des groupes ou des catégories de souhaits.
• Tous les utilisateur·ice·s Wikimedia connectés peuvent voter, y compris ceux dont le wiki d'origine opère sa propre liste de souhaits (tel que les communautés desservies par Wikimedia Deutschland). La participation à un processus de liste de souhaits local n'empêche pas une personne de participer également à la liste de souhaits mondiale. Les comptes temporaires sont exclus.
• Il n'y a pas de limite au nombre de votes par personne, mais chaque personne ne peut voter qu'une seule fois pour chaque souhait.

Discuss

Phase 3 : Post-vote

La priorité devrait être donnée à la communauté par le biais des votes, ce qui signifie que les votes définissent la priorité des souhaits. Après avoir trié les souhaits par vote, la Fondation travaillera sur la base de cette liste pour déterminer l'ensemble précis de souhaits sur lesquels nous prévoyons de travailler.

Nous voulons nous assurer que les projets plus petits et les projets-frères reçoivent également l'attention, donc, chaque souhait serait classé dans l'une des trois familles de projets :

• Grandes Wikipédias ou couvrant toutes les wikis
• Petites et moyennes Wikipédias
• Projets-frères

Une fois triés par famille de projet, nous examinerions les souhaits les plus plébiscités par famille pour voir si les souhaits avec des voix élevées dans les petits projets devraient être placés aux côtés des souhaits les plus plébiscités pour les plus grands wikis.

D'autres raisons qui pourraient nous amener à ne pas suivre entièrement le décompte des voix sont, par exemple :

• Plusieurs souhaits classés premiers nécessitent l'expertise de la même équipe. Par exemple, si deux souhaits en haut du classement sont tous deux des grands souhaits qui nécessitent l'équipe Editing, il peut ne pas être possible de faire les deux.
• Déterminer s'il faut accomplir un plus petit ensemble de grands souhaits ou un plus grand ensemble de petits souhaits.

Pour être clairs, nous savons et nous nous attendons à ce que ce processus aboutisse à des travaux que nous n'avions pas déjà prévu de faire, et qui exigeraient que les équipes changent de plan ; donc nous ne refusons pas les souhaits simplement pour ces raisons. Pour toute modification que nous apporterions à l'ordre de la liste, comme pour donner la priorité à un souhait avec un plus petit nombre de voix venant d'un projet plus petit, la Fondation fournirait un raisonnement transparent avant la mise en œuvre. La communauté serait ensuite invitée à fournir des commentaires sur la liste finale avant que nous ne commencions le travail.

Discuss

Phase 4 : implémentation

• La mise en œuvre des souhaits et l’itération du processus, sur la base des retours d’expérience de ce cycle, seront coordonnées par le biais du programme Wishlist, dirigé par le Lead Program Manager que nous sommes actuellement en train de recruter et mis en œuvre par les différentes équipes de la Fondation disposant de l’expertise requise dans ce domaine.
• La nouvelle période de soumission des souhaits pour le prochain cycle de vote commence une fois que les souhaits du cycle en cours ont été classés par ordre de priorité. Les nouveaux souhaits peuvent être soumis tout au long de l’année jusqu’à la prochaine période de vote.
• Si les souhaits ayant recueilli le plus de votes concernent des publics larges qui ne participent généralement pas à la liste de souhaits (comme notre lectorat ou les novices sur les wikis), la Fondation pourra mener des recherches et tester le concept avant de décider de poursuivre le développement. Nous appliquons la même norme que celle appliquée en interne à nos propres idées de fonctionnalités destinées à ces publics. Il est possible qu’au cours de ces recherches et tests, nous constations que la suggestion n’aura pas d’impact positif. Nous discuterions alors avec les personnes qui ont rédigé et voté pour cette suggestion de ces conclusions et de la marche à suivre.

Discuss

Possible calendrier

Pour le cycle de cette année, nous prévoyons que la période de soumission des souhaits soit fin octobre/début novembre et que le processus de triage soit terminé fin novembre. Pour respecter la saison des fêtes de fin d'année, le vote se déroulerait entre le début et la mi-janvier. Avant de finaliser la liste des souhaits, celle-ci sera publiée sur Meta début février pour permettre les commentaires de la communauté. L'objectif est d'avoir une liste de souhaits prête pour notre processus de planification annuel à partir de février 2027 afin d'informer nos plans pour l'exercice 2027/28 (juillet 2027 à juin 2028). Nous voulons aussi que ce premier vote donne la priorité au travail des souhaits pour les derniers mois de l'exercice en cours (jusqu'en juin 2027), afin que le travail des souhaits puisse refléter les priorités communautaires le plus rapidement possible.

Discuss

Questions pour la communauté

Nous souhaitons tout particulièrement recueillir vos avis sur les questions suivantes sur la page de discussion, mais vos commentaires sur d'autres aspects de la proposition sont bien sûr également les bienvenus.

• La division en trois parties par famille de projets (grandes Wikipédias/petites et moyennes Wikipédias/projets-frères) est-elle le bon moyen de s'assurer que plusieurs communautés sont équitablement représentées ? Ou avez-vous d'autres suggestions sur la façon d'assurer l'équité entre les projets et les éditions linguistiques ?
  Discuss
• Ce projet de proposition tente de concilier deux aspects qui présentent une certaine tension inhérente : d'une part, veiller à ce que la Fondation réponde aux souhaits ayant recueilli le plus grand nombre de votes, y compris en modifiant les plans des équipes existantes si nécessaire ; d'autre part, tenir compte du fait qu'il existe certaines limites à ce que nous pouvons techniquement ou concrètement réaliser. Les plans relatifs à la « suppression de souhaits » et à la « phase post-vote » permettent-ils de trouver le juste équilibre ?
  Discuss
• Nous savons que l'exigence que les souhaits des années précédentes soient re-soumis créé un fardeau supplémentaire pour la communauté, mais les itérations passées de la liste de souhaits ont montré que le fait de ne pas avoir de limite ici peut entraîner des retards accumulés insoutenables. Y a-t-il des mécanismes auxquels vous pensez qui réduiraient le fardeau sur la communauté pour cela ?
  Discuss