Talk:Community Wishlist/Community Wishlist 2027

As you read the proposed ideas on the project page, please speak up about whether you think this will work well or if there are ways to make it stronger.

• You can comment here in any language.

Status labels and definitions

I'm also interested in hearing people's thoughts about status labels 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)Proposed wish: 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.

I realize that this list will depend on the process we settle on based on the feedback we get from the community over the next couple of weeks on this proposal. SPerry-WMF (talk) 00:11, 28 August 2026 (UTC)

I like that this feels simpler and more direct. Something a bit broader than "Patch welcome" could be helpful, because I read "patch" as "change to existing codebase", and some wishes suitable for volunteers may take the form of a new userscript, bot, Toolforge app, extension, or another kind of standalone mini-project. I'm thinking of things like: Commons category userscript experiment, potential bot task related to captions, potential bot task related to new-language proposals. Could be "Help wanted" (a default label on GitHub) or "Help welcome"? Dreamyshade (talk) 04:02, 3 September 2026 (UTC)

That's a great point -- Help welcome sounds good to me! SPerry-WMF (talk) 16:18, 3 September 2026 (UTC)

While the labels make sense overall, I'm confused as to when these statuses come into play. Your text says during triage, but at that point, you would only have 'needs clarification', 'declined', 'open for vote' and 'no status', right? —Femke 🐦 (talk) 16:31, 8 September 2026 (UTC)

All wishes would come in as "Proposed wish" (I just made that change above, we actually need to have a label attached to all wishes for filtering and sorting purposes based on how the code works today). So during triage, we would change the status for some wishes to the following: Needs clarification and Declined. Prioritized by WMF requires the vote count, so that will follow in the post-vote stage.

We could actually also include PatchHelp welcome during triage if we change the description to: "The wish was not prioritized by the community during the voting period, or has not yet been voted on, but can feasibly be worked on by the community." The thinking here is that if a wish is well suited for a volunteer to pick up, why should we wait for the vote to open that up for them as a possibility? If that were the case, they could mark the wish as "In progress" and we would not include it in the vote. The other reason for adding this label during triage is that it could be an important signal for editors whether the wish could be easily done by the community -- especially if these wishes are small and could be done at a Hackathon, I could see fewer people voting on those wishes since the vote will determine what WMF teams work on. What do you think? SPerry-WMF (talk) 19:57, 9 September 2026 (UTC)

Stage 1: Triage

First of all, thanks a lot for putting this together! This proposal is very well-fleshed out and provides a real voice for the community, even in the triage stage (which can be the trickiest). I would be more than happy to volunteer as a member of this working group.

On the more concrete aspects, it could be helpful to clarify the balance between community members (of which we know the rough number) and staff. Will the group be flexible, taking in staff members from the teams qualified to work on the specific wish to consider, or will it be a more rigid working group? How many staff members do you estimate will be there? Given the instructions, I am confident that everyone will use their best technical expertise to determine how feasible a wish might be, but a numerical superiority on one side or another might lead to some chilling effect.

