Community Wishlist/Community Wishlist 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.

Updated! 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.

Future of the Community Wishlist (outdated version)

Hi, I’m Sonja and I lead some of the teams at the Foundation who will be responsible for picking up wish work under the new wishlist process. As you may know, the Community Wishlist started out as an annual process through which Wikimedia contributors submit and vote on technical improvements they would like the Wikimedia Foundation to work on. The main goal of it is and has been to improve the editing experience by making changes and features the community asks for specifically. In recent years, the process behind the wishlist has changed, and we’ve heard from many of you that it no longer meets many community members’ needs. So now, the Foundation is designing a new process with the community to improve how wishes are triaged, voted on, and prioritized in a way that is transparent, balanced across project families and language editions, and takes into account what the Foundation can deliver. I would like to get community input specifically on these three stages of the Wishlist process:

The triage stage, meaning how wishes are fleshed out, organized and filtered prior to voting
The voting stage, including who may vote and how votes are structured
The post-vote stage, including how to bring equity into what work is prioritized

As you read the proposed ideas below, please speak up about whether you think this will work well or if there are ways to make it stronger. This first voting cycle is meant as a first step to try out a new process, and there will be more opportunities to provide feedback along the way, so that we can figure out the best process for future years together.

Stage 1: Triage

While the wishlist will remain open year round for new wish submissions, 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 submitted wishes. The working group will include community members familiar with the wishlist process and the mediawiki codebase alongside the Foundation staff:

Community members (roughly four or five people), ideally to include:
- Someone from small and medium-sized Wikipedias
- Someone from large Wikipedias
- Someone from 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

Triage activities

The working group will be active once a year in November for 2-4 weeks between when wishes are submitted and when they are voted on. They will focus on:

Deduplication: Wishes that are substantially similar will be identified and merged, with both original submissions retained for reference.
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.
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.
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.
Wishes don’t carry over: In the years right before the wishlist became open year round, wishes that didn’t get worked on did not carry over into new wish surveys. This was done to keep the wish backlog of a manageable size and to ensure the more relevant wishes for that particular year were worked on. We recommend going back to this structure, meaning only wishes newly submitted in the current cycle will be included in triage and voting moving forward. Wishes from prior years that have not yet been completed would need to be re-submitted if they are still important to people. Previous vote counts will not carry over. But in the first voting period happening this coming January, we would include open wishes from the existing wishlist so that we make sure to include the wishes submitted during the months we’re in now.
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. And 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.
- Example: Only the Site Reliability team could implement the wish, but if they did so, crucial bot-detection work would be pushed out, creating a significant performance risk. This information would be added to the wish so that it can be taken into account during the vote.
Removal of wishes: A wish will be removed if it falls within the below criteria:
- Wishes that are legally prohibited, or could put the Foundation staff, contributors or readers at risk.
- Wishes that undo previous work, or counter other planned work. These wishes, however, may be the starting point for important conversations with the community.
  - Example: A wish asks to update the English Wikipedia article wizard to make it better for newcomers, but part of the suggestion is to retain the open-ended nature of editing within the wizard. At the same time, we're working on a new, much more guided flow to help newcomers create new articles. These 2 approaches are at odds with each other and would require further discussions.
  - Example: A wish asks to un-deploy Visual Editor. We would decline such a wish for several reasons: while many volunteers might vote for this wish, there are many more who would not want this to occur; and a lot of the work we're currently doing requires VE (e.g. Edit Checks), so un-deploying it would nullify a lot of past, current, and planned efforts.
- Wishes that propose features or changes that would first require significant community consensus, i.e. wishes where many people support them, but many other people likely oppose them.
- While providing positive impact for a given wiki or set of users, wishes that create negative impact for another wiki or set of users, for example a wish that makes a positive difference for experienced editors, but a big negative difference for new editors.
- 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 Foundation 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 state 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. I think it is important that any wishes we know for sure wouldn’t get worked on are removed before volunteers start voting to make vote count as powerful as possible in determining how wishes should get prioritized.

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

Stage 2: Voting

Following triage, there will be an open voting period, advertised with banners across Wikimedia projects. The following rules would 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.
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.

Discuss

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

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.

Other reasons 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.
Determining whether to accomplish a smaller set of large wishes or a larger set of smaller wishes.

To be clear, we know and expect that this process will result in work that we would not already be planning to do, and that will require teams to change their plans – so we won’t be declining wishes simply for those reasons. 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 Foundation would provide transparent reasoning prior to implementation. The community would then be asked to provide feedback on the final list prior to us getting started on the work.

Discuss

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 Foundation 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), the Foundation 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.

Discuss

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.

Discuss

Questions for the community

We are especially interested to hear feedback on the following questions on the talk page, but of course comments on other aspects of the proposal are also welcome.

Is the three-way split by project family (large Wikipedias / small and medium Wikipedias / sister projects) the right way to make sure multiple communities are fairly represented? Or do you have other suggestions for how to ensure equity across projects and language editions?
Discuss
This proposal draft tries to balance two things with some inherent tension: ensuring that the Foundation fulfills the top-voted wishes, including by changing existing team plans as needed, with the reality that there are some limits about what we can technically or realistically deliver. Do the plans around “removal of wishes” and “post-vote” get the balance right?
Discuss
We know the requirement that wishes from previous years be re-submitted poses an additional burden on the community, but past iterations of the wishlist have shown that not having a boundary here can lead to unsustainable backlogs. Are there any mechanisms you can think of that would reduce the burden on the community for this?
Discuss