Ideally, we want to strike a balance. Wishes should be technically realistic and provide a clear benefit to the community, but the wishlist is also an opportunity for volunteers to express desires going beyond the Annual Plan, and we don't want to push the working group towards the latter in an attempt to "play it safe". While the selection process hasn't been made explicit in the proposal, I would encourage a volunteer basis (if the numbers allow for it) or community elections on a reasonable term basis (likely 1 or 2 years), possibly with term limits. That way, we avoid the scenario of a working group drifting too far from community goals, and keep a reasonable input from, and accountability to, the broader community at the triage stage. Selection by the WMF can lead to great choices (thinking of PTAC's community picks!), but can also lead to the appearance of impropriety as the volunteers might be perceived as not representative of the community as a whole. We have many qualified volunteers and I do not believe that 4–5 community members should be a hard limit, although again we should be mindful to keep a balance between them and staff members. Chaotic Enby (talk) 20:30, 27 August 2026 (UTC)

Thank you for your feedback and all the good questions, let me address them one by one.

Based on previous wish years, let's assume we get between 150-300 wishes. To be able to get through them within about 2 weeks, getting at least 4-5 volunteers from a diverse set of wikis would be good, but I think that number should be flexible. In fact, I think it makes sense to keep this as simple as possible for this first year. After that we can determine if we need to make the process more formal with a committee. For now we could just open the working group to anyone interested in participating rather than having a voted-in group of volunteers, but there would be some requirements (like being familiar with the mediawiki code base and Phabricator and experienced enough to be able to understand a broad range of wishes across projects and provide advice on things like: Has this been tried before? Are there any pre-existing Phab tickets or community discussions around this? How useful would implementing the wish be and for who? Are there gadgets or scripts or features that already solve the problem? Does a wish seem generally easy or generally complex? Could the wish be changed to be easier to implement? Merged with another? Etc.). We haven’t created a sign-up process for this yet and we’d probably have to put a reasonable limit as a cap to keep the process manageable. This is something we would work on in more detail after we receive some feedback from the community on the overall proposal. It would be great to have at least one volunteer assigned to each wish.

With regards to the number of staff participating: I think we should also have at least one WMF staff member assigned to each wish, specifically from the teams who will carry out the wish. In some cases we may ask the product manager to step in, in other cases an engineer, or maybe both. This means the number of staff depends on the kinds of wishes we get and how they are spread across teams. The teams that tend to get the most wishes are Editing, Moderator Tools, PSI, Readers & Apps, and Content Transform, so I would expect 1-2 people from these teams to be involved in the triage process, but they would not all look at all wishes.

You make a good point about the chilling effect, I agree that's something we need to mindful of and avoid. I don't know if it's super important to make the ratio of staff/volunteers exactly even for each wish (but agree roughly even would be good), because ultimately lots of community members would be part of the triage process through discussions on the wish, which I hope would help prevent a chilling effect. For example if the working group thinks a wish should be merged with another or changed in any way, they would start a discussion on the wish page and ideally the wish submitter and anyone who voted on the wish would join in on the discussion. And something else that should help with the chilling effect: ideally very few wishes would be declined during this phase. For example: we should absolutely not rule out wishes simply because it's not realistic that they will get done with the resources we have. Rather, the group should note these things down in the wish to set expectations, but we still need to understand through the vote how important the wish is for the community, so that we can start discussing whether or where the wish could fit on a roadmap if top voted. In some cases we have to say no to a wish at that point, but having the community voice reflected on how important the wish is is very important for making those kinds of tradeoff and resourcing decisions.

One additional step we could add is that prior to any declining wishes, the working group reviews all wishes that are nominated to be marked declined by those who reviewed them to ensure all perspectives are taken into account. SPerry-WMF (talk) 23:11, 27 August 2026 (UTC)

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. - This is way too subjective. Pppery (alt) (talk) 21:07, 27 August 2026 (UTC)

I.e this could be interpreted as banning things as trivial as "implement extended-confirmed protection" (ignoring the fact that that is a site request not a wish as it requires no engineering resources). I'm sure that's not your intent, but you need to clarify what exactly this rule is meant to cover if you keep it at all. Pppery (alt) (talk) 21:27, 27 August 2026 (UTC)

And, more fundamentally, I think the community should be left to make this balancing act for itself, not have the triage team decide for them. Pppery (alt) (talk) 21:16, 27 August 2026 (UTC)

I think the decision should be made jointly. Certainly the triage team should point out (and be responsible for pointing out?) potential negative impacts that the community hasn't thought of. Thryduulf (talk: meta · en.wp) 21:40, 27 August 2026 (UTC)

That's fair. Pppery (alt) (talk) 21:51, 27 August 2026 (UTC)

I've been envisioning this also as making the decision jointly. The working group should document during triage whether there are any trade-offs, either between wikis or with other impactful work that would compete for the same resources. @Pppery (alt) you make a good point that the balancing act should sit with the community. I might just move this piece from "Removal of wishes" to "Potential impact assessment". What do you think?

Here is the problem we're trying to solve with having a list of potential cases for removal: ideally the result of the triage process would be to make the vote as powerful as possible. I think this means that if we know for certain that we will not pick up a wish regardless of vote count, we should make that clear early in the process and decline the wish. I can't think of many wishes that would fall into that category, but un-deploying VE was one that came to mind (though I get your point above that the decline reason should be different), another might be a wish that asks to build all editing functionality into the app as well, which we know is something that would require the kinds of resources we would not be able to get even if vote count was very high. In my opinion getting these wishes declined before the vote helps with making the prioritization process less subjective, because a lot of these difficult discussions are done earlier in the process and then the community can trust that the vote count will be THE guiding post for prioritization. SPerry-WMF (talk) 23:54, 27 August 2026 (UTC)

I agree with you in principle that if we know for certain that we will not pick up a wish regardless of vote count, we should make that clear early in the process and decline the wish. On the other hand making the prioritization process less subjective isn't much of a gain if it comes at the cost of making the triage process more subjective. And you have to make sure you really mean that -- seeing hundreds of people support something you had thought was un-doable should be seen as a way of rethinking whether it's really doable after all. Pppery (alt) (talk) 00:00, 28 August 2026 (UTC)

For the question of whether or not something is doable, I totally agree with you. The examples I was using were also for things that were doable in theory, but we wouldn't consider them for different reasons. It just feels disingenuous to not have these conversations up front and I believe the vote count becomes more powerful when this stuff is out in the open before people cast their vote. Another way of dealing with this would be to not outright decline the wish, but just make it very explicit in the wish that the wish is not going to be picked up, even if top-voted. That in itself would make me as a voter question the power my vote could have though. SPerry-WMF (talk) 00:34, 28 August 2026 (UTC)

I think that a good way to maintain good will, etc. here is to make it clear that there are really different sorts of declines. The bullets are intended as examples not an exhaustive list

1. Can't be done.
   • It technically can't be done, no matter how much it's wanted.
   • It could theoretically be done, but cannot practically done.
     • It would require vast amounts of resources that are unambiguously out of proportion to the benefits.
     • It would require resources the WMF does not have or is objectively unable to allocate to the project, regardless of the benefits
2. Won't be done no matter what.
   • It would be illegal or incompatible with the license
   • It would break accessibility
   • It would be incompatible with the movement goals
   • The community has made it clear they don't want it
   • On balance it would be net negative for the projects overall, even though it benefits others
3. Won't be done by the WMF.
   • There is a better way to implement it (e.g. a gadget)
   • We aren't going to allocate the resources towards implementing this (at least this year), but community patches are welcome

Clearly articulating why something is being declined, and possibly using different terminology for the three basic types, will hopefully maximise understanding. Especially if it's clear that some degree of change is possible in some cases. Thryduulf (talk: meta · en.wp) 00:38, 28 August 2026 (UTC)

That makes a lot of sense to me, thanks for spelling this out so clearly! SPerry-WMF (talk) 02:23, 28 August 2026 (UTC)

Wishes that undo previous work, or counter other planned work. These wishes, however, may be the starting point for important conversations with the community. I also don't like this, in particular since neither example helps clarify much. Undeploying VisualEditor would be declined as a wish for a different reason as it requires no engineering resources to do and is instead a site request as a technical matter. And for the first example I think the ideal outcome is that both competing designs end up on the wishlist and whichever gets more votes gets done. Pppery (alt) (talk) 21:15, 27 August 2026 (UTC)

Agree with the fact that this is not ideal, especially as I foresee the risk of it being used to veto wishes orthogonal to the Annual Plan's intentions. The team's power should ideally be limited to technical feasibility, demonstrated benefit, and housekeeping (e.g. merging redundant wishes).

Also adding that wishes where many people support them, but many other people likely oppose them is quite vague: in many cases, the community will want to see a first draft of an implementation for consensus to sway one way or another. The likely oppose is also pretty subjective and I don't think it should be the committee's job to second-guess community intention. In fact, this last part is quite redundant with the voting period itself! Chaotic Enby (talk) 21:30, 27 August 2026 (UTC)

So, re: Wishes that undo previous work, or counter other planned work, I think there are scenarios where this might be useful. The particular one I have in mind is Community_Wishlist_Survey_2019/Editing/Put_mw.toolbar_back which was removed for "we don't want to keep maintaining deprecated code from a millenia ago that can be a gadget" reasons. I personally don't feel particularly thrilled about the application described in Example A, but "These wishes, however, may be the starting point for important conversations with the community." seems to imply that regardless of the wish to make article editing more open-ended itself being declined the feedback/spirit of the wish will be discussed in other venues/will be forwarded to the team in question? (atleast that's how I read it)

Re: wishes where many people support them, but many other people likely oppose them. I think the last part there is a bit of a red-herring? Declining because of existing consensus has been a standard thing in the wishlist (and on Phabricator) for a while. This would be the equivalent of putting a "Community-consensus-needed" banner on a task and would cover stuff like "can we stop archiving X/Y/Z talk pages" or "have a NSFW disclaimer on some articles/censor certain images". Sohom (talk) 21:54, 27 August 2026 (UTC)

I think Community_Wishlist_Survey_2019/Editing/Put_mw.toolbar_back shouldn't have been archived. If the community expresses such hostility to what is seen by the WMF as removing deprecated code and wants to use the wishlist to force them to keep maintaining it, then so be it and let them do it. Pppery (alt) (talk) 21:59, 27 August 2026 (UTC)

You're right we won't really know how many people support vs oppose a wish until they voted on it, so I see how that wording is confusing. I was referring to prior consensus primarily, so "Declining because of existing consensus" makes this more clear and captures what I was trying to get at. SPerry-WMF (talk) 00:48, 28 August 2026 (UTC)

I agree that declining wishes because the 'counter other planned work' is not ideal. I have good hopes that the new article guidance will incorporate feedback to bring in key features of the article wizard (that is, discouraging people from creating articles that are non-notable). The team working on it initially didn't want to have this relatively hard discouragement. It should be possible to ask for work more closely aligned with what communities want.

A second example: If we look at the current wishlist, improvements to sfn were rejected because of subreferencing. I love the idea of subreferencing, and it's possible (but unlikely imo) that sfn will become a more niche style of referencing due to it, but that choice should be with the community.

In these cases, I would like a note from the triage team instead with a discouragement, saying that this partially duplicates work / brings parallel solutions in place which might not be wise use of time. But leave the communities to decide. —Femke 🐦 (talk) 16:29, 8 September 2026 (UTC)

How will the community members on the committee be chosen? (I will probably volunteer). Pppery (alt) (talk) 21:15, 27 August 2026 (UTC)

Good to hear you might want to volunteer. I replied to ChaoticEnby above with a more detailed reply, but in a nutshell, I wonder if we could just have an open call for volunteers who want to participate. Do you think that could work well? SPerry-WMF (talk) 00:36, 28 August 2026 (UTC)

"Wishes don't carry over". I don't find the reasons for this convincing. ensur[ing] the more relevant wishes for that particular year were worked on can be accomplished by keeping wishes from before that weren't selected to be implemented and only resetting their vote counts. Also state explicitly whether current votes will or will not carry over. Pppery (alt) (talk) 21:30, 27 August 2026 (UTC)

Let's fast forward 3 years from now... if we say we'll keep all wishes active and include them in the next year without asking the wish submitter to review the wish / re-submit their wish, then we could have something like 700-900 wishes to triage. Granted the wishes from the previous year would have already gone through triage then, but the working group would have to still review the wish to ensure it's still accurate / doesn't have to be merged with another wish. That's just a lot of duplicative work without knowing if the wisher and the previous supporters are even still interested in getting the wish completed. Putting the burden of doing that assessment on the wisher is not ideal either, but we could create an easy process for them to just re-open the wish (while retaining previous triage information), so that the work for them is minimal. SPerry-WMF (talk) 00:55, 28 August 2026 (UTC)

Why does this need to be presented as if there are only two options, all or nothing? Neither is helpful. We know very well from previous years how frustrating it is for the community when they are forced to resubmit the same valid wish over and over again, just because it's not as popular. This is a complaint we, the WMDE TechWish team, regularly got. We also know how previous wishes ranked in the previous voting phase(s). All you need to do is to pick something like a top 20 from the previously unsolved wishes and put them up for vote again. Thiemo Kreuz (WMDE) (talk) 07:27, 1 September 2026 (UTC)

Yes! A similar comment below really resonated with me too, suggesting that we take the top N wishes and roll them into next year. I think that's a great suggestion in that it reduces the burden on volunteers but also doesn't blow up the backlog or require a ton of extra triage. SPerry-WMF (talk) 21:39, 1 September 2026 (UTC)

• Would be good to have a place for community members to add any potential perceived blockers during the triage process. Doc James (talk · contribs · email) 01:59, 28 August 2026 (UTC)

  All discussion/communication about the wish would happen on the Talk page of the wish, following the current process. Do you think we need something in addition to that? SPerry-WMF (talk) 02:23, 28 August 2026 (UTC)

  I was thinking a section under "Supporters of this wish" on the main page rather than the talk page of the wish in question. Doc James (talk · contribs · email) 04:22, 28 August 2026 (UTC)

Create an organization dedicated to the Wikimedia Movement Product Roadmap

Hello and thanks for this proposition. While I think it's way better than what previously existed, I think it misses the mark on what the movement should be. This is because the Community Wishlist is a bandaid put on a real problem : the lack of product strategy in the movement. A way to "give to editors what they want" one or twice a year, instead of having a shared ownership.

What I think would be ideal is way different.

First, have a dedicated organization (NOT a department of the WMF) dedicated only on defining the product roadmap of Mediawiki. Its first mission would be to establish what are the real needs of MediaWiki (and other technical solutions) users (everyone, not just the subset involved in Community Wishlist. It means not just Wikipedia users, but Commons, Wiktionaries, Wikisource, etc, as well ; not just English speakers ; not only people who edit, but also the one who don't because of UX issues. This means treating editors not as a "community" you need to have "liaisons" with, but as a market with user experiences to address.

Secondly, manage (not do) the actual development. Let ALL the actors of movement address the roadmap, not only the WMF. Aren't we supposed to be a free software / open source movement ? Every year we showcase great stuff done by volunteers, let this kind of work be a normal part of our software development. Obviously there are lot of amazing people and team at the WMF that would implement the majority of the roadmap but this way, ALL the development done by the WMF would be aligned with what the movement needs the most critically, not just one/three wishes a year.

I tried to keep it short but I'm happy to discuss this more ! Léna (talk) 13:58, 28 August 2026 (UTC)

+1, hits the nail on the head Kowal2701 (talk) 17:33, 28 August 2026 (UTC)

Thank you for this, and I'm glad the direction feels like an improvement over previous versions. I want to be clear about the intention behind the Wishlist though. The Wishlist isn't trying to fill a gap for a missing product strategy, but instead it's solving a different and more specific problem: giving contributors a reliable, structured way to surface concrete technical needs and see them addressed. That's valuable in itself, regardless of the bigger governance questions you raise.

That said, your point about who gets heard resonates with me, and it's actually something we've been grappling with directly. One of the structural questions we're sitting with is whether a three-way split between large Wikipedias, small and medium Wikipedias, and sister projects is actually the right way to ensure fair representation across communities. Do you have other ideas for how to create an equitable process across projects? SPerry-WMF (talk) 19:24, 28 August 2026 (UTC)

The most concrete point first : I would create a specific bucket for English Wikipedia separated from other larges Wikipedia. I also think every type of project should have its split as well (at least one for Commons, one for Wikidata, one for Wiktionaries, one for Wikisources). The functional debt on Commons is abysmal, we're still managing a multi-lingual media library with a software thought for monolingual encyclopedias.

The other point : why don't contributors have a reliable way to surface technical needs ? I worked in several tech companies, we never had a "client wishlist" with votes on which features to do next. New ideas came either from the sales team (equivalent here would be : conduct surveys to know what are the technical obstacles that prevent some people to edit) or the product team through what they learnt by conducting user interviews etc.

The only nuance I see is that we're supposed to be a horizontalish movement and not a hiearchical for profit, meaning that high level strategy questions (for instance : is the priority n°1 to attract young users around the world ? users from any age in Africa ? to make the top 0.1% of editors even more efficient ?) should be decided with a democratic process and don't think the Whislist adress this as well. Léna (talk) 12:46, 29 August 2026 (UTC)

Your suggestion to use buckets per project type makes sense, thanks for calling out specific ones you think should have their own! SPerry-WMF (talk) 21:43, 1 September 2026 (UTC)

Stage 2: Voting

Small procedural question here: will the votes for the wishes be only support votes, or will there be a way to oppose wishes too? I'm expecting the latter (as it allows the community to express which wishes might be controversial), but it isn't immediately clear. Chaotic Enby (talk) 21:34, 27 August 2026 (UTC)

I would suggest to keep that the same as in previous wish years, unless there are good reasons not to. SPerry-WMF (talk) 01:10, 28 August 2026 (UTC)

In previous previous years, people could oppose with a reason, but it didn't 'count'. That way, you could open community discussion without creating a more oppositional climate. I don't know if that's still possible now that you support via a button rather than via wikitext. —Femke 🐦 (talk) 16:34, 8 September 2026 (UTC)

Thanks, Femke! You are right, in the current wishlist extension this is not an option as a button, but you can still oppose a wish on the wish talk page, which essentially establishes the same thing, since the Talk page of each wish will be reviewed during triage. Here is a more recent example. We could make sure to make this clear as an option and add it to our documentation/instructions. SPerry-WMF (talk) 01:27, 9 September 2026 (UTC)

As the voters do not see the talk page, that solution doesn't work as well as the old system. Perhaps a 'comment' option should be placed next to the 'support', so that people can put their oppose in a visible place. I'm suggesting the word 'comment' instead of oppose to prevent a more adversarial system. —Femke 🐦 (talk) 12:46, 10 September 2026 (UTC)

Adversarial != bad. If people have substantive reasons to oppose, I have no issue with the 'Oppose' label. I presume we are adults who can handle differing points of view. StefenTower (talk) 18:27, 11 September 2026 (UTC)

I want people to oppose, but an oppose button implies that these opposes count and create more of an adversarial process. The same can be achieved with a neutral comment button. The wishlist is a celebration of our community, and should avoid that imo. —Femke 🐦 (talk) 20:20, 11 September 2026 (UTC)

I think perhaps framing it as disagreeing with a suggestion rather than opposing it might help with that?

People add things to the wishlist because they sincerely believe it will be an improvement (either for them specifically or more broadly). It is possible for other people to equally sincerely believe it would not be an improvement and/or would actually make it (or something else) worse, and there should be a way to express that, but it should be explained why they think that. In some (but not all) cases one or other view will be objectively correct, but it is equally likely to be the proposer's or the respondent's view. In other cases matters can be resolved by changing the scope of the wish or by modifying it. No one person can be expected to think of everything so comments looking at it from different angles should imo be encouraged, whether that's from a generally supportive perspective or otherwise. Thryduulf (talk: meta · en.wp) 22:49, 11 September 2026 (UTC)

I agree with having 'Oppose' as a choice, but its use should be restricted to opposition based on the opposer believing the implementation of the wish will cause one or more specific issues, and therefore they must include a comment with it to explain what those issues are. Opposition that amounts to "I don't like this" or "I prefer other wishes" shouldn't be allowed. StefenTower (talk) 22:57, 31 August 2026 (UTC)

Stage 3: Post-vote

• I'm glad the community gets to have input after the initial proposed prioritisation list. It's possibly the least defined part of the proposed system. I makes sense to me to ensure that the work is well divided over the different teams, and a discussion of size comes into play. In the past, we've had a few "imposed" reasons for deviation from the ranking that were less popular, which I'm glad to not see repeated (e.g. give UWERs more weight, even though they turn up to vote in relatively large numbers already).
• It might be good to specify which reason cannot be used to deviate from the ranking, and which reasons can. I imagine that small communities will be prioritised when there are wishes with a disproportionate effect, for instance if basic functionality is broken or for small communities that have an outside effect on other projects (Commons, Wikidata, perhaps wiktionary). —Femke 🐦 (talk) 16:55, 8 September 2026 (UTC)

Stage 4: Implementation

• The main issue is exactly the same one it was three years ago: if there's no implementation, this is a way of making volunteers lose their time and compete for scarcity instead of going on. There are tons of things to improve, we just need the WMF to work on those, instead of having volunteers competing for attention. Is just about doing things that should have been done two years ago. -Theklan (talk) 06:33, 2 September 2026 (UTC)
• This makes sense, and it's good to set expectations for reader-focused wishes, ensuring they are tested with the true audience in mind. —Femke 🐦 (talk) 16:42, 8 September 2026 (UTC)

Potential timeline

• This feels really slow. We'll vote in January on things that won't be done until July? Why the almost year-long wait relative to now. Pppery (alt) (talk) 21:52, 27 August 2026 (UTC)

  For this year, we actually want to start working on wishes immediately in January. We will also use the list of wishes for planning the next fiscal year, starting in July 2027 and going through June 2028. Moving forward voting would likely happen at the same time (so in January 2028) and we would most likely not start working on those new wishes until July. The reason for that is that we want to make room in our roadmaps for wish work explicitly, and we start building those roadmaps in February for the next fiscal year, which starts in July. I could see some exceptions for really important wishes, but generally speaking we would need to plan those wishes into next year's plan to make sure teams can deliver them alongside other projects we plan to work on. SPerry-WMF (talk) 01:08, 28 August 2026 (UTC)

  Yes, this feels very slow for the future: submitting requests by October 2027 for developers to start analysing in July 2028. That's nine months in the best case, or 20 months if a problem is identified in November just after the submission deadline. Sorry to be blunt, but a bureaucratic delay of that magnitude just wouldn't be tolerated in any other organisation I've worked with. Certes (talk) 19:20, 30 August 2026 (UTC)

  You’re right, 20 months is a long time, but we specifically want to bring the results of the vote to our annual planning process, so that we can ensure wish work gets a dedicated spot in our roadmaps for the next fiscal year. In future years, we could move the submission and voting period to January and February, which would help us keep the timing between those periods tighter and it would reduce the time between vote and wish implementation as well. If urgent bugs come in, we’d of course continue to handle them on a faster timeline as we do now. SPerry-WMF (talk) 21:09, 1 September 2026 (UTC)

  @SPerry-WMF I don't know how your roadmaps work, but would it be feasible to have a spot on them for "community wish delivery" (not necessarily that exact phrasing) with detail to be filled in later, rather than programming in Wish #1, Wish #2, etc individually? Thryduulf (talk: meta · en.wp) 02:08, 2 September 2026 (UTC)

  Good question! The main benefit of making the wishlist a shared responsibility across all Product and Tech teams is that team with the most expertise is expected to pick up a wish. This means that which teams are responsible for wishes will depend on the wish and which area it falls within. For example, if the wish is to improve VE functionality, the Editing team would pick up the wish, whereas if the wish is about automating repetitive patrolling tasks, the Moderator Tools team would be better suited to implement it. So having the vote done before we go into planning helps us make important trade-off decisions. If there is a big wish around automating patrolling tasks for example that is estimated to be very complex to implement, that would mean that we'd budget much less time for other work for the Moderator Tools team, and we'd have trade-off decisions around timing. During our planning process we set a goal for each area (our objective) that the individual teams contribute to. So in this case if the Moderator Tools team can't contribute to the shared objective all contributor teams work towards, we'd have to reflect that in our goal for that area as well. SPerry-WMF (talk) 03:15, 2 September 2026 (UTC)

  Sorry, but that isn't happening ever. The WMF doesn't deliver even if it's in the Annual Plan. Just act. Theklan (talk) 06:34, 2 September 2026 (UTC)

  Planning and doing work is quite a long process that cannot easily be compressed, but the voting system can. What I loved about the previous system is that you could still remember the wishes you submitted and help clarify when the voting starts. Now there is a very long time between wish submission, and voting. To align with the annual plan, perhaps the period for wish submission and triage should be pushed back later? —Femke 🐦 (talk) 16:38, 8 September 2026 (UTC)

  Yes, exactly that's what we're thinking. For this first period unfortunately we'll have to stick to the timeline because we want to prioritize wishes as soon as possible and not just make space for them in our roadmaps for the 27/28 fiscal year. But for future years, a better alternative could be to run the banners for wish submission in January, immediately followed by triage, then immediately after that the vote (in Feb/March). We'd also keep wish submission open through the voting phase. SPerry-WMF (talk) 01:43, 9 September 2026 (UTC)

Questions for the community

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? -- Sohom (talk) 00:34, 28 August 2026 (UTC)

We'd all agree that the wishlist shouldn't just focus on the needs of the largest communities. However, I'm not sure splitting by size is the right variable. Imagine if there were only two communities: one had a million people and the other had ten people. A 50/50 split of resources would be absurd. I think that logic applies equally for N number of different-sized communities.

One possible alternative is to split by project type, which probably means creating carve-outs for certain project. Commons, Data, Source, Quote... all of these might have needs that are particular to those projects/platforms. Irrespective of size. Some portion of resources should be allocated to their particular needs (I don't know what portion).

Another (not mutually exclusive) alternative is to focus on geography. Even broad categories like "Global South" and "Global North" could help bring equity. Or, by continent.

So for example, just picking numbers out of the air here, but it could be 70% Wikipedias, 30% non-Wikipedia projects (Commons, Data, etc.). The 70% could further be divided into 35% South and 35% North. Or 10% for each of the continents (ok, not Antarctica).

But I'd also speak up in favor of matching resources with volunteers. If 70% of the volunteers are all in one project, it's bad if 100% of the resources go to that project, but there's nothing really wrong with spending 70% of the resources on that project. Levivich (talk) 18:16, 28 August 2026 (UTC)

Thanks for sharing your perspective. The part I'm struggling with the most for this question is that I'm not sure setting a quota or using a specific formula will work here, because every year is different. Let's say one year there is a wish that would be hugely impactful for a set of smaller projects and within the project family it is the top voted wish, but the overall vote count was much lower than the highest voted wish overall. We check with the community and there is general consensus that the wish would make a big difference, so we could say: ok, let's remove the wish lowest top-voted wish and slot the other one in instead. Then the next year we look at top voted wishes within the same project family (or however we end up sorting them) but when asking the community about it, everyone is more or less indifferent about the wish. Should we then slot it in anyways, because we did that last year, even though we generally agree that the impact isn't as exciting as last year and the lowest top-voted wish would actually be more impactful? My problem here is that it's just all so subjective, and I agree with you that having some formula here would be ideal to make it more objective. Interesting idea of matching resources to the number of volunteers! SPerry-WMF (talk) 21:04, 28 August 2026 (UTC)

That's a good explanation of why hard quotas aren't the best approach. Perhaps flexible guidelines instead, with the exact proportions changing year to year based on circumstances. For example (again picking numbers out of thin air): 1/3 could be allocated to cross-project wishes that would benefit all or almost all projects; 1/3 to cross-language wishes that would benefit all languages if not all projects; and 1/3 to individual project wishes (or small groups of projects).

Under this example apportionment, 2/3 of the wishes would benefit a population that is probably bigger than 2/3 of the whole community. The "1-project" 1/3 could then be filled with wishes that score high on a rubric for, e.g., popularity, feasibility, etc. In some years, the "1-project" portion might be 40% because there are a lot of popular, feasible, etc., wishes. In other years, it might be only 20% because there aren't that many.

For those first two thirds, there's another factor to consider: representation of different languages and global areas (and maybe even demographics like age, gender, etc.). If a supermajority of the community is English-speaking, then what the English-speaking members of the community want would always be the most popular cross-project wishes. If a supermajority is in North America, same thing. Members who contribute in any other language or who live anywhere else would be in a permanent voting minority, if the global community is heavily concentrated in a single language or geographic area (as I believe it is).

One open question is whether it matters: do non-English-speaking community members vote differently on wishes than English-speaking community members? I don't know but I would imagine it would make a difference for some wishes. So I think that should (continue to?) be tracked, and the votes somehow weighed, to make sure that the community members outside that homogenous supermajority also have their voices heard and wishes fulfilled. Levivich (talk) 03:27, 29 August 2026 (UTC)

I see some different groups:

• Commons - specific type based primary on imagas
• Wikidata - specfic type, different type of interface
• Wikisource - many pages without edits for long years, specific needs (proofread, formated outputs)
• Wiktionaries
• Other wikis - wikipedias, wikiquotes, wikivoyages, probably wikibooks and wikiversities too
  • Large wikis (big community (thousands of editors), many articles) - uses some specific tools
  • Middle wikis (medium community (hundrets), ususally more than 100k articles)
  • Small Wikis (maximum tens of editors)

JAn Dudík (talk) 07:08, 1 September 2026 (UTC)

Thank you for the proposal and for this question being the first one. While I like the proposal, I feel uncomfortable with the proposed classification. As we are dealing with technical evolutions, I think the main criteria shouldn't be how large the community is, but how technically different the projects are, and I would rather see something like:

• Commons (media library used by all other projects + a major project by itself)
• Wikidata (database used by all other projects + a major project by itself)
• Text-based wikis (all other projects. Here, I would focus on the writing systems rather than the community size: make sure we handle properly non-Latin-based system, right-to-left writing systems, etc.)

Don-vip (talk) 18:05, 1 September 2026 (UTC)

All suggestions above make sense, thank you all for sharing your perspectives. One follow-up question for you all, @Don-vip, @JAn Dudík @Levivich: logistically, this would mean we tag a wish with the specific type (per your suggestions above), then we'd rank each type separately by vote count. Per my comment above, I'm not sure it's as easy as assigning a quota. Can you think of a system that would apply the right kind of weight to these buckets to ensure we focus on the most important things in an equitable way? SPerry-WMF (talk) 22:21, 1 September 2026 (UTC)

@SPerry-WMF: I'm not sure if this exactly answers your question; apologies if not. The simplest system I personally can think of would work like this:

• "Feasability," as I think of the word, is a gate: either a wish is feasible or it's not, and if it's not, that's unlikely to change, so it doesn't matter if it's popular or otherwise scores high. That's because I'm using "feasible" to mean, basically, "doable," is in: not technically impossible, not illegal, etc. Wishes that aren't feasible might become feasible if, e.g., the law changes, or new technology is invented, but that would be an unusual development. "Feasible," to me, doesn't mean, e.g., "expensive." That should be a different category. So: step 1: filter out the wishes that aren't feasible, because regardless of how many people vote for it, we can't, e.g., give all editors unicorns or ignore copyright laws.
• Step 2: tabulate vote across 3 dimensions
  1. "Overall": individual voters' votes, across all projects; 1 voter, 1 vote
  2. "By project": projects' votes; 1 project, 1 vote; a project counts as voting in favor if a majority of its voters are in favor; voters can set one project as their "home" project, default is the project with the most contribs
  3. "Per project": 1 voter, 1 vote, but divided up by project; this is so you can see if a particular wish is highly popular but only in one or a just a few projects
• Step 3: rank based on each dimension:
  • Group A: broadly popular overall: high Overall (many individual votes) and high By Project (most projects in favor)
  • Group B: broadly popular: high By Project but not high Overall -- e.g., something everybody except enwiki wants :-)
  • Group C: narrowly popular: high Per Project: things that are really popular but only in one or a few projects -- e.g., things specific to Commons, or Data, etc.
• Step 4: time and expense scores are assigned by WMF staff, like on a scale of 1-10, or actually using estimated $'s and number of months, for the most popular wishes in each of the three groups (so that staff doesn't have to spend time estimate time/expense for every wish, just the most popular ones)
• Step 5: final allocation: based on types, and time/expense scores, decide which wishes will be fulfilled, in each of the three groups. The default allocation between A/B/C might be 1/3 each, with that being adjusted if, e.g., one group has a lot of popular wishes that are quick and inexpensive, and another group doesn't. Within each group, you could again allocate by type, so for example, in Group C, include wishes tagged as Commons and Data.

Not to tell you how to do your job or anything, but it might be worth taking past wish data and running it through an example system to see how it would shake out? Having never counted wish votes, I'm kinda shooting in the dark about whether what I'm imagining would at all work in reality. :-) But I think any potential system could be tested using past data. Levivich (talk) 22:57, 1 September 2026 (UTC)

1. Totally agree on filtering out any wish that would not be picked up regardless of vote -- I'm hoping this will be done for the most part during the triage process prior to the vote.
2. Your tabulation suggestion is interesting! Definitely something we can play around with to see how else we could slice it, and I like how you're thinking across different dimensions.
3. See above
4. Agree and I imagine this for the most part happening during triage with the working group that would consist for staff and volunteers. Ideally voters would have that information when they vote on a wish, so that they can factor impact and cost into their decision.
5. This is the only step I see happening after the vote. I agree that this should include a mix of the factors you describe, and maybe we keep it as simple as looking at the top voted wishes in each bucket to compare them by impact and effort.

In the past we had different models -- in 2020 for example we actually excluded Wikidata and Commons because they had teams dedicated to them, and that same year the team committed to non-Wikipedia content projects only, while in 2021 we added "historically excluded communities" as a factor into how prioritization was scored. I think this shows that even though we tried different things over the years, we haven't really cracked this nut yet. SPerry-WMF (talk) 23:31, 1 September 2026 (UTC)

---

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? -- Sohom (talk) 00:34, 28 August 2026 (UTC)

---

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? -- Sohom (talk) 00:34, 28 August 2026 (UTC)

My first thought is that the top N unfulfilled but possible wishes, plus any that were deemed not practical last year but might be practical now, would automatically be carried over (without any votes). All others could still be resubmitted if someone desires it. This would I think reduce (but not eliminate) the burden on the community while not creating too much of a backlog. Not carrying over votes would give a level playing field with newly submitted wishes. A wish could be automatically carried over multiple times, but only if it was in the top N unfilled wishes in multiple years. Thryduulf (talk: meta · en.wp) 00:49, 28 August 2026 (UTC)

Looking just at the top N wishes from last year would definitely make this a less daunting process! Where I think it gets more difficult is to determine out of all the rest which ones were deemed not practical last year but now should be considered. For that we'd have to review all wishes again, and there would be an argument to also do this for previous years, because any year an old wish could become practical. So to draw a line at top voted wishes makes more sense to me, creating a much cleaner process. This would mean we would leave assessing all other wishes to the wisher or supporters of the wish. If they have reason to believe a non-top-voted wish became practical since the last vote, they could re-submit the wish. SPerry-WMF (talk) 21:12, 28 August 2026 (UTC)

I'd like people to have to take a tiny step to re-submit a wish for re-consideration (even just a one-click button), because so much can change in a year. I'm especially thinking about how AI companies and big tech companies are competing hard and iterating quickly, and both editors and readers get impacted in various ways and have to adapt. Something that would have been really helpful a year ago may be overcome by events. Dreamyshade (talk) 05:11, 3 September 2026 (UTC)

Agree, that a quick resubmission would be good. That way we also don't overwhelm voters with too many wishes (a problem the current system has). —Femke 🐦 (talk) 20:14, 9 September 2026 (UTC)