Talk:Community Wishlist

This page is for discussions related to the Community Wishlist page.   Please remember to: Sign posts using the four tildes (~~~~) Remain civil and polite during discussions. Place new text under old text (start a new post).   Archives: 1 2

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 3 days.

Recent activity on other Community Wishlist talk pages

This list recent changes to talk pages of Community Wishlist wishes and focus areas.

List of abbreviations:

D

Wikidata edit

N

This edit created a new page (also see list of new pages)

m

This is a minor edit

b

This edit was performed by a bot

(±123)

The page size changed by this number of bytes

29 May 2026

12:33

Deletion log Jianhui67 talk contribs deleted page Talk:Community Wishlist/How to write a good wish/it (G7: Out of project scope: please read Meta's inclusion policy)

28 May 2026

			03:28		Talk:Community Wishlist/W409 2 changes hist +641 [StefenTower (2×)]
					03:28 (cur | prev) +177 StefenTower talk contribs (→Issues & already-implemented as script: Reply) Tag: Reply
					03:26 (cur | prev) +464 StefenTower talk contribs (Basic user script that implements this)

03:12

Talk:Community Wishlist/W415 diffhist +272 StefenTower talk contribs (→Update from WMF: Reply) Tag: Reply

27 May 2026

			17:30		Talk:Community Wishlist/W222 2 changes hist +538 [Wyslijp16; MikeZ-WMF]
					17:30 (cur | prev) +288 Wyslijp16 talk contribs (→Update from WMF: Reply) Tag: Reply
					10:10 (cur | prev) +250 MikeZ-WMF talk contribs (→Update from WMF: Reply) Tag: Reply

26 May 2026

			08:50		Talk:Community Wishlist/W503/Progress 4 changes hist −210 [MusikAnimal (WMF) (4×)]
					08:50 (cur | prev) −24 MusikAnimal (WMF) talk contribs Tag: Visual edit
					08:50 (cur | prev) −114 MusikAnimal (WMF) talk contribs Tag: Visual edit
					08:33 (cur | prev) −48 MusikAnimal (WMF) talk contribs Tag: Visual edit
					07:49 (cur | prev) −24 MusikAnimal (WMF) talk contribs Tag: Visual edit

Archives

---

1, 2

Reflecting on the new process to date

We're now about a half year in to the new format of the Community Wishlist, approaching two years from the last survey, and have just passed by the time where that process would have started so I thought it appropriate to take stock of the new process to date. The Wishlist team identified three goals with the change: Improve connection, Reach more audiences, and Collaborate with other wishlists. At least in the goal of "reach more audiences" the new format has been a dramatic failure.

The new process has seen a dramatic drop-off in participation compared to the old system. So far there have been (by my count) 70 unique participants across all wishes compared to 842 in the last survey (or about a 92% drop-off). In fact there were 24 distinct wishes in the old format which had more support than the total participation so far. The most supported wish in the last survey got 240 supports, while the most supported focus area has 25 (or about a 90% drop-off). There were 115 wishes which got more support than any focus area. I am guessing that the new system is doing better on other metrics (which I'm presuming are in some annual plan that I would have access to somewhere on meta but aren't linked where I could see them on any of the Wishlist or Future of Wishlist pages so I didn't find them), but that's just a guess.

What I don't have to guess about is my own frustration and seemingly that of the mere handful of people who have participated in this page in conversations like this one. I have sympathies to the idea that the Wishlist team wanted to change the name because they knew it was no longer going to be a wishlist and wanted a new name to symbolize the new system where they would have far more control over the process, but following to the feedback for not changing the name of the process without making any other changes based on the feedback offered there suggests they didn't actually listen to the feedback. I would love to understand ways that perhaps I'm not giving enough credit for the new process, but absent that I would love to understand ways that something will radically change to course correct from what has happened so far. Best, Barkeep49 (talk) 17:45, 7 January 2025 (UTC)

I think it was wrong to assume that Meta is anyone’s project to go to for things like this. Currently, the new top-down process is pretty much pointless for outside onlookers, since you can only support ‘focus areas’, whatever those are, so posting a Phabricator task about the issue you have or a feature you want is literally 100 times more useful since at least there it would rot for years but more people would see it rotting. I am not surprised that this overhaul ended up with such result. stjn^[ru] 18:11, 7 January 2025 (UTC)

Good points. However, I wonder what measures like The most supported wish in the last survey got 240 supports would be good for: this involvement in voting and reading wishes doesn't mean more proposals get implemented. That there appears to be much activity may even just distract from the fact that only very little gets actually worked on and implemented. So I at least wonder whether level of participation is the subject/measure to worry about, i.e. instead of other things, and whether changing it would (necessarily) have much of an effect. Prototyperspective (talk) 19:49, 8 January 2025 (UTC)

Some of the promised improvements might help with engagement (individual votes/categories). However, a continuous wishlist removes the feeling of coming together with different communities, as it's necessarily slower even if we get the total engagement numbers back up.

If I remember correctly, with the implementation of the new system, the hope was that more wishes could be honoured because:

• Other WMF teams (or volunteers) pick up some focus areas
• The focus areas allow developers to work on the same code base for a longer time, so that they become more familiar with it.

If we move back to the old system, having other WMF teams work on wishes shouldn't be too difficult, I say naively. The idea of focus areas need not be lost either, but they can be made after the voting: of the top-100 ideas, make a few small (2-4 wishes) focus areas and benefit from spending more time with similar wishes. Femke (talk) 20:45, 8 January 2025 (UTC)

@Prototyperspective you're absolutely correct that the data I presented only talked about participation and did not talk about product results. However, by the WMF's own standards participation is its own goal with the Wishlist. And I think they have that right. If 10 things get done but only 2 of them were really desired by the community, that's worse for a community wishlist, than if 5 things get done but all of them were really desired by the community. So the right answer might be to keep focus areas rather than just have individual wishes. There were any number of changes made and I'm sure, as I mentioned in the original post, there is other data that is going to suggest they are worth keeping (or that it's at least too soon to tell). I am in fact not advocating for any specific change here. I am raising the alarm of what I see to be a change to community participation that has gone very poorly and which is an acknowledged goal of this process so there should be agreement from the foundation side that it needs to be fixed. Best, Barkeep49 (talk) 23:30, 8 January 2025 (UTC)

In the old wishlist system, the amount of resources/energy the WMF spent identifying tasks was wildly disproportional to the amount of energy they spent actually working on them. I agree the new system is very flawed for the reason Stjn identified, but the old wishlists have several years' worth of tasks that are mostly still relevant that they could take up if they wanted. There's a better balance to be had somewhere. Sdkb ^talk 04:40, 9 January 2025 (UTC)

• The new process has left me feeling out of touch with what the community needs or wants. Traditionally, I could expect to go through once a year and see a bunch of ideas, and weigh in, and then mostly forget about it for a year. Having it advertised on watchlists and banners and so on probably helped with that. But now, there's no pomp or circumstance, nor any deadline to motivate me. I'm not saying we need to return to the old system. But I think more outreach, at say a select time of year, might be a good idea. Perhaps it could coincide with the previous wishlist period ;)
  I also wouldn't mind having some kind of "yearly report from the wishlist" of the ideas that got suggested/supported during a year, and kind of giving the broader community a nudge to participate at that time. That could be worked into existing processes of the Foundation showing off "here's what we got done on the wishlist this year".
  I think another issue is that there are so many excellent ideas that got identified in previous wishlists but have gone unimplemented or not been raised in subsequent wishlists. Perhaps we as a community need to go through the old wishlists and identity the ideas that got left behind. CaptainEek ^{Edits Ho Cap'n!}⚓ 20:08, 17 January 2025 (UTC)

  Instead of only a yearly report, an annual collaborative event that motivates developers to implement wishes – including a leaderboard and a final report – would be better I think. Regarding further things relating to incentives, motivations, visibility, deadlines / event-type-feeling, participation, and actual implementation of proposals see more concrete readily-adoptable nearly-free-of-cost proposals here.
  Perhaps we as a community need to go through the old wishlists and identity the ideas that got left behind. Already done more or less for proposals until 2024: simply go here and see those tables Category:Community Wishlist Survey results. Prototyperspective (talk) 13:38, 18 January 2025 (UTC)

I feel the point of this change was to be able to effectively ignore Community's wishes, while projecting an image that they care about them. This is a familiar pattern the WMF has shown in recent years. Unfortunately I fear that a drop in engagement of >90% is not a bug, but a feature. Same with the voting system (by focus areas), which makes it essentially impossible for users to make their opinions heard. The current list does not even allow for sorting by votes, which makes the whole process even more frustrating and less transparent Ita140188 (talk) 14:36, 23 June 2025 (UTC)

I still don't see any substantial reason for why votes are so important when there are so little resources dedicated to actually implementing the wishes. That is the issue I think. Wishes were already largely ignored earlier with just a very small percentage of wishes ever getting implemented even a decade after they have been first submitted. Why would engagement with the Wishlist according to number of votes in particular be a good metric? It isn't. Whether or not and how people such as active Wikipedia editors can express their views on the proposals is way secondary to whether these are of any practical use at all and get implemented. Prototyperspective (talk) 13:30, 27 June 2025 (UTC)

What is your answer if not votes for how the community can say "we want development to help us with X?" I don't think this current iteration is doing a good job on the community front especially given the participation this used to get. Best, Barkeep49 (talk) 19:50, 27 June 2025 (UTC)

@STei (WMF): Do you have a ballpark of when that will be? Nardog (talk) 15:38, 3 February 2025 (UTC)

@Nardog we will get back to everyone by the close of this week with a timeline or some early thoughts I believe. The commtech team have spent the past week discussing their work offsite. They have been unavailable. Sorry for the delay everyone! –– STei (WMF) (talk) 19:15, 3 February 2025 (UTC)

Some thoughts from CommTech: Hi everyone and thanks, thank you for your patience. The Community Tech team has been away for a work offsite and also faced unforeseen challenges due to a medical emergency which has made us slower in responding to this thread and impacted our timelines for our response here as a result.

We’re back now with some thoughts to share on here is how we want to move forward with the issues raised:

Continuous Engagement: Having the Wishlist open all the time creates more opportunity for people to submit wishes on their own timeline, and without the nearly year-long wait as before. That said, improving the monitoring and triaging of new wishes is something that we are still working on improving, and there’s a balance we’re trying to get right between responding to incoming wishes and actually developing them.

We do hear from all of you here that you want more conversation with us about what is/isn’t working on wishes and focus areas, and think this is a good idea too. Specifically, our updates page will be reviewed soon to make sure we have information about ongoing work on wishes, and which you can follow to stay current on our progress.

We also hear that many of you are interested in strategies around the wishlist that might motivate more people to sign up or join in for a focused time period. This is an interesting idea - while we do think a continuous wishlist is important for the reasons shared above, we’ll think about ways to play with the idea of focused wish periods or events that could bring back a sense of fun, collaborative energy from users who liked that about the old system, and ideally use it to bring in a more diverse contributor base (which we think about a lot, and remains a top priority for us).

Clarifying Focus Areas: We hear from several of you that Focus Areas have felt confusing or process-heavy. On the WMF side, the recent introduction of Focus Areas plays an important role, which is helping connect the dots across the underlying needs of many users. While we understand that to some people this can feel like less direct influence on the final product, this is actually really important for good product design. In particular, it helps us avoid spending a lot of time and energy on a pre-determined solution without really understanding the full scope of the problem and how it impacts different types of users. While we know many of you see “total completed wishes” as the main indicator of success, we’re also keenly aware that elsewhere on the wikis volunteers (and staff!) get frustrated when we build the wrong things, or the right things poorly, or the right things well that soon become obsolete anyway. So if we’re going to build the right things for the right reasons and in the right way, we need to understand why something is needed. Focus Areas help with this.

Focus Areas also help more WMF teams participate in the Wishlist, because this problem-first approach fits well with how teams plan their goals and allocate their time for the year. For instance, Moderator Tools supported Community Tech create some focus areas around moderator topics and have adopted the Task Prioritisation for Patrollers area. The Moderator Tools team will share progress on this work soon. Community Tech  is already gathering insights through the Templates focus area case study and aim to complete our evaluation of this proof of concept and share our findings with the community.

All this is to say, Focus Areas are here to stay but with your help we do want to keep refining how we use them. This includes refining individual focus areas as needed, as well as importing old wishes into a focus area where it would make sense. Our goal is to make focus areas more practical and understandable and you can learn more about Focus Areas on our FAQ page.

I would also like to mention that our Lead Community Tech Product Manager Jack Wheeler had also separately reached out to Barkeep and discussed the concerns they had shared about focus areas. Jack is out of office on medical leave but will be back soon. On behalf of Jack and the rest of the Community Tech team, thanks for caring so much about the wishlist and continuing to reach out with your concerns and ideas.

–– STei (WMF) (talk) 17:29, 6 February 2025 (UTC)

I feel like my point above was ignored. The continuous Wishlist process is currently entirely separate from Wikimedia Phabricator despite in a way serving the same function: having WMF’s attention on things that matter to volunteers. It is hard not to perceive Wishlist process as the less fulfilling out of the two, since Phabricator tasks at least can (sometimes) get direct attention from the folks involved in maintaining a certain project and the back and forth is faster. But it seems like, from what I’m reading here and elsewhere, volunteers are told that they are supposed to use Wishlist process to get their wishes across to various Wikimedia Foundation teams. If that’s the case, then Wishlist team should implement some ways to ease up the load from participating in two duplicative community areas. Right now as a technical volunteer I am both expected to file tasks on Phabricator for everything I want to see fixed and at the same time to file wishes in Community Wishlist. Even filing tasks on Phabricator is tedious, having to duplicate that work in another venue is doubly so, especially since, as perceived, there is practically no return for it. stjn^[ru] 22:14, 6 February 2025 (UTC)

A little digression – I hate the fact that we haven't figured out the integration between the wiki space (WMF wikis) and development space (Phabricator, Gerrit, etc.) in Wikimedia. A while ago, I described an idea about having a Questions & Answers system for both volunteer and employee devs like they have on GitHub. I envisioned it to be on Phab (there is a Q&A extension for that in Phorge). In case of Community Wishlist, on the other hand, the ecosystem is being built around the wiki space. Which is probably a good idea (having to familiarize yourself with a new website is an unnecessary barrier). But there is this disconnect between the two spaces, and the users are now torn between them.

Maybe something could be done to gap that bridge. The most basic thing that comes to mind is auto-creation of a Phab task together with a wish, and keeping their statuses in sync. Some way of reflecting the last Phab activity in the wish perhaps. Jack who built the house (talk) 20:27, 7 February 2025 (UTC)

Can you give specific examples of "the wrong things", "the right things poorly", and "the right things well that soon become obsolete anyway" that you built? Nardog (talk) 22:50, 6 February 2025 (UTC)

What is the research and evidence that made you conclude moving away from individual wishes "helps us avoid spending a lot of time and energy on a pre-determined solution without really understanding the full scope of the problem and how it impacts different types of users"? Nardog (talk) 22:50, 6 February 2025 (UTC)

One thing I mentioned on the call I had with Jack was that the WMF resisted both dark mode and supporting NPP, two top place selections in the last 5 years of the wishlist. It was only through the community being able to express its support, through the wishlist, that those things finally got WMF developer attention. Focus areas are fine and I appreciate the point Sdkb made above about the learning curve, but I worry that this becomes a way to add barriers to things the community really wants actually happening. And then one thing I mentioned in a follow up email last week (which I've now forwarded to Sandister) is that by failing to respond to wishes it acts as a disserve to volunteer developers, because even if a volunteer developer picks up a task there is no guarantee they're going to be allowed to actually get their work accepted. (see [1] and [2] for two examples of a volunteer trying to address wishes I filed and reasonably meeting with some WMF resistance). Best, Barkeep49 (talk) 23:41, 6 February 2025 (UTC)

"One thing [..] WMF resisted both dark mode and supporting NPP, two top place selections in the last 5 years of the wishlist." This is not true btw. They didn't resist. They said "this is too big to do within the purview of this team". Dark mode specifically was then selected by another team, based in part on information that came out of the Wishlist, technical blockers were picked up BEFORE people started working on these areas (took 2 years) and THEN when the time was ready, the work could finally begin (another 2 years). —TheDJ (talk • contribs) 09:30, 7 February 2025 (UTC)

Thanks DJ for clarifying. I never cared much about dark mode and followed at enough distance I clearly got the facts wrong. Best, Barkeep49 (talk) 16:10, 7 February 2025 (UTC)

I think from the outside it looked like the WMF was ignoring the dark mode wish, they could have done a better job communicating that another team is starting the necessary groundwork to deliver this wish one day. But I agree that the work described in these blog posts [3][4] would have been too much for the Community Tech team – which might demonstrate how the new system could be beneficial if other WMF teams are going to pick up community wishes more frequently in the future. Johannnes89 (talk) 20:05, 7 February 2025 (UTC)

The biggest problem I see is this whole focus area thing. I think people should be voting on wishes, not focus areas. The WMF should select the focus area by banding a few related things together opportunistically, based on the vote results and I don't see why the community has to be involved with that focus area selection. —TheDJ (talk • contribs) 09:26, 7 February 2025 (UTC)

I'm a little sympathetic to focus areas and am not surprised the com tech team is taking the rhetorical position that they're non negotiable. As Skdb pointed out above the total efficiency of this team was really hindered by having to learn so many different areas of the code base. A disprotionate amount of their time was being spent in research (and presumably testing though I don't think that has been stated). So the net benefit to the community in a best case scenario is going to be higher than in the old system. But from a political point of view I'm not sure if saying "we've looked at the results and are going to work on the 5th, 6th, 11th, and 20th placed wishes as a focus area because that is the best combination that can be grouped" is something the community would tolerate. I wonder if instead there is some sort of process with community input to identify 4-6 focus areas ahead of the wishlist survey month returned, allow for new wishes to be submitted in those areas and then include all wishes in the database in those areas, vote on individual wishes and then start with the focus area whose wishes combine best. This would have some similarity to the years where non Wikipedias or small Wikipedias were the theme. But I agree that after the complete failure of com tech to get participation focus groups are the biggest problem to solve. Best, Barkeep49 (talk) 16:23, 7 February 2025 (UTC)

I feel like an easier to parse approach would be having community collect and !vote with arguments on certain proposals in one time period, then CommTech collecting and grouping those wishes so that all well-supported wishes get grouped, and then community getting to vote again without arguments on focus areas. It will be a more demanding process, of course, but it is at least transparent in the same way that Picture of the Year voting is. Being able to submit the wishes for the whole year is fine. stjn^[ru] 19:48, 7 February 2025 (UTC)

I would like to second TheDJ's suggestion: let's vote for individual wishes only, and have the focus areas created based on wishes that do well individually. Currently, focus areas combine wishes that are likely very unpopular with common-sense wishes, which makes it unclear what you're voting for. This takes away influence from the community. It also means that CommTech is using its precious resources on improbable wishes, rather than have the community bring to light the most useful wishes.

For instance, we can create focus areas from wishes in the top-20 or top-30 by category (so that smaller communities still stand a chance of having their wishes selected). Are categories still coming soon?

To respond to Barkeep: I think a large majority would be happy politically if we get wish 5, 6 11 and 20. This would honour many more votes than a potential alternative of honouring #1 and #2 which use similar resources. In the previous system, we had something similar with the prioritazation system, where each wish got weighted by technical and design complexity. This was explained well and accepted by the community. The grouping of wishes decreases both types of complexity, so I can only assume this will be accepted. Femke (talk) 09:52, 8 February 2025 (UTC)

Well, it was begrudgingly accepted by everyone, not enthusiastically accepted. With focus area system, the transparency between the wish getting added to the wish getting prioritised became even worse. I get that product management doesn’t really like democratisation, but the goal of this process is to provide WMF feedback on what communities feel like is important, so the democracy aspect got lost when CommTech decided to revamp the process despite objections. stjn^[ru] 12:55, 8 February 2025 (UTC)

Just to be clear, I fully agree with your point that the new process is insufficiently democratic.

If I remember correctly, the idea of prioritization wasn't too controversial, but some elements of it were (i.e. the low weight of the votes in some years). Femke (talk) 15:48, 8 February 2025 (UTC)

"Focus Areas also help more WMF teams participate in the Wishlist" reads like circular reasoning. If the problem-first approach fits well with how teams plan their goals and allocate their time, that does not preclude the possibility that certain problems would be better addressed by non-problem-first approaches but are exacerbated by the very structure of WMF that incentivizes the problem-first approach. Nardog (talk) 12:48, 7 February 2025 (UTC)

–– STei (WMF) (talk) 17:34, 7 February 2025 (UTC)

Again, no further replies from the WMF in this thread since posting this placeholder message in February Ita140188 (talk) 14:38, 23 June 2025 (UTC)

It's ridiculous I had to unarchive this. Nardog (talk) 16:32, 26 September 2025 (UTC)

Dear all, just to let you know that I discussed your ideas and comments with the new CommTech manager, @MEztuinaga-WMF:, and that he will provide an initial answer during next week. Also, I'm writing this to avoid the thread gets again archived. Sannita (WMF) (talk) 14:33, 16 October 2025 (UTC)

Hi all,

This is Mike, the new Technical Program Manager for Community Tech, nice to introduce myself to you all. I read your opinions, and I am thankful for your insights.

What I read from your comments is the need for a more democratizing approach to the Wishlist, and that the process is still obscure in some parts, and it looks more like a top-down approach than a fully bottom-up process. Those concerns surfaced to us when the wishlist process was refreshed last year, and we have tried to address them continuously to improve the system overall. As you can see, we have also renewed the possibility to vote on individual wishes, which was a much requested feature that you all informed should be brought back as a valuable indicator for decision making.

We are also looking at other opportunities that will help us further improve our ways of defining priorities with deeper collaboration with you. Our intention is to further improve the internal processes for selecting a focus area to work on, to communicate better in all phases of a wish’s life, and to improve the relationship with other Wikimedia Foundation teams, who will help us better deliver wish implementation.

So far, we have already delivered some solutions that have been welcomed by the wider Wikimedia community, such as Multiblocks and Favourite Templates, and we are aiming to solve the problem of clogged watchlists for long-time users who have hundreds of articles to watch. We also welcome your constructive feedback, as we aim to build a productive relationship with you as a community to deliver on what you need.

I hope this will mark the beginning of a fruitful and stable relationship between us. Please reach out to me or to @Sannita (WMF) for any feedback you might have. MEztuinaga-WMF (talk) 14:59, 22 October 2025 (UTC)

@MikeZ-WMF, @Sannita (WMF) a discord thread was raised today in the unofficial Wikimedia/Wikipedia discord server regarding some of the more recent messages that got sent out and how they were worded. TLDR, some of the messages appear to be worded in a way that imply that the wish would be marked as not fulfillable due to non-technical reasons such as the pursuit of other P&T OKRs and team direction. Since the whole point of the wishlist is to have the community inform the direction of the P&T OKRs, it feels counter-intuitive to decline a wish/mark it as non-fullfillable as a result of the P&T OKRs, since it disincentivises volunteers from filing wishes to influence WMF's P&T direction. Thoughts, clarifications would be great! Sohom (talk) 22:54, 27 November 2025 (UTC)

Discussion continued below

Declined upon migration

W260 and W269 were "submitted" and "open", respectively, but Maintenance script made them "declined", even though the associated Phab tasks are still open. Who declined them and why? Nardog (talk) 03:09, 3 October 2025 (UTC)

We are getting to the bottom of it! If any wish was intentionally declined, a reason will be provided. This may not be fully addressed until Monday. Thanks for your patience. MusikAnimal (WMF) (talk) 15:31, 3 October 2025 (UTC)

Thanks. I wondered if the same thing happened to other wishes, only to find out wishes aren't categorized by status and Community Wishlist/Wishes didn't help either. Will there be a way to filter wishes by tags and status? Nardog (talk) 09:27, 4 October 2025 (UTC)

@Nardog: Yep, filtering on tags and statuses will be coming soon: phab:T400945. SWilson (WMF) (talk) 12:48, 4 October 2025 (UTC)

Turns out there indeed are other wishes that have been declined by bots during the migration: Special:Diff/29369608, Special:Diff/29391187 (not exhaustive). Nardog (talk) 10:46, 20 October 2025 (UTC)

Once delivered, now a long-term opportunity: Special:Diff/29380378.

Once declined, now under review: Special:Diff/29426739. Nardog (talk) 10:37, 22 October 2025 (UTC)

Are you saying the new status is inappropriate? If so, that isn't clear and if you're asking for the status to be changed from what it's now I think it needs (a) reason(s). Prototyperspective (talk) 13:22, 22 October 2025 (UTC)

Well, if a bot changes something from delivered or declined to something else, I think it's pretty clear something has gone wrong. I'm not questioning the statuses of these wishes in particular per se; I'm highlighting likely issues with the migration. Nardog (talk) 13:38, 22 October 2025 (UTC)

Eek! The status changes made during the migration obviously did not go as planned, to say the least! I have fixed up the wishes you mentioned. Thank you for bringing them to our attention.

There are likely more, and I'm afraid we'll have to deal with them on a case-by-case basis. I was reviewing each and every wish manually post-migration, and got maybe 60% of the way done, before I lost my place. It is very tedious work, as you can imagine. I will try to resume that effort. In the meantime, please continue to report any wishes with questionable statuses, either here or on the wish's talk page.

Best, MusikAnimal (WMF) (talk) 19:37, 23 October 2025 (UTC)

@MusikAnimal (WMF): I've complied all changes to wish statuses by Maintenance script here: User:Nardog/Community Wishlist migration. Hope it helps. Nardog (talk) 07:18, 5 November 2025 (UTC)

Wow, this is great! The data parser function (phab:T406537) should go live today, by the way. Its entity caching would make this page a lot more efficient ;)

I will continue to re-review outstanding wishes that are declined when they weren't before. You made the job a lot easier, thank you! MusikAnimal (WMF) (talk) 19:01, 5 November 2025 (UTC)

@MusikAnimal (WMF): Hmm, it doesn't work because |field=status returns the interface name. I don't think it should, as that would still be achievable with something like {{int:communityrequests-status-wish-{{#CommunityRequests:data|id=W123|field=status}}}}.

But it at least allowed me to find user renames were not handled: W91, W105, W371.

(I also found that only the last preview warning will be shown, much like phab:T398390, but that seems neither here nor there. And {{#iferror:{{#CommunityRequests:data|...}}}} doesn't work as expected for some reason.) Nardog (talk) 04:20, 6 November 2025 (UTC)

Not done but Done

In Special:Diff/29382963, my wish Community Wishlist/W391 was marked as "Done". But the last thing I heard was: "While it’s not being prioritized right now, the Codex Steering Committee is aware of the broader need to support community use cases like this one." Can someone with enough rights update the status, or actually explain why it was changed from "submitted" to "done"? Thanks! pon_or (talk) 15:51, 5 December 2025 (UTC)

@Ponor It was a mistake done during the transition to the new system. I updated to "accepted". Sannita (WMF) (talk) 17:27, 5 December 2025 (UTC)

I'm really confused as to why you haven't undeclined/ununreviewed some of the ones marked red in my compilation. Having a small, or at least actively worked-on, backlog is vital to the health of any user-submitted system, because otherwise it looks abandoned and people give up on it. The longer this goes on the less faith they will have in the whole wishlist, and the bigger the impression that you don't care if they do. Nardog (talk) 15:35, 13 December 2025 (UTC)

Adding nontag categories to wishes

I'd like to add Category:Audio to W317: A proper audio player and maybe some more wishes about audio. However, it's currently not possible. Could it please be made possible?

This is assuming 'Audio' will not become a new tag. If it becomes a new tag, it would be a subtag of Multimedia and Commons. Allowing users to categorize wishes would also enable developing potential new tags (a category could become a tag candidate if it e.g. has a certain number of wishes) or organizing things beyond tags which would prevent there to be too many tags in the tag input box, the tag column and/or the filter options. Prototyperspective (talk) 16:31, 12 November 2025 (UTC)

Looks like you've already figured it out. You can add categories to the description and that will stick. A bit sloppy, sure, but it's all we can offer for now. I believe it is possible to allow categories outside the {{#CommunityRequests:wish}} parser function (so that HotCat works), which we can try to look into at some point. However I'm guessing it's not worth the hassle in the short-term given we have a viable workaround. MusikAnimal (WMF) (talk) 17:20, 17 November 2025 (UTC)

Thanks. I do think that cat-a-lot needs to work and ideally also HotCat for categorization of CW wishes into nontag categories – which would be really useful – to become feasible in practice in terms of actually getting done to a reasonable degree. (e.g. this to the Audio subcat WikiRadio from the Category:Community Wishlist/Wishes/Multimedia and Commons page). Do you – or somebody else here – know what would be needed to enable cat-a-lot to be able to set categories on wishes and/or whether that would be a change in cat-a-lot or the CommunityRequests-Extension? Prototyperspective (talk) 12:55, 1 December 2025 (UTC)

Issue with Cat-a-lot would be the same as HotCat – they assume categories go at the bottom. All content outside the {{#CommunityRequests:wish}} parser function (which most users can't edit, anyway) will get wiped out on the next edit. It is still fixable, just not a pressing issue. Please feel free to file a Phab task, or create a wish! :) MusikAnimal (WMF) (talk) 19:58, 1 December 2025 (UTC)

Talk header inconsistency

• Special:Search/-hastemplate:"Community Wishlist/Talk" prefix:Talk:Community Wishlist/W
• Special:Search/-hastemplate:"Community Wishlist/Talk" prefix:Talk:Community Wishlist/FA

reveal Community Tech bot's insertion of {{Community Wishlist/Talk}} is somehow patchy. Nardog (talk) 14:03, 27 November 2025 (UTC)

The bot added this before as a means to power {{Talk:Community Wishlist/RC}}, but this is not necessary anymore now that {{Special:RecentChanges}} takes a |subpageof= parameter. MusikAnimal (WMF) (talk) 02:26, 2 December 2025 (UTC)

Oh, so you don't actually care about reminding people to sign their posts, remain civil, and start new threads at the bottom? I know Wikipedia is no more a place for people with control issues than mining is a career for claustrophobes, but the inconsistency is gnawing at me! Nardog (talk) 12:12, 7 December 2025 (UTC)

DiscussionTools takes care of the signatures and thread placement, as you know. We of course want people to remain civil, but I hope we don't need a template to remind people of that :) At any rate, there is no bot involved at all with the extension, nor should there be. Someone skilled with AWB should feel free to remove the {{Community Wishlist/Talk}} instances if they so desire, or we could blank the template, etc. MusikAnimal (WMF) (talk) 15:59, 15 December 2025 (UTC)

Why were these declined

@Sannita (WMF): Why were these wishes declined? I had thought that WMF internal prioritization wasn't a reason to decline a wish, and that was the entire point of statuses like "Community opportunity".. This sort of action prevents the wishlist from becoming an expression of what the community truly wants. * Pppery * _{it has begun} 16:30, 28 November 2025 (UTC)

Community Wishlist/W287, Community_Wishlist/W39 and Community Wishlist/W41 appear to be fine at a technical level, I do not understand why these were declined. Sohom (talk) 00:14, 29 November 2025 (UTC)

@MikeZ-WMF Thoughts would be welcomed! Sohom (talk) 00:14, 29 November 2025 (UTC)

If any wish was intentionally declined, a reason will be provided. Apparently not!

It's also unclear who MikeZ-WMF is speaking on behalf of as it's a red link. I didn't notice you were the head of CommTech because the account had been renamed. I suggest you create a user page as a start. Nardog (talk) 04:26, 29 November 2025 (UTC)

To be fair, on each of the wishes declined in my link there is an explanation on the talk page. It often amounts nothing more than the boilerplate "The team responsible for this is focused on other priorities and they don't see this as fulfillable based on the direction of the team. To read about what the team is focused on, see the Product & Technology OKRs." which isn't helpful and I'm challenging as a reason for a decline in the first place - isn't this exactly what the "Community opportunity" status is for? * Pppery * _{it has begun} 04:45, 29 November 2025 (UTC)

Agreeing with the above. The "OKRs" for next year should be informed by the wishlist, not the other way around. Basic issues with citations are popular in the voting so far, and it's not sensible to turn off voting for them, if we want to deliver trustworthy encyclopic content. —Femke 🐦 (talk) 10:18, 29 November 2025 (UTC)

Hi, we’re listening to your feedback, and here’s an explanation of why we declined some of the wishes.

Firstly, we declined only 17 wishes out of 156 that we recently evaluated, and only 7 of them were for OKRs alignment reasons. Wishes do influence our year’s OKRs, but this influence is not binary, and we cannot regrettably prioritise every wish in our year’s activities that are decided at a higher level in advance.

Also, voting is now allowed all year long, but the caveat is that wishes need to be considered against already decided OKRs for the year. Nevertheless, they can also be picked up for our Wishathons, or be considered as a long-term opportunity, and be revisited in the future.

We also want to underline that the majority of wishes we evaluated were either accepted or sent to additional evaluation with other stakeholders, and/or we plan to re-evaluate them with next year’s OKRs. So, we are open to listen to your wishes, and we are doing our best to address them in time.

Hope this helps! Sannita (WMF) (talk) 13:50, 1 December 2025 (UTC)

(reposting from the thread above since I realized I duplicated the responses) @Sannita (WMF) I do understand that the influence is not binary and that some tasks will not make the cut for prioritization, but I don't understand why it was declined. To my (and the communities) understanding, baed on how the wishlist was previously setup, when a task is declined, it is not available for any of: Nevertheless, they can also be picked up for our Wishathons, or be considered as a long-term opportunity, and be revisited in the future. for what it is worth, volunteer developers will gloss over anything that will be declined and the chances of it being picked up, supported get reduced to effectively zero making it's chances of being prioritized drop. In my experience, marking a task as "declined" does not make sense outside of technical infeasability or being out of scope of the Product and Tech department. Sohom (talk) 14:25, 1 December 2025 (UTC)

Agreed with Sohom Datta. I think you should have a separate status for "contrary to WMF priorities", or whatever you want to call it, which still allows people to vote and volunteers to implement it if they wish. Actually I had thought "Community opportunity" was that status - could someone explain what the difference between a "community opportunity" wish and one you declined is? * Pppery * _{it has begun} 17:07, 1 December 2025 (UTC)

Repeating since this question has been ignored while wishes continue to be marked declined. Could someone explain what the difference between a "community opportunity" wish and one declined as "contrary to strategic priorities" is? * Pppery * _{it has begun} 22:37, 6 December 2025 (UTC)

@Pppery We acknowledge the feedback, we're discussing internally to evaluate it and we'll get back with answers early next week. Thanks for your patience. Sannita (WMF) (talk) 13:42, 7 December 2025 (UTC)

@MikeZ-WMF: Your silence leads me to wonder if your team actually has the authority to overturn these declines. If you don't, I'd appreciate if you just said so, along with who does. Nardog (talk) 12:08, 7 December 2025 (UTC)

Declining stops voting, so that it's not possible for these wishes to inform next year's OKR if they turn out to be popular. Which makes it less likely they'll be positively evaluated next year.. —Femke 🐦 (talk) 19:21, 1 December 2025 (UTC)

Hi all, first of all thank you again for your concern and feedback. To answer your questions, we wanted to remind you that we declined only 7 wishes out of 156 for misalignment with this year’s priorities. This is because we are trying our best to accommodate as much as possible requests from the community, and finding a team that would be suited best to follow up on them.

As for the difference between “community opportunity” and “declined”, I point you to our FAQs, but in general a “community opportunity” is something that can be worked on feasibly by the community (especially if there is some interest in getting it solved), while a “declined” wish is something that is just infeasible, misaligned with priorities (i.e. contrary or not fitting into planning) or out of scope for our teams.

That said, what we decided internally is to use even less the “misaligned with priorities” reason for declining, and be more specific on why we are declining the wish. Alternatively, we decided to expand the possibility of categorising a wish as “community opportunity”, especially if the community has already expressed interest and support. This is specifically in response to Femke’s comment, about being able to potentially reconsider wishes when we discuss our next year’s priorities.

Please note that every wish is decided on a case by case basis, so guidelines are not strict rules. If you have more information about the feasibility or impact of a wish, this feedback is helpful for us to reach an updated decision.

I hope this helps to clarify the situation. (Also, I would like to ask you for a bit of patience in the next days, as I will be less present due to personal reasons and be slower to respond) Sannita (WMF) (talk) 17:28, 8 December 2025 (UTC)

I'm glad that 'misaligned with priorities' is going to be used less. I wonder if the solution could be to allow for votes to continue despite a tag of 'misaligned with current priorities'? That way, the community can express whether they agree with these priorities or not? Keen to hear if this will change the decision on declining one of the two wishes of citations not working well in infoboxes (or in other templates). My impression is that it's technically difficult to fix this 'templates in templates' issue, but that might solve other with VE as a bonus. —Femke 🐦 (talk) 08:04, 11 December 2025 (UTC)

The community is obviously not bound by the WMF's annual plan and is capable of working on things the WMF deems misaligned with their priorities. That's why I see "misaligned with priorities" and "community opportunity" as one and the same. * Pppery * _{it has begun} 02:04, 13 December 2025 (UTC)

Agree and thought the same. However, there are some things that can only be implemented/enabled by the WMF so if they decide to not do it, it makes it basically impossible for volunteers to do.

Went to the linked declined wishes' talk pages to find out why they were archived and for 1 of the 3 linked wishes W39: Make it easier to use sfn in VE , it makes sense: I wanted to add some specifics to why the wish was declined: the main reason is that, in the long term, we want to see sub-references render sfn obsolete. The Editing team is already working on a MediaWiki solution that would create sub-referencing in a way that is compatible with VisualEditor. For another 1, it's kind of reasonable as well but info about why is still missing: W41: Defining multiple mail addresses and I requested further rationale on the talk page Is there any reason for why only one email can/should be entered? Don't see why this was declined albeit few websites have the option to enter multiple mail addresses and this is probably only something that WMF employees could implement, not volunteers. Prototyperspective (talk) 12:22, 13 December 2025 (UTC)

Don't see why this was declined albeit few websites have the option to enter multiple mail addresses and this is probably only something that WMF employees could implement, not volunteers.
You are very much mistaken about the capabilities of volunteers :) Iniquity (talk) 12:45, 13 December 2025 (UTC)

You misunderstood. This is functionality that as far as I understand it can only be enabled (see prior comment) by WMF, not volunteers. Prototyperspective (talk) 13:48, 13 December 2025 (UTC)

You misunderstood. This is functionality that as far as I understand it can only be enabled (see prior comment) by WMF, not volunteers.
But it works a little differently :) Iniquity (talk) 15:10, 13 December 2025 (UTC)

@Prototyperspective Yes and no. I do think enterprising/well-versed volunteers theoretically could definitely fulfill the wishes, the way I see "community opportunity" is a subset of "declined because OKRs" in areas where the community has traditionally stepped in (like saying developing user scripts or similar) Sohom (talk) 12:51, 13 December 2025 (UTC)

I do think enterprising/well-versed volunteers theoretically could definitely fulfill the wishes the info missing is what wishes you refer to and why. Assuming you mean the email one: how would they be able to change the backend of WMF without access to it and change the preferences users have? Hacking into WMF servers? If you also meant the sfn one: the reasoning there is another, namely the cited one. Prototyperspective (talk) 13:51, 13 December 2025 (UTC)

@Prototyperspective For both, volunteer can (and regularly do) contribute open-source code to MediaWiki, to change Wikipedia's (or for that matter any other project) backend infrastructure. For emails, there might be a requirement to make database changes, which can also be requested on Phabricator and implemented during deployment windows (often by volunteers with shell access). For sfns, yes the WMF is pursuing a different solution, but that should not be a block for enterprising volunteers from contributing code to MediaWiki to make sfns compatible. Sohom (talk) 15:03, 13 December 2025 (UTC)

I know. I now explained it twice. Once again, this is not about the coding but about accepting/enabling the change. Once again, if the WMF says it won't accept the backend change, there is no use in letting volunteers implement the coding. Regarding sfns, would it make sense to develop this even when it's about to become obsolete? Prototyperspective (talk) 15:09, 13 December 2025 (UTC)

if the WMF says it won't accept the backend change
They can't say that because it's open source and the code is written/approved not only by the WMF, but also by volunteers. Iniquity (talk) 15:13, 13 December 2025 (UTC)

I mean; in theory, a team acting as a code steward could state that something specifically shouldn't be merged/implemented into a codebase or component that they're the stewards of (and therefore specifically responsible for maintaining). Best, ‍—‍a smart kitten_[meow] 16:43, 13 December 2025 (UTC)

I doubt very much that the answer here is "WMF will not accept the change". By that logic, 90% of changes made by volunteers would be rejected. My understanding of "P&T OKRs" is that it encompasses what the WMF is prioritizing in a specific year. Volunteers can and do implement changes that are outside this narrow spectrum all the time. (Also +1 to Iniquity's point that there are literally volunteers who have the access to merge and deploy code on production servers and a select few who even have shell access). In my experience the only two scenarios where I've seen code contributions be rejected by the WMF is due to maintainability concerns (wrt to deploying new extensions) or alternatively due to security concerns, non of which fit either of these two wishes being brought up. Sohom (talk) 15:28, 13 December 2025 (UTC)

My understanding is the sfn wish is not eligible as a Community Opportunity given sfn is slated to be replaced by subreferences. An interim solution for sfn is deemed as very complex, so it would make sense for the Editing team to dissuade working on it – if for nothing else, to prevent wasting volunteer's time. MusikAnimal (WMF) (talk) 15:50, 15 December 2025 (UTC)

Ah, yes, refusing to support the existing features the community has developed in favor of some bold new thing. I had thought that the point of the community wishlist was to escape that sort of logic. w:WP:CITEVAR means that we won't have some sort of universal declaration that sfn is deprecated and subreferences should be used instead, however much someone may want to happen. * Pppery * _{it has begun} 19:44, 15 December 2025 (UTC)

I imagine subreferences will be a clear improvement, and once live on enwiki, CITEVAR would adapt accordingly. There's more info at WMDE Technical Wishes/Sub-referencing. It seems like the project is pretty close to completion. I see lots of mentions of sfn on the talk page. You may be able to find answers there. Hope this helps, MusikAnimal (WMF) (talk) 23:31, 21 December 2025 (UTC)

I think you've overestimated the will of the community to make changes by an enormous margin. * Pppery * _{it has begun} 23:38, 21 December 2025 (UTC)

Assuming you mean the email one: how would they be able to change the backend of WMF without access to it and change the preferences users have? Using the "second email address" wish as an example, there's procedures for changing the database schema in production. For example, wikitech:Schema changes#Workflow of a schema change. It does need WMF buyoff though (specifically the DBAs), and for good reason. Schema changes in production are very time consuming, so it would need to be worth it. As long as it got a green light though, a volunteer could start the process and participate in a lot of it, from creating the Phab tickets to writing the patches. Then the DBAs would handle the schema changes. –Novem Linguae (talk) 16:49, 15 December 2025 (UTC)

Hi everyone. Wait, am I right in thinking that the new wishlist is also annual and I have to re-iterate my wish each year? Iniquity (talk) 09:47, 13 December 2025 (UTC)

No, why do you think so? Prototyperspective (talk) 12:15, 13 December 2025 (UTC)

Also, voting is now allowed all year long, but the caveat is that wishes need to be considered against already decided OKRs for the year.
Since proposals are rejected based on this wording, it is difficult for me to draw any other conclusion. Iniquity (talk) 12:43, 13 December 2025 (UTC)

Thanks for explaining. It doesn't seem like that was meant as reason for declining, see or be considered as a long-term opportunity, and be revisited in the future – the annual priorities/goals play a role not in declining but for deciding which status to set as far as I understood it. Prototyperspective (talk) 13:47, 13 December 2025 (UTC)

But now it works like this. Iniquity (talk) 15:09, 13 December 2025 (UTC)

@Iniquity No, you don't need to reiterate your wish every year, submitting it once is sufficient. Sannita (WMF) (talk) 14:12, 15 December 2025 (UTC)

@Sannita (WMF), but if it is declined within the current year, then what should I do? Iniquity (talk) 16:59, 15 December 2025 (UTC)

@Iniquity In case it gets rejected, you may bring up a case for why it should accepted/reconsidered for community opportunity, we are open to revisit such cases. Sannita (WMF) (talk) 11:43, 16 December 2025 (UTC)

Well, that is, as I say - resubmit. Iniquity (talk) 12:24, 16 December 2025 (UTC)

Or worse than that, arguably, as after phab:T409613 resubmitting at least instantly opens the vote (until it is declined). Nardog (talk) 13:13, 16 December 2025 (UTC)

@Iniquity No, resubmitting would be marked as duplicate, you can argue for a change of status in the talk page of the declined wish. Sannita (WMF) (talk) 13:45, 16 December 2025 (UTC)

I'm sure Iniquity is saying that having to argue for a change of status in the talk page of the declined wish is tantamount to resubmitting, not that they intend to actually resubmit a declined wish. Nardog (talk) 13:56, 16 December 2025 (UTC)

Yes, that's exactly what I meant, thank you :) Iniquity (talk) 15:11, 16 December 2025 (UTC)

So we're back to the annual wishlist, because now if you don’t get it in the current year, you need to request to include your wish in the list next year. Iniquity (talk) 15:13, 16 December 2025 (UTC)

@Iniquity No, because you can argue for reconsidering whenever you want, but at the same time, I wouldn't ask every year to reconsider a wish, if it has been declined multiple times. Sannita (WMF) (talk) 15:22, 16 December 2025 (UTC)

No, because if it is rejected with the wording "decided OKRs for the year", it is logical that it will definitely not be accepted this year. Iniquity (talk) 15:24, 16 December 2025 (UTC)

I wouldn't ask every year to reconsider a wish, if it has been declined multiple times.
Oh, am I right in thinking that the WMF will filter out requests they don't like? And even if a request has overwhelming support in one of the communities, it can still be rejected? Iniquity (talk) 15:26, 16 December 2025 (UTC)

If a request has support from community, it will very likely be categorised as community opportunity, or as a long-term opportunity. We try as much as possible not to decline wishes, as we shown in the last batch, were we actually recategorised potentially declined wishes into something we're willing to work on. As I said, every judgement is on a case-by-case basis, so I cannot predict 100% what will be the fate of a wish, but we're trying our best to accomodate as many requests as possible for us. I get the frustration for rejected wishes, but they are a fragment of the whole set, that overwhelmingly gets considered. Sannita (WMF) (talk) 10:32, 17 December 2025 (UTC)

┌───────────────────────────────────────┘
I understand the concept, but I don't see why it applies to an open wishlist, which generally shouldn't be closed. Or it should be, but for purely technical reasons: duplicate, empty, and so on. Iniquity (talk) 11:25, 17 December 2025 (UTC)

If you decline a wish it can't have support from community... Nardog (talk) 13:54, 17 December 2025 (UTC)

Declined status should be mentioned on the page, not just in the top right corner

Took me awhile to find the "Declined" chip in the top right corner. I'd recommend also adding "Status: Declined" / "Status: Open", etc. as a subheading under "Description". –Novem Linguae (talk) 20:28, 28 November 2025 (UTC)

We have a template now {{Community Wishlist/Decline}}. It needs some work. I can help add those (eventually, we'll get it automated). MusikAnimal (WMF) (talk) 05:50, 30 November 2025 (UTC)

Reason for decline should be mentioned

To increase transparency and communication, reasons for wish declines should be mentioned when declining. Perhaps this should be collected in a text box when pushing the decline button, then published in a subheading under "Description". "Decline reason: ABC". –Novem Linguae (talk) 20:29, 28 November 2025 (UTC)

@Novem Linguae You're right, in fact I am now updating the relevant declined wishes with the proper {{Community Wishlist/Decline}} template. I just forgot to do so. Sannita (WMF) (talk) 14:26, 5 December 2025 (UTC)

Refocus

So, I looked at every wish in Category:Wishes declined as contrary to strategic priorities. They are:

• W18: Make it possible to reuse citations from infobox in VE
• W34: Hosting of free fonts in Commons
• W39: Make it easier to use sfn in VE
• W41: Defining multiple mail addresses
• W112: Literatur auch in Einzelnachweisen erlauben
• W121: Blocking of fake signatures --[[User:Testuser|resutseT]]
• W287: Simplify the creation of route diagrams
• W334: Issues-based Discussion for Articles

In reverse order:

• I'd have declined W334 as "about local policies and guidelines" instead - it's proposing a fundamental social restructure of the wiki, not a technical change.
• I genuinely do not understand why W287 was not a community opportunity - I understand why the WMF editing team would not want to support for a local template but I don't see why that can't be punted to the community. It's kind of vague an difficult to action, but I think the community could build such a thing as a gadget for example without any resistance and it wouldn't have to interact with anything else.
• I'd probably have decline W121 as "about local policies and guidelines" or maybe "not requiring engineering resources" instead - it's really more of a social issue than a technical one. It's also something that could be handled by a local abuse filter if one were wanted (and said abuse filter would be fairly easy to code).
• W112 is proposing a basically trivial patch to the Cite extension. I don't understand the social reasons for that proposal very well, but if I ignored whether it was a good idea or not I could write a patch for it in 15 minutes. I'm also not sure why Community Tech is the listed team here, isn't Cite maintained by WMDE instead?
• I'll let the discussion of W41 above stand on its own and not add my own commentary.
• W34 is at least an exception to the "community can do anything it wants" dogma I claimed above, in that it is essentially requesting the installation of a new extension, which currently requires WMF stewardship (another rule that I think is both hypocritical and needlessly hostile to the community - see more ranting at w:User talk:Clovermoss#Possibly interesting).
• Which then leaves W18 and W39. I actually spent some time trying to write a patch for W39 and didn't get anywhere, so it really is technically hard, and it's in a codebase with very few contributions by people other than WMF or WMDE staff. And I've said what I have to say about W18 above, but it combines multiple bits of awkwardness together including the fact that codebases on Gerrit shouldn't generally be aware of wikis local conventions. I think parts of W18 could be implemented as an on-wiki gadget or user script since it's all JavaScript (so in that sense nothing stops the community from working on it) but probably nobody in the community understands the internals of VE well enough to write said script.

* Pppery * _{it has begun} 21:50, 18 December 2025 (UTC)

I agree with almost everything. Iniquity (talk) 07:32, 19 December 2025 (UTC)

+1 on this, though I would consider W34 not a "we cannot build a extension" problem, but one of getting the security team to sign of on the concept of hosting font files (and subsequently loading them through TemplateStyles) and having some work done on the media infrastructure to make sure it can be used properly. I think the proper step there is also to start with a RFC of some sort on Commons. That is probably the only one I can see deserving of a "cannot be prioritized" label since it does require a significant amount of buy-in from the WMF. The rest could probably be thrown into other categories or be left in the Wishlist for next year/time and not declined. Sohom (talk) 21:45, 19 December 2025 (UTC)

There already is an RfC about this on Commons and the wish links to it. I think W39 is reasonable to decline if this is legacy code about to be deprecated. Prototyperspective (talk) 22:14, 19 December 2025 (UTC)

My guess is there will be a bit of a revolt of sfn is deprecated. Featured article writers love how neat sfn looks. Subreferencing is still an unknown. It might take off, but might not. I understand a decision to wait and see here, as subreferencing on paper is better than sfn in many regards. —Femke 🐦 (talk) 08:09, 20 December 2025 (UTC)

I'm on the fence here, I wouldn't be against the deprecation of sfns (and instead would strongly advocate for it). However, I also do recognize that the problem here is that I doubt the community would move away from old solutions due to guidelines like w:WP:CITEVAR which promote people being territorial about deprecated technologies many of which shouldn't be supported (To my knowledge we have managed to deprecate a single style in the last 5 years). Until we fix that, and the communities attitude towards keeping the old citation standards alive, adding sfn support will still be a legitimate task. Sohom (talk) 08:27, 20 December 2025 (UTC)

Declined as contrary to strategic priorities

I still want to clarify the next type of declined actions and how it interacts with wishes. Which comes first? Should users first read the development strategy and only then publish their wishes? If so, then this should be indicated at the top of the wishlist: only wishes that align with the development strategy are allowed; wishes that WMF does not like or dont want to do will be declined. Iniquity (talk) 10:30, 11 January 2026 (UTC)

It's not required, but it can help make the case. Regardless, there are other factors we look into, which are now expanded on here: https://meta.wikimedia.org/wiki/Community_Wishlist/How_to_write_a_good_wish MikeZ-WMF (talk) 17:25, 30 April 2026 (UTC)

Discontinue voting on focus areas?

Now that we can vote on (a subset of) individual wishes, should voting on focus areas be discontinued? There's a few reasons why voting makes less sense here:

• The focus areas change over time, making it unclear what you're voting for. For instance, integrating sfn in VE was part of the reference management focus area but has now been declined and removed from the focus area.
• Efficiency of time: don't make voters vote twice.
• Allowing voting means there is some pressure on the CommTech team to ensure that focus areas are continuously up-to-date. Again in reference management, popular wishes are not included (e.g. prevent VE from fabricating sources), whereas wishes with 0 supports are included.
• Most importantly, focus areas are decided by the foundation. The spirit of the community wishlist is that the community gets a say in allocation of resources. When you vote for an amorphous focus area, the ball is in the court of the foundation to interpret that vote and choose what to work on.

Focus areas are important to ensure the team working on the area uses their time more wisely, as they become intimately familiar with the code and can deliver more wishes for fewer resources. But that only works if focus areas are made from popular wishes, rather than at this early stage of the process. —Femke 🐦 (talk) 08:15, 3 December 2025 (UTC)

Reasonable question and haven't yet formed much of an opinion on this – however:

• making it unclear what you're voting for what you're voting for is described in the focus area description and title.
• Efficiency of time: It can also be more efficient for those users who didn't/don't go through all the wishes. Moreover, there aren't that many focus areas.
• wishes are not included doesn't imply to focus areas should be abandoned but that this approach to assigning wishes to focus areas needs to be changed and/or that the team(s) should do this work (better/more often)
• the ball is in the court of the foundation to interpret that vote and choose what to work on I think that an intention where votes aren't taken super literally as the only indicator but internal professional in-depth analysis combined with this to form a more performant collective intelligence. That's an optimistic interpretation, it may also be different. Regarding this, I think that top/high-voted wishes should clearly also be highly prioritized, unless there's good reasons against them like mainly it being near impossible or incompatible with current Wikimedia policies (things like 'we think this needs more research regarding usefulness/importance/impact/… first' would for example not be a good reason).

1. Focus areas allow people to see the forest instead of the trees and vote on areas of improvement.
2. An alternative that may be better or could be integrated with focus areas would be voting on categories. So for example instead of voting on the broad 'Media formats, editing, and display' focus area, users could vote on a new subcategory of Category:Community Wishlist/Wishes/Multimedia and Commons about wishes relating to Audio if they think that format is important / has potential / should be worked on (e.g. I think it is because one could feasibly double real-reads of Wikipedia articles per day by that). Another idea would be to allow users to specify importance ratings (e.g. I think 3D STL models are important but I don't think they would have as much of an impact as doubling Wikipedia reads) – giving people just the binary choice of voting or not voting is fairly limited albeit the vote comment and the talk page can provide important useful insights.
3. But that only works if focus areas are made from popular wishes You make the assumption that things of benefit to the Wikimedia movement would all and exclusively be popular. That is a kind of populism not backed by much. It's very likely something popular would be of great benefit but that doesn't mean that things that aren't currently wouldn't be or that everything that is popular for whatever reason such as sounding great on paper are also very advantageous, a wise use of resources currently, and feasible in practice. The number of votes is displayed in the focus areas (btw, all wishes in the for strange reasons top focus area "Template recall and discovery" have 0 votes).

Prototyperspective (talk) 14:39, 3 December 2025 (UTC)

@Femke @Prototyperspective

Thank you for your feedback on focus areas. This has also been something on my mind and has come up in a few other threads recently.

Focus areas allow people to see the forest instead of the trees and vote on areas of improvement.

This really resonates with us while talking with different stakeholders and trying to get more wishes into roadmaps by showing that there are larger, recurring or growing issues in an area. Tags don't always provide the right level of granularity, and so focus areas help group recurring themes. Maybe long-term we can somehow converge by having more specific tags to cover more granular collections of wishes (e.g. Mobile UX, Developer Productivity, Contributor Recognition...), but for now let's think of what to do short-term.

It would be helpful to do a large update as we enter the new financial year in July, and maybe merge or phase out some focus areas where it makes sense. There are also emerging focus areas that we've seen. Some possibilities based on notes (wish counts might be slightly outdated):

On existing Focus Areas (wish count):

• Template recall and discovery (5): Keep - there are even more than 5 wishes for sure.
• Reference management (9): Keep
• Media formats, editing, and display (12): Keep - splitting it up would result in too many smaller focus areas
• Make it easier for patrollers and other editors to prioritize tasks (27): This is too big - how to maybe decompose into smaller and more impactful focus areas?
• Improved discovery of media files (10): Keep - there are even more wishes that came in
• Improve how categories are presented on articles (3): Keep - there are even more than 3 wishes for sure.
• Help newer contributors understand the status and rationale behind a moderation decision (2): Maybe merge into a higher level Moderation focus area? There are many new wishes that could go there.
• Help content reviewers more efficiently manage their repetitive tasks (7):
• Create new consumer experiences for learning from / engaging with Wikipedia content (5):
• Connecting like-minded contributors (5):
• Citoid improvements (3): Close or merge into another higher level theme
• Better stitching between Commons and other projects (4): Maybe merge into general Commons improvements as the amount of Commons wishes has gone up
• Article Creation Guidance (8): Keep - there is even an OKR around this
• AbuseFilter Improvements (5): Maybe merge into a higher level Moderation focus area

Possible new Focus Areas:

• Developer velocity and recognition: Wishes related to helping developers get started and ship faster plus recognition their work
• Mobile UX and Desktop Parity: Wishes related to mobile web, Android and iOS plus gaps with desktop (either way - missing on mobile or missing on desktop)
• Internationalization and accessibility: Wishes related to parity and ease of making features work for other languages, locales, and also user experience for audio, subtitles/closed captioning, and more.

This is nothing final - just some initial thoughts from notes I've been taking over the past few months, so not everything has a suggestion. MikeZ-WMF (talk) 18:02, 30 April 2026 (UTC)

False update

@Sannita (WMF): "the template preview wish" is not a case where "we were able to resolve all of it". Please fix it. Nardog (talk) 10:40, 3 December 2025 (UTC)

@Nardog Tim already replied to you on T279736, so I consider his answer to be final on the matter. Thanks. Sannita (WMF) (talk) 11:32, 3 December 2025 (UTC)

What's not resolved is what's not resolved. The task has stood for as long as it has precisely because it can't be done with the current APIs. You put only your own credibility at risk when you exaggerate. Nardog (talk) 11:56, 3 December 2025 (UTC)

Badly written "How to write a good wish"

I don't think Community Wishlist/How to write a good wish is good guidance:

1. we encourage wish proposers to articulate a single problem they face without providing an explicit solution, so that volunteers and staff have space to problem-solve together this fails to consider that there is also space to problem-solve together on the talk pages of wishes where a or multiple solutions have been described – if a better solution has been found, the wish could be edited to add or adjust the solution proposal and if it isn't a new wish about that could be created. Wishes without solutions are unclear and not helpful, e.g. overly broad, not actionable, not much of a contribution (e.g. doesn't inform technical development much and doesn't explain how the problem could be solved), and often not technically solvable at all.
2. Wishes that do not correspond to the strategic priorities of the current Annual Plan will be declined is this the 'Community Wishlist' or the 'Wishes with WMF's blessing for being perceived as aligned with WMF's contemporary strategic priorities'? Wishes can inform strategic priorities and maybe strategic priorities are not optimal or haven't considered sth that a wish author did and which is a valid proposal. This negatives much of the whole point of the Wishlist.
3. whereas the solution-led example might receive negative feedback from contributors who resist renaming a user sandbox. that's another advantage of specifying clearly what is being proposed instead of writing something that is entirely unclear where people supporting it don't actually support the solution (of likely several) that is then built.
4. Title Make it easier for newcomers to create their first article [vs] Rename sandbox to “Draft editor” the former is not better because it's super broad and as a wish reader and voter, it's not clear and doesn't follow that this wish would be about renaming the sandbox to "Draft editor", nor would it have much of an impact in regards to making it easier for newcomers to create their first article which certainly wouldn't be solved by renaming the sandbox like that plus the wish with that title also certainly isn't [a wish that is] bigger than a bug, but take[s] less than a year in terms of engineering work and (/or?) has a very unclear title where clarity and descriptiveness is important in an ideas bank and requests list with over 400 items and a table + categories that only show the wish title. In this case, a good title would be sth like 'Rename sandbox to "Draft editor" to make it easier for newcomers to create their first article' which is clear and specific.

I very much oppose the current content of this page and would support its deletion or overhaul for the 4 reasons elaborated above. Moreover, I think for a Community Wishlist, the community and/or constructive deliberation should define what constitutes a good wish, not top-down WMF instruction. Prototyperspective (talk) 19:21, 22 January 2026 (UTC)

@Prototyperspective Thank you for your feedback and for the time you spent analysing the page. Regarding the part about Annual Plan, we'll revise that bit because we noticed it's not quite true to what really happens (since we decline only wishes that are 100% on the opposite direction of the plan, and as we defined in previous conversations, we will use this motivation less and less).

We also agree that the page can be written in a better fashion, so - since in our team's advice, your wishes are usually well written and very clear - how would you rephrase the parts of the page that you are criticising? We're really interested in knowing your perspective and your advice on how to rewrite the page, and more generally we welcome input from the community on this issue. Let me know. Sannita (WMF) (talk) 10:44, 28 January 2026 (UTC)

Thanks for the reply, looking into it a bit, and being open to feedback.

Regarding point 2, an idea would be to introduce a new tag and/or status like "Contradicts strategy" or "Outside strategy scope" or sth like that. Sounds good, thanks.

I think one can also make good advice or improve advice without one's outputs being role-model-like optimal and I'm well aware some of my wishes could be more concise (or too long to read in full albeit reading the intro in these cases often suffices) where I'll think about what to do with the nevertheless valuable ideas (e.g. lists of potential use-cases & applications) such as collapsing them or putting them on the talk page replacing the long text with a short summary etc. (Just meant to clarify this as context.)

1. For example, we encourage wish proposers to articulate a single problem they see and to consider editing wishes as appropriate if there has been feedback to give volunteers and staff space to problem-solve together or
we encourage wish proposers to articulate a single problem they see and to outline how they think it could or should be solved

3. Instead of The problem-led example leaves the solution open-ended and invites collaboration, whereas the solution-led example might receive negative feedback from contributors who resist renaming a user sandbox. for example,
In some cases, it can be better to just outline a problem without specifying a solution if it's unclear how it could be solved or if there's many ways to address the problem without it being reasonable to at this point to pick any particular one(s) thereof. or
Wishes that only describe a specific problem that can be addressed in technical ways but not any solution(s) are also welcome. or
For wishes about problems that can be addressed in a multitude of technical ways, it is recommended to not make the solution(s) too narrow and to avoid describing just one of multiple mutually exclusive possible solutions.

4. Basically changing the recommended title to Rename sandbox to "Draft editor" to make it easier for newcomers to create their first article or to Rename sandbox to "Draft editor" to make draft-creation more accessible to newcomers or Rename sandbox to "Draft editor" to get more newcomers to create draft articles. Btw, "make it easier for newcomers to create their first article" sounds like a good name/scope for a focus area and/or the scope of a new category for wishes like "Wishlist/Wishes about simplifying article creation".

Prototyperspective (talk) 14:25, 28 January 2026 (UTC)

Thanks a lot @Prototyperspective I am making some changes now inspired by your suggestions. Feedback is generally helpful for us, especially when so constructive. Regarding your second point from the initial feedback, which was about the connection to the annual plan, I found that the edit made simplified it so much that it wasn't accurate anymore, so we reverted that edit. It is not correct that we decline wishes that don't align with our strategic goals, but having lots of wishes that are not fulfilled we need to prioritise in some way when considering what to work on, so what we do is applying a triage process that takes into account votes and the Annual Plan. This approach also allows us to draw attention of other teams across the Foundation to the Wishlist, because we are all working towards the same Annual Plan. The objective behind this is, that other teams take on more and more wishes that come from the Community Wishlist. KSiebert (WMF) (talk) KSiebert (WMF) (talk) 10:27, 29 January 2026 (UTC)

Declining a wish disables voting and removes it from Community Wishlist/Wishes, and thus prohibits it from becoming more visible even if participants support it. How is a triage process that declines wishes as contrary to strategic priorities supposed to help draw other teams' attention to them? Or are you saying declining a wish as contrary to strategic priorities means you don't think it should be worked on by other teams either? Nardog (talk) 14:59, 1 February 2026 (UTC)

Yes exactly, check the definition of "Declined" in our FAQ, where we wanted to verbalise with the definition, that we want don't want to suggest to working on a particular wish. The total number of declined wishes is very small if you look closely and it doesn't mean disallow working on an idea, but we don not suggest it. All the best, KSiebert (WMF) (talk) 11:46, 2 February 2026 (UTC)

Thanks, but I'm really confused as to how something can be not [to] be actioned by a product team and [not] recommended for a volunteer either just for a year. And let's say it can be, then I'm also confused as to why no one can vote for it during that time. It leaves no opportunity for the wish to prove it nonetheless has demand. It comes off as antithetical to the point of having a community wishlist.

You say the number of them is small and you're going to do it less, but the fact you have done it at all, and you haven't overturned it, signals something that makes us very wary of what else you'd be willing to do. It's not the act itself but the message it sends that we're creeped out by. Nardog (talk) 14:30, 3 February 2026 (UTC)

So, I think you need to restore this edit then. And rename Community Wishlist to Annual Plan Wishlist, please. Iniquity (talk) 06:13, 11 February 2026 (UTC)

Renaming Community Wishlist is unlikely to occur. We already had a major discussion in 2024 that led to this name, and without another such effort, there's no chance. StefenTower (talk) 10:22, 12 February 2026 (UTC)

Well, when this discussion took place, no one knew that the WMF would decide to turn the community's wishes into wishes for the annual plan. Iniquity (talk) 10:31, 12 February 2026 (UTC)

Your complaint is noted but changing the name won't occur due to one person's request. You will have to start an RFC. StefenTower (talk) 10:39, 12 February 2026 (UTC)

I don't think you understand :) This renaming doesn't require a community request. This wishlist isn't from and for the community now, as has been stated several times above. It's the wishlist for the WMF and its Annual Plan, so they can do whatever they want with it: including renaming. Iniquity (talk) 10:50, 12 February 2026 (UTC)

OK, so my request here is for them to keep the current name, because your argument doesn't hold any water. It's a shallow complaint. StefenTower (talk) 23:58, 12 February 2026 (UTC)

It may also be a good idea to suggest there to create an image to illustrate the problem or concept. I think wishes that include images that show what's being asked for or the problem that the wish aims to address (can be a screenshot), make wishes much clearer, likelier to get support and easier to understand. Adding sth like Consider adding an image that helps illustrate your wish. would thus be good I think. Prototyperspective (talk) 12:23, 8 February 2026 (UTC)

That seems to go against the recommendation that wishes be "problem-led" (which should have been rescinded a long time ago IMO). Nardog (talk) 12:36, 8 February 2026 (UTC)

Criticized that part of the recommendations too above – and wishes can arguably be problem-led but still also explain how solution(s) could look like or specify more clearly what's being wished – but the proposed text would not go against it (see or the problem that the wish aims to address (can be a screenshot). Prototyperspective (talk) 13:18, 8 February 2026 (UTC)

The team and I want to also provide transparency in what goes on in the triage process, so that people know and can help keep this in mind in writing a wish description. Here's a paragraph we would want to add to the article about how to write a good wish since right now it lacks details about the triage process:

When prioritizing incoming wishes with stakeholders, we take a look at three main factors to determine whether to scope and try to implement a wish:

• Wishes that have a clear and measurable impact on the community, such as increasing engagement (editing, search, discovery, etc), versus wishes where it may be harder to measure impact of the work (if at all);
• Wishes that don’t have a workaround at all to ease the underlying problem versus those that do have a workaround (intuitive or not);
• Wishes that have a wide scope for a critical set of features or users versus wishes that may just be relevant for a limited set of users (e.g. nascent feature, power users).

This is not meant to be an exhaustive list, but just to give you transparency about what goes through our triage process. Regardless of how many votes a wish receives, we do triage everything and you can help us by providing more context with the tips above.

What do folks think? --MikeZ-WMF (talk) 13:29, 30 March 2026 (UTC)

Sounds reasonable. However, re point 1 I think it could often be the case that there is clear and large impact (a sizable fraction thereof also feasibly measurable) but which/how is not immediately clear to everyone. For example, it's not always a very direct impact (eg making Commons more useful resulting in over time slowly increased use) or not an impact that is considered in itself as a goal/positive by WMF (eg more people being aware that Commons exists). Re point 2, that's an important factor but sometimes the workaround isn't really making the issue less severe since the main point/goal of the wish is sth that requires wide availability. Re point 3, it's important to consider the impact small numbers of users eg power-users could have via the functionality so one shouldn't think just in how many people would directly be affected by the immediate change but also by how many would be affected (how much) by how the feature would be feasible/likely used.

Questions or input forms etc where input on things pertaining to these three points or other points like these could be given could be useful especially if you triage a wish as rather low-impact while assigning some low confidence to the assessment or when having some doubts as to whether the understanding/info on the wish is sufficient. Things could then be elaborated and sometimes the value or use-case or impact can become clearer. Prototyperspective (talk) 00:03, 4 April 2026 (UTC)

Thanks @Prototyperspective for your feedback! Some points below:

• On impact: Yes, we acknowledge that impact is hard to quantify and not always obvious, so this is partially on the Foundation to figure out. We sometimes ask about the impact of wishes in the discussion pages where we would like community feedback.
• On severity, we don’t mean to say that we’ll never work on something that does have a workaround, but rather we’ll first try to prioritize wishes that have no workaround.
• On scope, you’re right that something that is only for power users might become more widely adopted and votes are a signal of this.

On having input fields for those, the “Affected users” field is relevant here and not so widely used yet plus we don’t want to create more barriers for questions that are difficult to answer. We can always discuss these on the discussion page too, which is often the case now when we would like clarity. The team is also very focused on implementing various wishes right now, so no changes to the form are possible at the moment. MikeZ-WMF (talk) 16:02, 8 April 2026 (UTC)

Sure, that makes sense. As for 3, that was not I was saying. Some changes may be adopted by very few users but still have a large benefit for many users – it's important to not just look at direct adoption but also at indirect impact. E.g. a tool used to update say 10000 charts across 10k articles with 100 M monthly views has a large impact even if just 5 users use that tool (this is just for explanation purposes and not to be taken literally or as some good example). Prototyperspective (talk) 15:17, 9 April 2026 (UTC)

Thanks for clarifying! We will also look at potential indirect impact from all angles such as your example. MikeZ-WMF (talk) 13:04, 13 April 2026 (UTC)

Wishes without phab issue

Is there any way to see wishes that don't yet have any phab issues linked?

It would be best if there was a default-disabled column one could enable to see a column with the phab issue links but I don't think that can be readily implemented. There probably is a way to use the search to e.g.

• see wishes one has submitted that haven't yet been linked to any phab issue so as to create these phab issues if adequate or looking if there's any
• see all wishes without linked phab issues so as to add phab issues to them (for users who know a lot of phab issues)

How to do this? Probably the insource search operator can be used for this but I can't see the wikitext and it should not show wishes that just have a phab issue linked anywhere in the text (only in the input field for the phab issue that directly relates to the overall wish). Prototyperspective (talk) 12:27, 8 February 2026 (UTC)

@Prototyperspective I'll raise this point too with the team, maybe they can find a solution to it. I'll keep you posted. Sannita (WMF) (talk) 14:04, 8 February 2026 (UTC)

@Prototyperspective I got an initial response from the team: for now, we will try a workaround for the problem, that is when we start working on a wish, we ensure a ticket will be created by us and added to the page to keep track of the wishes also on Phabricator. We thought of making linking Phab tickets mandatory, but in the end decided against to avoid to overcomplicate the submission process (many users don't know how to use Phabricator, but might have ideas for new features or requests for bugs anyway). For the rest, to search for wishes without Phab tickets, you can add insource:"phabtasks =" to the search and then in the search results you will see if there's a task assigned or not. Sannita (WMF) (talk) 11:39, 9 February 2026 (UTC)

Thanks. I thought filtering like this would work deepcategory:"Community Wishlist/Wishes" -insource:"| phabtasks = T" -insource:"status = declined" but it doesn't. Apparently one needs to use regex (I think T\d{6}). Maybe somebody here knows how to build a working query for this - does anybody?

Note that when creating phab issues for wishes created by other users it would probably be good to 1) have some delay to allow adjustments and for the wish creator to still create the issue and for people to find+link any potential already-existing phab issue and 2) set the wish creator user as the issue creator instead of the person who creates the issue on phab (unless it deviates from the wish). Prototyperspective (talk) 13:29, 9 February 2026 (UTC)

This will do: insource:/\|\s*phabtasks\s*=\s*\|/ -insource:/\|\s*status\s*=\s*declined/ incategory:"Community Wishlist/Wishes". Nardog (talk) 13:50, 9 February 2026 (UTC)

Statistics about the implementation of wishes

Here is a chart of annual wishes and the fraction that have been implemented so far:

• 
  Number of Wishes exclude Declined/Archived ones
  "Combined" is implemented wishes + partly implemented as 0.5 each
  Fraction done is 'Combined / Wishes'

For details, see the file description and matplotlib python code at the file description page.

---

Here's some things that seem useful to such/these statistics and analyses:

• Adding an 'already-solved' status in the ongoing Wishlist – things that have already been implemented before the wish was posted are currently just marked as 'Done' (in the chart these are subtracted from the wish number; please let me know if I missed any)
• Checking the tables at Category:Community Wishlist Survey results to mark additional wishes as done or partially done and archiving some wishes that are not technical etc in the ongoing Wishlist
• Letting me know if I missed any wishes marked as Done that are are just partly done – in the chart they are counted as 'partly done' unless either there is a separate wish for the remainder or the remainder is infeasible in which case they will also be considered 'Done' (again, check the file page to see which)

If you'd like to see more wishes implemented, see post The problem that underlies most issues and challenges noted here and elsewhere on the discussion page of WMF's Annual Plan.
Thanks to everyone involved in the technical development and with contributions to the wishlists so far.

Other ideas regarding the implementation of wishes would be very welcome of course as would be feedback on how to improve the chart.
If the Wikimedia movement's technical development capacities are as limited as they currently are, there's only so much that can be done. Maybe I'll make a separate thread about that subject at some later time.
If you're interested in raising the implementation of community wishes and code issues on phabricator, what you can do includes raising awareness about this and letting your voice be heard both outside and within the projects.
If you see something to improve in the chart or have ideas for further related statistics, please comment. Thank you, Prototyperspective (talk) 18:42, 28 February 2026 (UTC)

I've now added the number of top 20 wishes done per year beneath the years (of course it doesn't mean wishes below the top 20 can't also be super important or impactful). You can find more info and the raw data about all the measures of the chart on the file page. Prototyperspective (talk) 00:13, 12 March 2026 (UTC)

The latest update (thanks) on the main page claims 44 wishes as fulfilled (8% of the total of wishes); I'd like to note that these also include a) wishes that were just partly done without a separate wish about the remainder and b) wishes that were already done at the time when the wish was submitted such as W194: In Wikidata quality assessment of articles in different languages . To see why there is a difference between the counts of my chart/statistics above and these, go to the file page and open "Data with notes and explanations". The total there is 31 (+3 partly) which equates to 7.0% (or 7.3% if partial ones are counted as 0.5).

It's nice to see some progress but it could be much more (and should be imo). By the way the Statistics section currently says "78 wishes are considered community responses" which seems to be a some typo and probably should be sth like 'require responses' or 'are considered community opportunities'. Prototyperspective (talk) 00:38, 11 April 2026 (UTC)

Tracking the ways vote counts might be inaccurate

• Since December 2025, creating a wish automatically adds a proposer vote, but proposer votes for wishes created earlier have not been backfilled. (T415231)
• Some wishes have been declined as duplicates, but thier votes have not been transferred to the wishes they were deemed duplicates of. (T418937)
• A new vote for a wish or focus area removes votes by users who have since been renamed. (T412648)
• Some wishes were accidentally declined or marked done (or vice versa) during the October 2025 system migration (stats).
• Wishes declined as contrary to strategic priorities cannot be voted for, even though they are supposedly declined only for the given fiscal year.

Nardog (talk) 12:19, 3 March 2026 (UTC)

@Nardog Thank you for noticing us this. I'll talk with the team to see if we can fix the bugs in the meantime. Sannita (WMF) (talk) 12:13, 9 March 2026 (UTC)

Merging wishes and votes

I think when wishes are basically identical and merged with one being marked as a duplicate, then the votes of the source wish should be transferred to the new wish. This helps prevent votes getting lost. It also reduces workload and distractions for users. If votes are not transferred you'll probably see some votes missing from the target wish (as with the affected wishes so far) which seems unfair / suboptimal.

If there is no full solution available at this point whereby clicking a button in some UI automatically copies over the votes, then this could be done manually via copy and paste by the person who does the merge.

One example wish where votes have not been transferred is W507. There Paloi Sciurala stated I prefer not to have my votes merged automatically, since I might not agree that the second wish is a duplicate of the first one. It's also possible some wishes as declined as duplicate that are duplicating multiple wishes or are a mix of infeasible / not technical / unclear and one or multiple existing wishes. Taking all that into account two approaches that consider these complexities would be:

• generally copying over the votes but allowing for exceptions where users of the source wish are only pinged to be informed about the other wish (rarely done)
• copying over the votes of the source wish but pinging the respective users so they can check in case they want to remove their support vote from the target wish (I think this would be best and while writing this, Nardog also raised this option at phab:T418937)

This is related to point 2 of the thread above. Prototyperspective (talk) 18:26, 11 March 2026 (UTC)

Inconsistent wish dates

This Wishlist seems to be for 2024+ and all wishes have a date set except for the 3 initial planned+done wishes W1-3 as well as two that got their data changed retroactively, eg in Special:Diff/30218707 by MusikAnimal (WMF). Sort the wishes by date to see these 5 wishes.

I noticed this issue when creating the chart in #Statistics about the implementation of wishes where these inconsistent dates complicated things.

It's a problem for many other reasons too – for example, it makes it harder to see when wishes have been submitted to this wishlist and essentially hide (or move) them even if they're newer. Moreover, it's inconsistent – lots of wishes have been submitted in earlier Wishlists too but most of them have the date set of when they were submitted – can also be called "imported" – to this Wishlist.

That's also what a reader would expect that date to be. The current inconsistency also hampers tracking, comparability, etc. If anything, a second field or second date in that field could be added for the date of the original/first submission of what's described in the wish. One could also have a dedicated field for earlier Wishlist submissions similar to the one for the phabricator issue.

Please change the date created of these 5 wishes to the date the wish in this Wishlist was created, not some date of some wish in an earlier annual Wishlist. Prototyperspective (talk) 21:31, 11 March 2026 (UTC)

I agree, this will particularly be problematic when trying to get stats for vote counts adjusted for how long the wishes have been up. Nardog (talk) 10:30, 12 March 2026 (UTC)

Allow translating wishes "under review"

Now that wishes "under review" can be voted for, it's odd that those wishes cannot be translated. Nardog (talk) 14:58, 23 March 2026 (UTC)

There's nothing in the codebase stopping under review wishes from being prepared for translation. Someone just has to do it. * Pppery * _{it has begun} 16:19, 23 March 2026 (UTC)

Then I ask that those with the right (be they staff or volunteers) mark wishes for translation as soon as they see them and confirm they're not spam. W320: Possibility of adding icons for mobile view through addPortletLink has no business not being translated when the English translation has been posted on the talk page. Nardog (talk) 02:59, 24 March 2026 (UTC)

I've translated that specific wish. But that's not a full solution. Meta translation admins have been chronically understaffed for a while to the point that there are regularly hundreds of pages needing tadmin action ... * Pppery * _{it has begun} 03:05, 24 March 2026 (UTC)

Indeed, and even when it is marked for translation, volunteer translators can only do so much. We can get it translated to English most likely, but that doesn't help users who don't know English or the source language. It is for this very reason that we also offer machine translation. The goal is to enable it for all users by default, but we are waiting for capacity issues to be sorted out by the Language team before we can do that. In the meantime, head over to your internationalisation preferences and enable "Enable automatic machine translation in the Community Wishlist." if you'd like to give it a try. MusikAnimal (WMF) (talk) 16:48, 30 March 2026 (UTC)

"Existing functionality" not specified

Declining a wish as "proposing existing functionality" and then not stating what that existing functionality is even after a request feels... weird, at best. Nardog (talk) 17:09, 27 March 2026 (UTC)

Question re. Community Wishlist/How to write a good wish (bot creation)

The WMF will not create gadgets or bots, but you're welcome to add wishes for gadgets/bots for consideration by members of the community. (added in Special:Diff/29814976, FWICS.) Just out of personal curiosity, does that rule out any additional functionality for Community Tech bot? Best, ‍—‍a smart kitten_[meow] 07:19, 1 May 2026 (UTC)

For tasks Community Tech bot already does, no, it does not rule out requesting additional functionality via a new wish. We'd need a well-supported wish to justify further development, though. I'd personally rather see whatever desired functionality be brought into MediaWiki itself, which will make maintenance easier. MusikAnimal (WMF) (talk) 10:10, 1 May 2026 (UTC)

Feedback on Wishlist expectations and scope

I have to admit that parts of the current scope description feel a bit disappointing to read. One of the things that initially made the new Wishlist process appealing to me was the idea of having a more direct and responsive venue for proposing features and improvements, rather than another long-term task tracker similar to Phabricator.

Currently, it increasingly feels like wishes are being narrowed mostly to relatively small changes that already align with existing annual priorities, while more ambitious or niche ideas risk becoming forever stalled as low-priority or out-of-scoped altogether. In many cases, genuinely community-driven wishes are precisely the kinds of niche, experimental, or workflow-specific ideas while the more obvious high-priority technical issues would already be expected to fall within existing planning and development priorities and not need wishes to be handled. - Klein Muçi (talk) 00:11, 12 May 2026 (UTC)

No stranger to Phabricator and the Wishlish since its creation, I wholly concur with your current perception. Kudpung (talk) 00:28, 21 May 2026 (UTC)

May 20 update

Am I to understand from After noticing that having a centralized team was leading to frequent bottlenecks and delays as CommTech staff coordinated with other teams, we've decided to shift Community Tech into a program that multiple teams are officially responsible for supporting. This is a model that has proven success already, but it will involve disbanding the Community Tech team and the roles of five engineers and one manager. that a perceived bottleneck has been removed by... layoffs? Surely having all teams responsive to community desires is a positive goal, but it's hard to read this as anything other than "we fired five staff engineers and their manager, and other teams will now have to pick up the slack". I suppose it's true that a bottleneck will indeed cease to exist if one throws out the whole bottle. -- asilvering (talk) 18:32, 20 May 2026 (UTC)

That is precisely what that reads as. I'd like to hear more about how that "proven success" has been evaluated so far and what processes are in place so CommTech work doesn't just fall to the bottom of multiple too-long backlogs. ~2026-30375-12 (talk) 19:11, 20 May 2026 (UTC)

I as well would like to hear more about how that "proven success" has been evaluated so far and what processes are in place so CommTech work doesn't just fall to the bottom of multiple too-long backlogs. -- Just N. (talk) 22:06, 21 May 2026 (UTC)

Is there more info on how teams will ensure alignment with the communities' needs? What is the new model? Who looks after the wishlist (assuming there will still be one)? Kowal2701 (talk) 21:41, 20 May 2026 (UTC)

This feels like essentially quiet shutdown of the wishlist as we know it after it was already neutered before by this weird new system. Other teams already have work that they prioritise above the random wishes, the point of CommTech was to bridge the need for continued maintenance of MediaWiki where community feels like the WMF teams fall short. Since last July or whenever the initial changes were made, it seems like that fundamental point was lost to the WMF decision-makers, and now we see that this work is considered fundamentally second-rate so much so that the people that were doing it as their main job are getting fired/demoted and restructured.
I have a slight deja vu from reading the announcement on disbanding Design Systems Team: it was presented like Codex is in such a great state that it didn’t need any dedicated employees working on it full-time (even though it is anything but that), and then when the time came to battle-test a Codex adoption in a really visible site element, it ended up easily breaking down in a very predictable yet seemingly untested way.
I don't know if there’s a bright side to this. It seems like more and more the WMF seems to make questionable decisions that get presented like they are innovative. The problem is that the corporate speak ends up sounding like BS, in both cases. Time will show whether it will also just be BS. stjn^[ru] 22:01, 20 May 2026 (UTC)

That would explain so much why there hasn't been much action with some of the proposals in recent months... Should we let Jimbo know about this? 2601AC47 (talk) 13:48, 21 May 2026 (UTC)

I would expect that as a member of the board Jimbo received an FYI (this would be 2 levels below the kind of issue a board member should intercede on so no criticism of lack of action given that notice (at least here since I've got plenty of board criticisms). Best, Barkeep49 (talk) 14:20, 21 May 2026 (UTC)

Well, speaking of which, my friends: this just got started for a potential "solidarity strike". It feels very familiar, does it not? 2601AC47 (talk) 14:27, 21 May 2026 (UTC)

But whatever happens next, and with hindsight of the last several years, please don't

let the vandals in.

2601AC47 (talk) 14:30, 21 May 2026 (UTC)

And keep a good eye on this newly-created Telegram group. Just in case it escalates... 2601AC47 (talk) 14:48, 21 May 2026 (UTC)

And while at it, ChildrenWillListen's suggestion...

blocking all donation banners/buttons using intadmin tools and forcing the WMF to respond to our demands before allowing them back in

is a very delicious idea, but risky. Next down the line: inform a larger union like Communications Workers of America. They'll be very interested. 2601AC47 (talk) 15:58, 21 May 2026 (UTC)

Or, rather, smashes the bottle over our heads. JPxG (talk) 11:51, 25 May 2026 (UTC)

Usually you still end up with an intact bottleneck when you do that. asilvering (talk) 12:09, 25 May 2026 (UTC)

---

The Community Tech team is the team responsible for maintaing certain tools. When will we learn what new teams will be picking up that support? Thanks and best, Barkeep49 (talk) 19:21, 20 May 2026 (UTC)

---

I'm gonna quote a paraphrased part of a email I sent when I learnt about this announcement as a PTAC member:

To show just how badly things are going [for the Wishlist], the highest-voted item in the current list has 42 votes, a paltry amount of community engagement, compared to the previous iteration of the wishlist, which saw over 240 votes on the top item. If we want to talk about raw wish output and take last year as a benchmark, four major feature areas from the Wishlist were worked on: Multiblocks, Watchlist Labels, Video2Commons, and Favorite templates (I'm choosing to discount one-off "wishathons" work as anything useful in this context). Video2Commons was an Unsupported Tools Working Group initiative and, to my understanding, was handled by an external contractor. Besides that, Community Tech worked on Multiblocks, Watchlist Labels, and Favorite templates. You could theoretically make an argument that Multiblocks and Watchlist Labels had some involvement from the Moderator Tools Team, but I think the key point is that no other team stepped forward to address any issues raised through the Wishlist. If this isn't a rejection of the "other teams will do it" approach, I don't know what is. The only other team that decided to implement a "community wish" for "Reading Lists" (which I understand came from wish W102), did not consider multiple rounds of community feedback on how to implement it (cc the Watchstar debate). This is anything but a success for the multiple-team model, and disbanding the team that effectively did the most work is, plain and simple, a bad decision in my eyes.

It's also pertinent to note that among the six engineers who were made redundant were folks who have significantly more community experience than even some folks on this council (I know for sure at least 4 of them have more experience than me). This is rare to have. Two of them were former stewards, the most trusted positions in the community. Among the others, Samwilson was one of the folks who mentored me into the technical side of the community. I would trust them to know their way in figuring out what the community wants more than anything, and the fact that the Foundation does not see the immediate benefit in retaining these engineers in a job where they explicitly work on community-requested features feels extremely sad and is a significant problem.

I'm sorry, but I have no confidence that the model with "proven success already" is going to work and have lost confidence in the WMF piloting this initiative given the disbanding of the team that was doing the most amount of work to keep the Wishlist alive. I have zero support for this initiative. Sohom (talk) 22:42, 20 May 2026 (UTC)

I think that sums it up. Yet another crack in the bridge the Community has been trying to build for its relations with the WMF. Kudpung (talk) 00:35, 21 May 2026 (UTC)

Indeed, yet another crack in the bridge the Community has been trying to build for its relations with the WMF. Fine metaphor. -- Just N. (talk) 22:12, 21 May 2026 (UTC)

---

I've posted my thoughts at en:w:Wikipedia:Village pump (WMF)#WMF Community Tech team has been disbanded, engineers laid off. –Novem Linguae (talk) 23:58, 20 May 2026 (UTC)

I find this turn of events very disappointing. I've had my criticisms of the wishlist structure (sometimes it feels like a band aid for WMF managers being bad at planning, and had difficulty ensuring long term maintenance of completed wishes), but it clearly was meeting a need that will now go unfulfilled. The new program sounds like vauge platitudes that won't be followed through with when the time comes. Laying off staff as part of the restructure instead of just internally transfering them seems particularly cold and short sighted. Bawolff (talk) 02:08, 21 May 2026 (UTC)

This is extremely disappointing. The team behind the Community Wishlist must be strengthened, not disbanded. WMF is not supposed to lay off experienced people on a whim, and it is not an evil corporation last time I checked. What is going on?! Le Loy (talk) 03:03, 21 May 2026 (UTC)

What's going on, of course, is a unionization drive. I'm disgusted, but I can't say I'm shocked. -- asilvering (talk) 03:31, 21 May 2026 (UTC)

Bewildering. I am so baffled. Le Loy (talk) 03:43, 21 May 2026 (UTC)

+1 Rampion (talk) 09:42, 21 May 2026 (UTC)

What Bawolff said. Legoktm (talk) 03:16, 21 May 2026 (UTC)

---

the creator of a petition to unionise wmf employees, User:TheresNoTime, is one of the people laid off. hmm... ltbdl (talk) 03:18, 21 May 2026 (UTC)

---

How can this possibly help the encyclopedia? In addition to all the other problems, I find it peculiarly short-sighted with reference to the WMF's stated goal of raising Wikipedia's public profile. It could get a lot of attention, but not good attention. Remember how people liked it when we banned LLMs? This is the opposite of that. When I talk to students, it's clear that the "unique selling point" of Wikipedia's "brand" is, basically, "what if a website wasn't evil?" In other words, what if a website was about making something wonderful and freely available, and not about following all the latest trends of capitalist corporations? People hate AI because they hate tech layoffs and poor labour conditions. This takes all the goodwill WMF has been building with the community, and Wikipedia has been building with the public, and squanders it. LEvalyn (talk) 06:04, 21 May 2026 (UTC)

100% agree with this - none of it sits right with me. It feels more and more like the sort of decision a the higher-ups in a huge corporation would make after looking at numbers and thinking "how do we make those numbers smaller" then wandering off to figure out how to use AI as much as possible because that's what everyone else is doing.

It doesn't matter what the people at the bottom think about it, they have no say in "big picture" decisions and should just get on with scrubbing the toilets.

I don't know whether that was the intent, but that's how it feels to us toilet scrubbers. It's so out of touch that it's on freaking Jupiter. Blue-Sonnet (talk) 09:43, 21 May 2026 (UTC)

If anything, this has highlighted a complete disconnect of values between the Wikipedia community (and the WMF staff) on one side, and the WMF leadership on the other, more than any incidents about AI use could have ever done.

One of Wikipedia's greatest assets is its horizontal, consensus decision-making process, where every editor has an equal voice. "Higher-ups" can't retaliate by blocking users for disagreeing or just advocating for their rights. The WMF has told us, openly, that they don't subscribe to this model, despite it being at the heart of the community they speak in the name of. Chaotic Enby (talk) 16:14, 21 May 2026 (UTC)

I agree entirely. I came here to make a similar point. Regardless of the CommTech situation, if the WMF has any interest in maintaining goodwill and image among it's readership, it will engage in good faith with WWU. Vanamonde93 (talk) 17:23, 21 May 2026 (UTC)

Bernadette Meehan has commented at her talk page. —In solidarity with Wiki Workers United · ClaudineChionh (she/her · email · w:en) 12:20, 25 May 2026 (UTC)

English Wikipedian Solidarity Labor Action

News of this was buried in a link above, but I think deserves to be more clearly highlighted. A number of English Wikipedians have signed-on to potentially take a solidarity labor action resulting from these lay-offs and broader concerns about union busting. Other communities may be interested in discussing their own responses. Best, Barkeep49 (talk) 16:12, 21 May 2026 (UTC)

Response from WMF

Hi All, my name is Suman and I'm the Deputy Chief Product & Technology Officer at the Wikimedia Foundation. I want to address some of the questions being raised here. I cannot go into specifics about individuals but can confirm all five engineers and a manager impacted by the change are encouraged to apply for existing and upcoming roles at the Foundation. This process can take time depending on where someone is located because of local regulations around jobs changing, but we are actively supporting impacted staff through this process and expediting interviews as much as possible. The open roles are all ones that will strongly benefit from experienced engineers with knowledge of our tools, some with more specific requirements than others. I want to also confirm that there is no budget reduction in engineering as a result of this change - this was never about saving money.

Regarding the new model, over the past five years or so it has been the de facto practice inside the Wikimedia Foundation to have product teams beyond Community Tech work on wishes in their area of expertise. As I mentioned in the main update, having a centralized team was leading to frequent bottlenecks and delays as CommTech staff coordinated with other teams. In shifting Community Tech from a single team into a program that multiple teams are officially responsible for means the wishlist will continue to work on wishes from across languages and wikis. It will still have dedicated staff managing the wishlist intake and triage process and will continue the same financial support for this work, just under a different structure.

While we’ve called out a few of these in our recent Wishlist updates such as providing a warning when large amount of content has been copy-pasted which the Editing team has taken on as part of a larger project, and adding Wikipedia Mobile App’s Reading Lists to the Website which the Readers team deployed to all wikis on Beta, this is only a small sample. Moving forward, we’re going to be clearer about which teams are taking on wishes by specifically outlining that in our monthly updates of work prioritized, in progress and done.  

Ultimately, we ask that you look at the number and size of wishes we are able to fulfill in the coming months as evidence of our continued support to community wishes and hold us accountable. SCherukuwada (WMF) (talk) 16:04, 21 May 2026 (UTC)

But what about the unionization of the staff, my fellow? Just curious like many of us are right now... 2601AC47 (talk) 16:15, 21 May 2026 (UTC)

this decision is not connected to discussions staff are having about unionising. I can also unequivocally confirm this decision is not connected to discussions staff are having about unionising, or terminating staff who have participated in those discussions

Hmmm. So the drama. 2601AC47 (talk) 16:42, 21 May 2026 (UTC)

There are now 150+ signatures that're signed on to it. 2601AC47 (talk) 17:38, 21 May 2026 (UTC)

Now there are... 115 signatures on en.WP and 245 on the WWU page. Clock's ticking... 2601AC47 (talk) 13:05, 22 May 2026 (UTC)

I want to also confirm that there is no budget reduction in engineering as a result of this change - this was never about saving money. So, you laid off the staff precisely because of the union organizing, then? -- asilvering (talk) 16:19, 21 May 2026 (UTC)

Or maybe there's no budget reduction because the staff were never laid off? SuperPianoMan9167 (talk) 14:00, 22 May 2026 (UTC)

@SCherukuwada (WMF) Please respond to the charge that this looks like an egregious case of union busting. Qcne (talk) 16:19, 21 May 2026 (UTC)

This is the second time that the foundation has asked for the community to judge them on results after major disruptions around the Wishlist that the community reacted to with alarm. I certainly believe you that it's not about saving money, but what I don't believe is that the same number of resources will go to progress on the Wishlist moving forward. I don't believe this because you haven't explained how that will be true. The lack of partnership with community bodies ahead of this change to a program - like PTAC - make it harder for me to believe you're actually interested in being held accountable for results. Best, Barkeep49 (talk) 16:19, 21 May 2026 (UTC)

I agree that a reorganization without a clearly described plan on how existing projects will continue is a failure to reassure the community that vital MediaWiki support will continue. I urge WMF management to provide more specific information on its plans. isaacl (talk) 16:56, 21 May 2026 (UTC)

Hi Suman! Thanks a lot for this response. You emphasize that this was never about saving money, which is great to hear, although I do not believe this was a sticking point in community discussions. While I am relieved to know that affected employees are invited to re-apply for roles, I am still worried about the strain put on them, alongside the fact that this does not address the core issue of worker relations and freedom to join a union without retaliation. Could you please clarify the role that the formation of Wiki Workers United played in this decision, and reassure us that you will take concrete steps to support the freedom of association of your employees in the future? Chaotic Enby (talk) 16:21, 21 May 2026 (UTC)

That, too. 2601AC47 (talk) 16:24, 21 May 2026 (UTC)

I'm too concerned about union busting, and the cruelty of firing and possibly rehiring key foundation staff. —Femke 🐦 (talk) 16:25, 21 May 2026 (UTC)

It will still have dedicated staff managing the wishlist intake and triage process Why disband the team doing exactly this right now then? Why not keep employing them until they go on to other teams? Nardog (talk) 16:33, 21 May 2026 (UTC)

That's what I don't understand - if it was reorganisation and moving responsibilities to different teams, why weren't the associated staff moved to those teams? Why were they sacked? They're are only six of them, all with valuable skills and experience in that very area.

If the reorganisation was to address high workloads, why reduce the resource capacity of the WMF to deal with said workload?

Also, didn't anyone think of the optics of performing such an outwardly counterintuitive business decision a matter of days/weeks following that same team publicly exploring the possibilities of unionisation? I find it very difficult to believe that they weren't aware of that discussion.

Why now? Blue-Sonnet (talk) 16:42, 21 May 2026 (UTC)

Yes, this is really baffling to me too, and really limiting any AGF interpretations. If there’s no change in budget and no change in the work being done, how does a layoff make any sense at all? Dissolving the community wishlist team would always raise some eyebrows, but if the team members were moved elsewhere in the WMF to continue working on meeting the project’s technical needs, it would be a lot easier to believe all these assurances. LEvalyn (talk) 19:23, 21 May 2026 (UTC)

If there’s no change in budget and no change in the work being done, how does a layoff make any sense at all? Or maybe there wasn't a layoff? Do we even know for certain that they've been laid off? Isn't it a possibility that the affected staff are still employed at the WMF but need to apply for new positions internally? SuperPianoMan9167 (talk) 14:03, 22 May 2026 (UTC)

@SuperPianoMan9167 as I understand the announcement (and I feel confident from having talked to a bunch of people I have this right), at this moment they are all still employed by the Foundation. They have a period of time to find a new role with-in the Foundation, if they want. If they do not want to find a new role or if they cannot find a new role, they will be laid off and given some kind of severance. All of that is complicated by the multiple international jurisdictions involved with the impacted employees. Best, Barkeep49 (talk) 14:34, 22 May 2026 (UTC)

Surely you could write a better response than that? This is a ridiculous nonanswer. Freedom4U (talk) 16:43, 21 May 2026 (UTC)

If the five engineers and manager who were fired are competent enough to apply for alternative roles, then keeping them employed and letting them apply for the alternative roles, while retaining their employee status, would have protected these employees' mental health. Being fired and then having a chance of being re-employed is stressful. The precariat is not an appropriate model for WMF staff. Boud (talk) 16:55, 21 May 2026 (UTC)

I'm afraid there's no other words for this response than "embarassing" and "not good enough". CoconutOctopus talk 17:05, 21 May 2026 (UTC)

The WMF's aims, ethos and methods no longer bear any resemblance to Wikipedia's, but perhaps we can still work together symbiotically and both get what we want. Wikipedia editors can be a nuisance for the WMF, but the WMF does need the content we create to keep those all-important donations rolling in. Helping us to do that by fixing the bugs we find and making the enhancements we request can give a high return on investment. I understand that running an encyclopedia has changed from a goal to a necessary evil, but I'm afraid the WMF really does need to spend a few dollars on keeping Wikipedia healthy if they want it to continue bankrolling their real ambitions. Certes (talk) 17:23, 21 May 2026 (UTC)

I was hoping to see a response I could believe and take heart in. It's disappointing to see further dissembling. If the goal was not saving money, then why were any employees laid off? If the goal was reorganization, why was there not simply a reorganization? If the WMF isn't interested in union-busting, why not proactively issue a statement saying it will engage in good faith with an effort at unionization, as it is required to do by law? Vanamonde93 (talk) 18:05, 21 May 2026 (UTC)

This is ridiculous, the sooner we can sack off of this organisation the better. CNC (talk) 18:05, 21 May 2026 (UTC)

That would be difficult. We trusted the WMF with our trademarks, domain and other brand rights, so any sacking would have to be by way of a fork. LibreOffice managed it, but it would be very costly and disruptive. Certes (talk) 18:16, 21 May 2026 (UTC)

Never said it was easy and I know it won't be, point still stands. LibreOffice is great though. CNC (talk) 19:26, 21 May 2026 (UTC)

The Spanish-language fork is generally seen as having been a major factor preventing advertising in Wikipedia (apart from ads for Google) and getting the shift from wikipedia.com to wikipedia.org. A fork would be painful but might similarly lead to a re-merge with a healthy resolution of the conflict. Boud (talk) 22:28, 21 May 2026 (UTC)

Another excellent suggestion: are there admins willing to issue blocks upon request for this, should a strike occur? If I'm striking I'd prefer to do it under an indefinite block, so that a signature strike-through can help raise awareness.

We could bring this up to every other major project, like Wikivoyage's admins. Same thing for pretty much every Wikipedia language edition with over 1M articles that should be alerted if they aren't already. Shall we?

After that, if they agree to join in solidarity, inform the WWU and the CWA. Tell them everything they need to know going back years - and include all known heavy-handed incidents involving the WMF and the Wikis. After that... beats me because of my lack of first-hand experience with labor unions and the like, but as a certain little shark might say: Murr. (Bite the hand that feeds. And where they hide the donuts.) 2601AC47 (talk) 18:59, 21 May 2026 (UTC)

Sure, do as you please. I've already pre-ordered my block here for reference sake (pending admin confirmation). A more centralised location to coordinate 'self-blocks' would make sense if there is interest. However, bare in mind it's likely many editors subscribed to a strike will likely want to remain active on WP mainspace/talkpage at minimum, in order to discuss the strike, so this strategy won't be for everyone (probably a shy minority). CNC (talk) 19:30, 21 May 2026 (UTC)

I already did. They will join eventually, and I expect it will be soon. 2601AC47 (talk) 19:32, 21 May 2026 (UTC)

Thanks for fixing my link as well, good use of free will that. I've subsectioned self-requested blocks here as a reference point, should there we further interest. Multiple admins are willing. CNC (talk) 22:00, 21 May 2026 (UTC)

Anyway, I've just conjured a creative little statement from that sweet good boy Jeff on my talk. I may have gone overboard during its making. And... he may have bit a few bureaucratic-looking people along the way. And the CEO. Twice. He's got an appetite for the sort of thing that we're dealing with.

Have a look. 2601AC47 (talk) 14:07, 22 May 2026 (UTC)

So far I dont understand if the staff was laid off or is still employed at the Wikimedia Foundation getting now time to find another role within the Wikimedia Foundation. From my point of view it is important to make internal restructuring public to the affected employees early enough before this is announced in public. And I think laying off people should be avoided when ever possible. The Wikimedia Foundation as a non profit should act in a very social responsible way and in this case so far it does not seem to me like it is happening in such a way. When has the Wikimedia Foundation informed the staff about the restructuring. In Germany such things often happen for example 3 months before the restructuring is effective and some days before it is announced. So I wish this is also true for the Wikimedia Foundation and you will learn from this situation. Hogü-456 (talk) 21:19, 21 May 2026 (UTC)

> I cannot go into specifics about individuals but can confirm all five engineers and a manager impacted by the change are encouraged to apply for existing and upcoming roles at the Foundation. This process can take time depending on where someone is located because of local regulations around jobs changing, but we are actively supporting impacted staff through this process and expediting interviews as much as possible. The open roles are all ones that will strongly benefit from experienced engineers with knowledge of our tools, some with more specific requirements than others.

If we try to simplify this from the corporate bullshit speak, this means ‘Yes, we have fired six employees as a result of this. They are no longer considered our employees but we are going to be interviewing them for other positions. There is no guarantee all of them will be kept at the WMF, even with all of their experience.’ Disgraceful decision, no matter what motivated it. stjn^[ru] 23:18, 21 May 2026 (UTC)

So far I dont understand if the staff was laid off or is still employed at the Wikimedia Foundation getting now time to find another role within the Wikimedia Foundation. Me too. We don't know for sure that they were laid off. SuperPianoMan9167 (talk) 12:32, 22 May 2026 (UTC)

Hogu: you are correct that things will need to play out over weeks. That's probably why they could not say "X people have found new teams, Y people will be losing their jobs" because this information wouldn't (and at least inside of the Foundation couldn't) stay private long enough for that to happen. Affected employees were told before it was publicly announced. They are being given time to find a new role in the Foundation, if they wish to. It is only at the end of that time - and there are different legal obligations for how long that time must be in different countries - or if they decide they do not want to find a new role in the Foundation, that they would be laid off and stop being employed by the Foundation. Best, Barkeep49 (talk) 14:53, 22 May 2026 (UTC)

So SCherukuwada (WMF) is saying that the sacking of incredibly dedicated and super-talented developers was nothing to do with a union—it's just a normal blunder by an out-of-touch bureaucracy fat on donations that depend on disposable volunteer editors. Johnuniq (talk) 23:33, 21 May 2026 (UTC)

There is a lot of smoke here. Even if there is no fire, making a move this toxic to key external stakeholders would not be tolerated at most organizations. If I woke up to my clients threatening to reduce product use and interfere with BD efforts because of a personnel decision I would escalate to my company's board. You guys are going to have to do something, and that something likely starts but should not stop with finding roles for the affected team. NicheSports (talk) 06:23, 22 May 2026 (UTC)

If Wikimedia as a whole is a body, then editors are literally the lifeblood that keep everything running - without editors, everything stops. Considering recent concerns from the WMF about editor retention and recruitment, this was never going to end well.

Someone would notice a move like this and, from what I can see, absolutely nobody believes the WMF's claims. They need to do better than this.

If WMF is the "brain", they've just chopped off one of their hands and are surprised by all this red watery stuff on the floor. Blue-Sonnet (talk) 08:56, 22 May 2026 (UTC)

Disagree. The whole point of a labor action is to be disruptive, to bring visibility to the struggle and situation, and demonstrate the source of what makes the organization valuable. We are Wikipedia, not WMF. Audiodude (talk) 13:03, 22 May 2026 (UTC)

I fully agree with you and @Blue-Sonnet and am sorry this was not clear from my comment. When I wrote it, I had already signed the collective action statement. NicheSports (talk) 15:04, 22 May 2026 (UTC)

It's fine, I felt it was clear & was agreeing with you too! I felt your comment was a good jumping-off point for my analogy. Blue-Sonnet (talk) 15:58, 22 May 2026 (UTC)

This is text book union busting coorporation talk. WMF is not Amazon (let us know if it has decided to become like it) and should not treat workers like this. You say there is no budget cuts but you fired people and you fired exactly the folks organizing the union, how do you explain that?

Rehire the workers and stop sabottaging the union!!!

Solidarity with the union! Irdiism (talk) 15:20, 22 May 2026 (UTC)

That's the spirit. But it should be clear that the WWU members have still not said much adu, but I'm sure they're very appreciative of us all. A shark agrees wholeheartedly: The idea that the workers who maintain the infrastructure for that mission should have no formal voice in how that infrastructure is run is not a minor inconsistency. It is a structural contradiction that has been waiting for exactly this moment. You found the moment. I'm glad you have. 2601AC47 (talk) 15:28, 22 May 2026 (UTC)

Update from Selena

Hi everyone, my name is Selena Deckelmann and I am the Chief Product and Technology Officer at the Wikimedia Foundation. I’ve been watching and reading this discussion closely this week.

First, I want to address what is happening with the staff affected by this change - as Suman mentioned, we are actively interviewing staff who have expressed interest in other open roles, and they are going through an expedited internal process. This is not a change; it’s something we started right away when each staff person was told individually that the team was being disbanded. This process (which is sometimes referred to as “redeployment”, and is legally required in some countries when roles are possibly made redundant) takes time because of different regulations, but we're trying to get those processes completed within the next week or so.

Second, it is clear (as it has always been) that the community cares deeply about the wishlist, and sees it as a primary vehicle (some see it as the vehicle) for having editor needs listened to and addressed by the Foundation. Volunteers have also historically looked to the staff size of that team as an indicator of how much it is a Foundation priority; while I don’t agree with this point of view, those who have noted here and elsewhere that at various points in the past other Foundation teams have not balanced wish work with their “regular” work are not wrong.

Regardless of what you think of the proposed version of the wishlist or the decision to disband CommTech, I think all of us agree on one thing: the wishlist hasn’t been working well. I would really like it to, and I’d like to do it with editors. I understand and hear that many of you have felt closed off from the decision making about how the wishlist works for the past several years. It’s time to change that.

I don’t have any big proposals today, but an intention. I’d like to hear from you - here is fine, individual conversations with me or my staff also work, about how we might build a new wishlist that works for both editors and the Foundation. Staff are going to pause on responding for the next few days (and for many, Monday is a WMF holiday) but I’ll check in again early next week. Thank you all for caring about this so deeply. SDeckelmann-WMF (talk) 16:07, 22 May 2026 (UTC)

Here they come. Prepare yourself. Also take a look at my statement. 2601AC47 (talk) 16:15, 22 May 2026 (UTC)

It's now Friday evening. Things have calmed, but the tension is very appetiting - and they're still in a solidiery mood. So far, we've heard from 3 people from WMF management: Mrs. Deckelmann (the CPTO), Mrs. Cherukuwada (the Deputy CPTO), and Mr. LaPorte (the Legal General Counsel). As of this moment, the next few people (besides Jimbo) we would like to see are: Chief Communications Officer Alikhan, Director of Community Development Ramkisson, CFO Villagomez, and perhaps Jan Eissfeldt of T&S. Yes, them, too, because we can never be too certain that they don't have a hand in some part of this. Then we head to CEO Meehan's office user talk. 2601AC47 (talk) 23:20, 22 May 2026 (UTC)

I think it's high time that the WMF prioritize community needs even when it requires restructuring how we do the work. We all know the old way wasn't working; I support the change. The hand wringing over this which is coming from the assumption that this means a turn away from community needs is mistaken at best. Jimbo Wales (talk) 05:34, 23 May 2026 (UTC)

@Jimbo Wales: By "the change" do you mean just the decision to not have a dedicated Community Tech team, or also the decision to lay off the five engineers on that team, even though the logic of disbanding the team would suggest that their efforts are still needed elsewhere, at a time when most of the team's members were engaged in pushing for better working conditions at the Foundation? Do you have any response to the characterization from many current and former staff of the Foundation as a place where expressing dissent from management's views is often met with censorship or termination? -- Tamzin^{[​cetacean needed]} (they|xe|🤷) 07:56, 23 May 2026 (UTC)

But I would really like to hear from Sammy the Fox. The fox has seen everything from within the infrastructure, and he's not the only one that's a friend to Jeff the Land Shark - the other fox has nine tails and leads a top-secret intel agency division in the Marvel Universe. Ami Han would have questions, too... 2601AC47 (talk) 23:30, 22 May 2026 (UTC)

One important question: are the staff affected by this change guaranteed a new role at the Foundation? Will all of them continue to work at the Foundation in some capacity? SuperPianoMan9167 (talk) 16:29, 22 May 2026 (UTC)

Thanks for the comment. But I think people are also worried about something bigger than the Wishlist itself: WMF's relationship with its own staff and with community feedback. I've spoken with multiple former staff members who described a culture where criticism of leadership decisions was not welcomed, and where community-requested priorities were often ignored in favor of top-down plans that felt disconnected from what editors were actually asking for. Some also described fear of speaking openly about these issues. Could you please respond to these concerns directly?

I also think you should understand why many community members are struggling to trust WMF leadership statements right now. Over the years, we've repeatedly seen core community-facing initiatives weakened, restructured, deprioritized, or left without dedicated maintainers (I can show a lot of examples), while being told the new model would work better. So when people hear "trust us, this will improve things", skepticism is a completely natural reaction from a community that has seen this pattern before. Nemoralis (talk) 16:31, 22 May 2026 (UTC)

build a new wishlist. I would recommend just reverting to what worked two years ago. A CommTech team, a yearly cadence, and organized primarily by individual rankings instead of focus groups. I think thinking that it needs to change and then spending a bunch of time architecting those changes would be a mistake, when we already have a good blueprint. Would suggest keeping mw:Extension:CommunityRequests, and sure some other WMF teams can pitch in, but discard all other changes. –Novem Linguae (talk) 16:48, 22 May 2026 (UTC)

I don’t think the previous way of wishlisting ‘worked’ but it was infinitely better than the new opaque process that was developed without any consultation with the community. The fundamentals of why it was developed are reasonable (CommTech was never able to deliver at the scale they were expected by the community), the decisions that were made are not. stjn^[ru] 20:01, 22 May 2026 (UTC)

Thanks for the perspective on the yearly cadence and the extension, and consideration for time spent re-architecting. SDeckelmann-WMF (talk) 21:38, 22 May 2026 (UTC)

The main question the community has had so far is why you laid off six people who seem to have been good at their jobs and were doing important work. You've written five paragraphs here and you still haven't explained that. You, like Suman, are trying to reassure us that these people may still be given new jobs, but this is a situation entirely of your own making. These engineers could have ben transferred to other teams, like the teams that you claim will take responsibility for Wishlist features. Even if some bureaucratic or legal quirk required you to technically lay them off for some reason, that would not take the form of an unexpected round of layoffs and an offer of interviews with no promise of rehiring.

There are two ways to read this situation, from where I stand. One is that you disliked that some or all of these people were trying to unionize. The other is, per what Nemoralis is saying, that the WMF has an institutional hostility toward dissenters, freethinkers, and valuable members of the community, which naturally guides it in the direction of terminating people who just happen to be involved in the union. I honestly think the latter would be more damning. The former would "just" be petty corporate bullshit; the latter suggests a fundamental inability to run an organization in the interest of its volunteers and donors. Because time and time again, the WMF is firing the people who try to make it better.

If you want to convince the community that you're not full of shit, the fix is easy. I mean, probably not easy administratively on your end, but easy conceptually: "We should have reassigned those people instead of laying them off. They've all been given new job offers, with apologies. We'll make sure we communicate better with team members in the future when reorganizing teams." Offering anything less than that is an insult to our collective intelligence, and an added insult upon the injury you've already done to the people you laid off to cover for your own incompetence. Do the right thing, or quit pretending you care. -- Tamzin^{[​cetacean needed]} (they|xe|🤷) 16:52, 22 May 2026 (UTC)

+1. If employees were laid off for budget or performance reasons, then own up to that. If they weren't supposed to be laid off, don't lay them off. Dissembling wins no confidence. Vanamonde93 (talk) 18:49, 22 May 2026 (UTC)

WMF has an institutional hostility toward dissenters This part, at least, is true. If you speak out in a way that somehow annoys or reflects poorly on someone high up the management ladder, there's a good chance you'll face retaliation. Anomie (talk) 01:13, 23 May 2026 (UTC)

To add to what Tamzin said, the unclear situation that employees are now facing is exactly why a union is needed, which is in fact mirrored in Wiki Workers United's goals: Preventing unclear or inconsistent hiring, firing, and promotion practices. The messaging hasn't made clear at all why this convoluted path, which puts strain on both employees and the Foundation as a whole, was preferred to a simpler internal reassignment to new positions. If you intend to reorganize CommTech into a program and integrate it into other teams to increase its efficiency, one would expect current employees to be welcome in these teams as part of the streamlined program, both to preserve know-how and to prevent an even worse bottleneck on community input. This has not been the case, and we find explanations lacking beyond a broad desire to reform the wishlist, which tells us nothing about the specific, destructive path that was taken.

I understand that neither can the WMF reveal every single internal discussion, nor would that be needed, but improving transparency and accountability from WMF leadership toward both staff and movement communities (another of the union's focus areas!) remains a baseline expectation to understand the factors that lead to these decisions being taken. Without strong reassurances, the natural conclusion that community members are going to reach is that the hostility to dissent many of us worry about is still deeply entrenched, and that guaranteeing the ability to safely express dissent among employees remains a priority in movement relations. Chaotic Enby (talk) 17:08, 22 May 2026 (UTC)

Thank you for the message, it reads very genuine, but this is bigger than the Wishlist and CommTech. That we need to have the Wishlist as an addendum is indicative of a poorly-designed system. The long-term flurry of scandals that torch community-WMF relations are all rooted in a broken and dysfunctional governance system that is antithetical to the Wikimedia movement's ideals and purpose, and results in satisficing communities (or rather attempts to) and mistreating staff while feeding a self-interested bureaucracy. If nothing is done to fix that, we’ll be having this conversation again at next month's scandal, and the month after that. There needs to be dialogue with communities about a new system, and no more bullshit (please). Kowal2701 (talk) 17:14, 22 May 2026 (UTC)

To clarify, staff are part of the movement too, idk about others but when I say community I include staff who adhere to the movement's ideals and prioritise the encyclopedia and other projects above all else Kowal2701 (talk) 17:50, 22 May 2026 (UTC)

...And what they mean is: "we appreciate that you came, but the door is still bricked up. And we've watched doors get un-bricked on paper before."

That's as kind a response as you'll get, Selena. Take them into consideration, while they're still willing. 2601AC47 (talk) 17:52, 22 May 2026 (UTC)

Support Tamzin and Chaotic Enby above. looking forward to a future with a recognized union. Solidarity Forever. Jeremyb (talk) 17:29, 22 May 2026 (UTC)

Selena, thank you for listening. I sincerely hope that all of the affected employees will be able to report next week that they have been hired into new roles. But I can't fail to notice that you said staff who have expressed interest in other open roles, not simply the affected staff. Are there enough open roles to take these people? Are those roles a good fit for those people? One would hope that the answer to these questions is "yes", but your wording strongly suggests "no". I second my colleagues, above, who point out that this is clear evidence of why a union is necessary for WMF employees. I understand that restructuring is sometimes necessary and sometimes painful, and that, often, leadership roles involve being forced to pick a bad option out of a long list of bad options. But if this is necessary, well: why? Because the wishlist wasn't working? It's true, we all agree it wasn't. But this will help how, exactly? The damage to community and employee goodwill was worth it for what reason? Why on earth is there a plan to fire employees but no plan to support the work they were doing?

I'm also sure that we can all agree this was a major failure of communication. If that were all it was, I would sigh, shrug, and go rant at some WMF communications people about how they're undervalued and leadership needs to listen to them better. But that WMF leadership was apparently totally unprepared for this to be a major issue for the community speaks to a completely different problem. That's probably the same problem at the heart of why the wishlist didn't work: the WMF as a whole has no idea what the community wants and is insufficiently interested in this problem to fix it. I believe that the WMF should have goals that are not the same goals as any individual editing community; the WMF is bigger and broader than any individual part of the whole. But the obvious conclusion editors are coming to here is that the WMF's goals come at the expense of editorial goals, or even directly conflict with them. This is an enormous problem. I hope that you spend time over the next few days trying to figure out why you were not expecting the community to react with horror and outrage to the closing of the wishlist and the firing of commtech. Whose voices were you ignoring earlier? Or, who did you not even think to ask? Again, thank you for taking the time to listen and make this statement. -- asilvering (talk) 18:14, 22 May 2026 (UTC)

I want to amplify asilvering's point here, that WMF leadership was apparently totally unprepared for this to be a major issue for the community speaks to a completely different problem. We value this team, and these employees, not (just) for coding skills but for the rare and important expertise of understanding the community from the inside. If they were all reassigned, you possibly could have gotten away with dissolving the wishlist by saying "now every team will have someone who understands and prioritizes the community!" Certainly, every last one of them could have given you a useful answer if you had asked, "Hey, do you think editors will mind if we dissolve the Wishlist and lay off the Community Tech team?"

It worries me that the WMF evidently employs many people who cannot answer that question. I'm aware that many WMF employees are also volunteers, but I am concerned that their effort and expertise as volunteers is not appropriately valued. The WMF would not need to spend so much time wondering what the community wants if they appropriately valued this expertise. LEvalyn (talk) 19:32, 22 May 2026 (UTC)

I disagree calling this a failure in communication because evidently, firing the people who are organising a union is not something that happens randomly. This is union busting and WMF should not be given a free pass to treat workers like Amazon does. WMF was hoping we do not notice this? Tell us, will every worker who was fired get a new position? Irdiism (talk) 18:43, 22 May 2026 (UTC)

Well, there is the matter of epistemological failure to the WMF's comms. That's what asilvering's describing, in summary. It hasn't been noted yet by the rest. And there's a distinctive difference between that and a endemoepidemic failure in comms - as in "getting perilously close to heightened occurrence of anything harmful". 2601AC47 (talk) 18:49, 22 May 2026 (UTC)

Cross-posting here from Village Pump:

"Open roles" have been brought up several times -- albeit via the statement we are actively interviewing staff who have expressed interest in other open roles, which contains the giant loophole of "well, they clearly aren't interested, so...." (This loophole was also noted here.)

Anyway, these are the current open product/engineering roles, at least the public ones. Of note: There are fewer than six of them (although again, these are only the currently open postings). One of them is a SRE role, which is more specialized. There don't seem to be any engineering openings at the staff or managerial level. And at the risk of being a huge cliche, I will point out that one of these roles asks for "experience with leveraging agentic coding to scale the work of small engineering teams," which suggests another possible angle for these layoffs. Gnomingstuff (talk) 18:55, 22 May 2026 (UTC)

"Agentic coding..." - that refers to autonomous AI that plan, write, test, and debug code with minimal human intervention, which means... Jeff's eyes open very slowly beneath the surface. "Oh. Oh no." 2601AC47 (talk) 19:02, 22 May 2026 (UTC)

It also states: Experience with data science, machine learning, and/or AI (e.g., familiarity with prompt engineering, Jupyter notebooks experience, etc.) 2601AC47 (talk) 19:04, 22 May 2026 (UTC)

to be fair, this one feels more standard for machine learning-oriented roles, which is why I didn't mention it Gnomingstuff (talk) 19:07, 22 May 2026 (UTC)

And yet, at the same time, this part alone does indicate another thing: that the WMF hasn't exactly given up its pursuit of AI. Which we know how that went last time, but still... A sound from the pool that is not quite "Murr". It is lower than "Murr". It has more teeth in it, and it sounds disappointed. 2601AC47 (talk) 19:15, 22 May 2026 (UTC)

I can confidently state that the WMF does not (yet) have the AI mandate problem that much of Corporate America is having right now. There is no mass of AI-generated slop patches on Gerrit, there aren't AI code reviews, there is no AI mandate for devs, and there is no AI dashboard for management to make sure devs are using enough AI. While it is reasonable to suspect this of pretty much any organization right now, I'm confident it's not happening here (yet). Source: I do a lot of volunteer technical work, and I talk to Wikimedia devs. I mention this so that we don't go down an unnecessary rabbit hole. –Novem Linguae (talk) 19:48, 22 May 2026 (UTC)

Yes, this is correct. SDeckelmann-WMF (talk) 21:31, 22 May 2026 (UTC)

The link is broken. How about this other link instead? George Ho (talk) 19:54, 22 May 2026 (UTC)

Those engineers were the only part that made the wishlist work to any extent that it did. I can hardly imagine anywhere else one is able to find talent with such intimate institutional knowledge about both the MediaWiki ecosystem and the Wikimedia movement. That knowledge is far more valuable to both the foundation and community than any awesome wishlist would be. Nardog (talk) 00:46, 23 May 2026 (UTC)

Selena,

I agree that the wishlist hasn't been working well.

What you are not mentioning is that there is a specific and easy to identify person who is responsible for this.

It's the person who for more than three years appointed and removed several product managers and engineering managers for the wishlist.

It's the person who got those managers and the engineers and the designers that they lead to change the wish procedures and develop an extension for managing the vote.

It's the person whose photograph appears on the page that expresses pride for "revamping the Community Wishlist from a once-a-year survey into an always-open intake process".

That person is you.

The real reason that the wishlist is not working is not that it has the wrong engineers, the wrong managers, or the wrong intake process. The real reason is that you simply don't want to implement most of those wishes. You may say that you do. You may even sincerely believe that you do. But your actions speak much louder than your words or your beliefs, Selena.

I heard your speeches a few times. You sounded like a person who enjoys being a leader, but doesn't enjoy taking full responsibility for being one. The time has come to finally do it. ~2026-30858-37 (talk) 13:16, 23 May 2026 (UTC)

Hi Selena, thank you for your comment. Setting aside my issues with how this matter has been communicated, I am glad to know that you are interviewing the former members of the CommTech team for other roles, as I think their experience is invaluable and should be kept within the WMF if at all possible. I am usually just a lurker on meta, but I felt it was important to ask you this directly: are possible rehirings subject to the Foundation's current hiring locations, or are the former CommTech staff being treated as existing employees? Personally I am aware of at least one former CommTech employee who falls outside of the countries listed, and I am very concerned that valuable staff could be let go on a technicality. Thank you for your time, Ethmostigmus (talk) 02:37, 24 May 2026 (UTC)

@SDeckelmann-WMF: I think there are significant questions about staffing raised by other folks here that I would really urge you to address. I strongly believe that the engineers who worked at Comm Tech need to be assured of roles in other teams at the same level and in their areas of expertise, and a failure to do so is a significant problem. There should be no caveats, ifs, or buts there.

That aside, focusing specifically on the wishlist itself. I think that the task of designing the Community Wishlist can be divided into three parts: (1) fixing the community intake wrangling process, (2) fixing the team wish intake process, and (3) fixing the prioritization process. In this context, the "community intake process" is the process of the community submitting wishes (i.e. the user facing CommunityRequests extension), the "team wish intake process" is the process through which Mike (the product manager) reaches out to teams and gets them to work on wishes and the "prioritization process" is the process through which the teams decide whether or not they should work on it/how important the wish is. With that in mind, I want to start by evaluating the existing iterations.

Extended rant about the old Community Wishlist structures and why I think they worked/did not work
The reason the old version of the wishlist worked was that it was a yearly event, which was widely announced. There was an extremely loud promotion period during which the community voiced their needs, voted on what they wanted most, and Community Tech worked on the "community prioritized" wishes. In this case, the community intake process worked reasonably well; lots of people showed up, cast their wishes into the "basket". The team intake process/problem did not exist, and the prioritization process, while it had its own glaring flaws, for the most part, the Community Tech team worked on what was voted on the most, and there was enough data for volunteers like me or Novem to pick on parts of the rest during Hackathons. The current process is a shadow of its former self. There is no real community engagement/intake process, almost nobody votes on wishes, and the only reason there are > 500 wishes and significantly high wish counts is cause community members who are very deeply invested in the process file wishes on behalf of other folks and then sometimes vote on other wishes. As a result, the prioritization process is broken since almost all wishes are relegated into the bottom right of the prioritization table since most wishes are made by community members who are not aware of our OKR prioritization metrics and typically are not fully of "Unbreak Now!" importance (we have a good enough triage process for those through existing technical community members who can raise tickets on phabricator). This also affect the team wish intake process, since due to the lack of engagement from the community, most teams (besides the Community Tech team) perform the calculus of "does this wish significantly change OKR metrics, if not, we will not work on them", and there is no effective way for community members to appeal this descision (not to mention that I strongly believe that as a community member you should not need to know the org structure of WMF and the exact word salad to say to get a wish prioritized by a specific team). The only reason the current Wishlist structure even worked at all was because of CommTech, a team whose mandate was to work on community wishes. As a result, they did not have to worry about pushing specific OKR metrics, and thus had no "team intake process," and there were enough engineers with community experience that they prioritized the work from the "basket" correctly. (read: y'all got incredibly lucky thanks to the existing engineers that you had hired to be part of CommTech) The process y'all (Suman) have proposed is the worst of both worlds; it does nothing to fix the root of the community intake problem, but removes the one part that actually worked, CommTech. Not only that, it exacerbates the team intake process problems, since now to get any work done, you need to literally know the org structure by heart and make every wish into a pitch to a product manager about why their team should steal their focus from their existing significant workload to work on my wish.

Coming to what an ideal redesigned wishlist would look like, I do understand that you want significantly more than a single team working on all the wishes. Keeping that in mind, I want to propose the following rough structure:

• The first and biggest thing to do is to establish a robust community wish intake process. As Novem mentioned above, the old community wishlist structure did a fairly good job. In my mind, you could keep wish intake open year-round, but with a sharp uptick in the period right before voting. This could be paired with a yearly (or maybe biennial) voting schedule where folks can vote on items they want.
• The second biggest thing is that the prioritization process needs to be majority community-owned. Some of that can and will be provided by the votes themselves, while the rest of the stakeholders, such as engineering input, can be handled by engineers with significant community experience, such as those who were on the Community Tech team, volunteer developers, or similar. Product managers can also be part of this prioritization exercise. This can take the form of a team, a council, or some other structure, but the operative part here is that it needs to involve existing community members.
• I also want to propose abolishing the whole team intake wrangling process, with each team having a certain quota of X wishes that must be directly correlated/taken from wishes on the already prioritized Community Wishlist (similar to Essential Work quotas?) that is outside of their normal push to meet their OKRs. The tasks must be taken up from the already prioritized version of the Community Wishlist and not be worked on and then coincidentally correlated with wishes, with the feedback process directly involving the community members who have proposed/shown interest in the wish in all the steps of the process, regardless of the team's designation (i.e., Readers or Enterprise).

I know this sounds a lot like the plan you already have, but I think the key point to note is that without a proper prioritization structure and a proper community intake process, this will devolve into something similar to what we already have, i.e., a cacophony of telephone games.

All that being said, even with an ideal Community Wishlist, I do still believe that there is a place for a Community Tech team (as an abstract concept) at the Wikimedia Foundation. Even in an ideal world where the Charts and UploadWizard extension (to give two examples) are owned by a team that actively works on them, and so is every other core component, there are a lot of tools and associated infrastructure that do not have a well-defined owner. This would include, for example, Wikimedia OCR, XTools, CopyPatrol, Who Wrote That, and even tools like Cat-a-lot, CropTool, Twinkle, or Popups. It would be really nice to have a team that could work on maintaining, helping critical volunteer infrastructure, and potentially find ways to upstream it into the core or otherwise maintain it for longer periods of time. This, alongside acting as the "community-owned prioritization process" for the wishlist, was what old CommTech excelled at and is the reason why you saw the response you saw over the last 48 hours (in my opinion). The old CommTech worked because it was more than just the wishlist itself; they went out of their way to fix "technical community issues" as an abstract concept.

To sorta summarize, my asks are the following: a) Ensure that the existing Community Tech team members are able to find a place within the existing organization structure b) If you are gonna redesign the Wishlist, fix the community intake and prioritization process ensuring significant community representation in the latter c) eliminate team intake wrangling process altogether and d) consider reconstituting a Community Tech team (maybe with the same engineers on the team that got disbanded) with the sole focus of maintaining critical community infrastructure. -- Sohom (talk) 20:37, 22 May 2026 (UTC)

Thank you so much -- you've given us a lot to think about and I'm genuinely open to considering all of these changes SDeckelmann-WMF (talk) 21:27, 22 May 2026 (UTC)

Seconding that it is shocking that so many tools that are critical to certain editorial workflows have no clear owners. asilvering (talk) 23:08, 22 May 2026 (UTC)

Yeah, can only +1 for the most part to what Sohom said. I also have to note that the only experience I’ve had submitting wishes through the new system was met first with ‘why is this needed at all’, then with ‘the team that owns this has said that this is not a high priority and it would be too complex for them to do, so you can get lost’ (my personal characterisation of what was happening at Talk:Community Wishlist/W356). I get that not all of the things are easy to do, but it was discouraging to submit something and then be asked again and again to ‘clarify the need’ by people that haven’t tried to understand it. Which was never present in the previous process to the same degree: you asked for things, people commented in the same way but eventually you either got supported by others or you didn’t. stjn^[ru] 09:55, 23 May 2026 (UTC)

I cannot say it better than what Sohom has said. The CommTech members have done excellent work for the movement, and should continue to do so in whatever roles they may find within the Foundation after this. I sincerely hope that other teams can be encouraged to take them in within the constraints that they may have (or if possible, give the teams the allowance to do so) if (d) isn't taken up. Robertsky (talk) 12:55, 23 May 2026 (UTC)

I read from Selena that those who have noted here and elsewhere that at various points in the past other Foundation teams have not balanced wish work with their “regular” work are not wrong and from a long-time community member and former WMF staff that If you speak out in a way that somehow annoys or reflects poorly on someone high up the management ladder, there's a good chance you'll face retaliation and I can't help but think the two things are connected. One reason people care about individual WMF staffers is the perception that good work at the Wikimedia Foundation happens thanks to caring and knowledgeable individuals and despite the management and official structures. If you remove several individuals knowledgeable in community needs and then maybe keep some of them elsewhere, it's not far fetched to conclude that you'll have less resources for community needs. Nemo 07:44, 24 May 2026 (UTC)

There should be a yearly cadence and the wikis put into two voting groups, based on traffic. Each member in group1 has 700million to several USA billion (european billions are different btw.) monthly views across all languages. Each member in group2 has 20-95 thousand monthly views across all languages. There was an specific non-wikipedia wishlist one year, which allowed the sister projects to get accepted wishes.

• Group1: Wikipedia, Wikidata, Commons
• Group2: All other sister projects

For the users that only stay on Wikipedia, let me say this. Wikisource has been used as a source for Wikipedia in Grants:Project/Harej/Librarybase:_an_online_reference_library and Grants:IEG/Growing_Kannada-language_Wikimedia_projects_with_a_digital_library. Wikisource uses the Wikisource extension, which is largely about en:Optical Character Recognition, which is very important in Wikisources workflow. Wikibooks likes to use quizzes, which I have not seen much of elsewhere. Wishes from Wikipedia are not necessarily useful on Wikisource or Wikibooks.

Group1 gets 75% of the wishes and group2 gets 25%. If a wish from group2 is more popular than a wish that would have been picked in group1, then the group2 wish is picked instead. Example: The total amount of wishes is 5. Group1 gets 4 and Group2 gets 1 accepted wish by default. In the top spots in group1 are wish1 120 votes, wish2 110 votes, wish3 90 votes, wish4 70 votes. In the top spots in group2 are wish1 100 votes, wish2 80 votes, wish3 50 votes. Since wish1 and wish2 from group2 are higher than wish3 with 90 votes and wish4 with 70 votes in group1, the wishes from group2 are picked instead.--Snævar (talk) 09:15, 24 May 2026 (UTC)

Tools left behind

I think no one is speaking more deliberately to the fact that it is not just some employees that the community liked and the WMF (allegedly) didn’t that we’re talking about here. As was mentioned by someone on the Discord server, this was also about, as far as we know, violating WMF’s own guidelines on re-orgs which state: Any service the team won’t continue to own (because it no longer makes sense in their portfolio, or even because the team is being disbanded completely) must be transferred to another team as a part of the reorg process, and this needs to be taken into account when planning the reorg—both the need to identify a new owner, and the need for time to execute a successful handoff.

If we go by mw:Developers/Maintainers and Community Tech/Maintenance, that means that, despite what’s quoted above, the following things no longer had maintainers after this re-org:

1. entire preferences system, including global preferences;
2. watchlist expiry;
3. watchlist labels (a feature that was currently in active development!);
4. article wizard workflow;
5. syntax highlighting for wikitext editors aka CodeMirror (also something in active development; for the record, MusikAnimal said they were going to continue maintaining it as a volunteer);
6. page assessments API;
7. template wizard for 2010 wikitext editor;
8. Wikisource extension;
9. edit recovery feature;
10. realtime preview for 2010 wikitext editor;
11. various tools and gadgets: AutosuggestSitelink, Copypatrol, Pageviews, SVG Translate, Who Wrote That?, WikiWho, XTools.
12. User:Community Tech bot doing various tasks (updating popular pages, notifying about Commons file deletions).

Compiling this list, it is hard to understand who was exactly helped by this re-org, and it is very easy to understand the people who end up thinking that this was done out of malice. While internally there might’ve been some updates in regards to who’s maintaining some of these tools above (not reflected on maintainers page yet), it is hard not to jump to conspiracy theories when, from the outside, the situation is that the entire team of experienced developers and maintainers was disbanded for at best procedural reasons all the while they were actively working on developing new features! And the original update about it talked about the team like they were some dictators putting the whole dev cycle into a stranglehold by forcing everyone else to co-operate with them, which, if anything, would’ve been a requirement you put yourselves there! Not something unchangeable about the whole process. The more you think about the situation, the more maddening it feels.

Who’s going to continue development of watchlist labels? Are you going to bring in new developers or is that feature canned entirely? And what kind of mess have we found ourselves in where a group of employees is being asked to develop something for months and then they get fired (‘redeployed’) en masse while they are developing it? Do WMF higher-ups really don’t see how badly this all looks, and how badly it reflects on them to continue to talk in what essentially are corporate platitudes while the community notices these obvious issues? stjn^[ru] 18:16, 24 May 2026 (UTC)

The above section reminded me of my own personal story of a tool failing to be maintained for years when a WMF employee left and it turning into a mess: the translation of Wikimedia Phabricator on translatewiki.net. This was set up in 2018 per phab:T225, and from 2018 to 2020 was run solely by Mukunda Modell. When Mukunda left in 2020 (I neither know nor care whether they were laid off or chose to quit) nobody took up the task of running it. This meant that from 2020 until 2024, while people could still submit those translations on translatewiki.net nobody ever deployed those changes to the server so they were wasted, and aside from a few old tasks languishing in the backlog requesting a new language be added to the interface nobody even knew that this was the case. I discovered the broken process and took over it myself in 2023, and the first new translations were deployed in April 2024, so crisis averted for now, but the threat is very telling - one person leaving created a situation where something was broken, and the only trace something was broken was a few unheard cries ...

Now imagine that sevenfold! * Pppery * _{in solidarity} 03:11, 25 May 2026 (UTC)

mw:Extension:CommunityRequests (the wishlist software) as well. –Novem Linguae (talk) 19:14, 30 May 2026 (UTC)

Response from WMF 24 May

(cross-posted to en.wiki village pump)

Hi everyone,

I have been following the conversation closely.

First, I want to apologize for the confusion caused by our initial posts on this topic. We could have been more clear and invited in more input from the beginning on how we can make the process of taking in wishes and responding to community needs better together.

Many of you have asked questions about the staff who were affected by these changes. Our priority in each individual staff conversation was to ensure they are aware of what options exist internally (including the severance they would receive if they chose not to apply), the process to apply for new roles (which has been expedited as much as is fair and permissible given they are known internal candidates), and where needed, specific introductions and/or connections to hiring managers to ensure questions about the work and roles are addressed.

I know many of you asked why we cannot just guarantee people new roles. As part of the planning related to disbanding the Community Tech team, we reviewed the rules in each affected staff member's country to determine our obligations in these situations. We also looked at how the laws differed country to country -- in this restructuring, we have 4 countries represented, with a wide variance in required actions. I want to note one specific requirement that came from these laws: we could not pre-select certain staff for new roles, as that would appear to be circumventing legally required processes in some countries. We made the decision as part of this restructuring to extend the option for a "consultation and redeployment process" to all impacted staff, even those who live in countries where this is not required. This process, required in some countries, is a period of time where staff whose roles are up for elimination have the opportunity to look for other positions internally (while remaining active as staff) that match their skill sets. We thought this was the most equitable approach given that this is a team of staff with years of valuable community expertise and developer expertise and these are skills that we need to be able to move quickly and respond to the global trends we're already seeing shape the internet and broader ecosystem we operate in.

I can confirm that we have a number of interviews ongoing, and we are expecting several processes to wrap up by early next week. If and when staff have been selected for these open roles, staff will be encouraged to update the relevant team page to show their new roles. We are going to respect each staff member's decision on how and when to communicate these changes, and ask you to do the same.

Regarding the future of the wishlist, I have received a lot of feedback from you in this discussion and directly, and am listening. In terms of changes, I am genuinely open to bringing back individual wish voting. Some version of this has existed since October, though as several of you have noted, it lacks the level of engagement that we had with the annual process, and I’m willing to discuss ways to make that better, including an annual or some other recurring cadence of a community wishlist survey. The wishlist will continue to have a technical program manager assigned to ensure that incoming wishes are delegated to the right team and a triage process for ensuring review of wishes by those teams.

I think the best way forward is to partner directly with editors in designing what this looks like in further detail, as well as considering other angles, like increasing participation in the wishlist across volunteer communities. One way to do this would be for my team and I to work directly with PTAC to come up with a proposal, and share it here for your consideration within three months. Is this something worth moving forward with? I am open to other ideas on how best to collect specific suggestions - hosting an open call, a Discord chat, etc. SDeckelmann-WMF (talk) 22:28, 24 May 2026 (UTC)

Hi @SDeckelmann-WMF, thank you for following up. Are you in a position to respond in general to Ethmostigmus's question about whether the new policy on hiring locations applies to staff being considered for redeployment? —In solidarity with Wiki Workers United · ClaudineChionh (she/her · email · w:en) 22:45, 24 May 2026 (UTC)

As a point of clarification: could not pre-select certain staff for new roles could be read in a few different ways. Does it mean that you could not transfer some staff while laying off others, that you had to give staff a choice of where to move (if they wished to at all), or that you were required to advertise positions externally as well and put existing staff through a similar interview process? AntiCompositeNumber (they/them) (talk) 22:47, 24 May 2026 (UTC)

I was also confused by that part. I struggle to believe that any of the involved countries has regulations forcing (or even encouraging) you to fire people, rather than e.g. transfer them to another team with their current title and job description. Nemo 05:01, 25 May 2026 (UTC)

@SDeckelmann-WMF: I am assuming good faith. However, when you stated We also looked at how the laws differed country to country -- in this restructuring, we have 4 countries represented, with a wide variance in required actions. I want to note one specific requirement that came from these laws: we could not pre-select certain staff for new roles, as that would appear to be circumventing legally required processes in some countries, you appear to be referring to an aspect w:labour law that appears to be absent from w:Wikipedia. Which of the existing ILO conventions covers examples of the national laws you are referring to? If you are referring to a topic absent from Wikipedia, then please tell us the specific name of this type of law, so that we can find w:WP:RS and create a Wikipedia article about this topic, e.g. w:role-change labour law; I found a few arbitrary US and UK sources, which may or may not be w:WP:RS. You won't convince anyone that those laws exist if there are no WP:RS that mention those types of laws at all. It's fine to protect the individuals' privacy to avoid revealing their particular geographical locations, but unless these are really exceptional countries, this aspect of labour law is likely to exist in many countries, not just those four. The closest article or template I could find is the Roles row in the w:Template:Employment navigation bar. You cannot just claim that an aspect of law exists but it is so secret that there are no w:WP:RS that cover it for any country. Boud (talk) 23:58, 25 May 2026 (UTC)

I’ll keep it short so maybe you or Suman will finally answer this: what exactly made the ‘restructuring’ a better option in comparison to just shifting the responsibilities of wishlisting to be more decentralised while keeping the team intact? Suman wrote originally that having a centralized team was leading to frequent bottlenecks and delays as CommTech staff coordinated with other teams but this does not sound at all like a problem of having a dedicated team, it sounds like a problem the management created. stjn^[ru] 23:41, 24 May 2026 (UTC)

One way to do this would be for my team and I to work directly with PTAC to come up with a proposal, and share it here for your consideration within three months. Please forgive my scepticism, but: PTAC was available to you for consultation this entire time, and yet the decisions were made as they were. How can we trust that another three months with PTAC would reach a better outcome than the one we presently have? -- asilvering (talk) 23:54, 24 May 2026 (UTC)

I'll repost what I said on enwiki for those who are only seeing what's said on Meta:

Looks like we're now on the They say they are listening and request questions and feedback from the community, to which they have no intention of responding. They sometimes go as far as to issue a non-apology without accountability or any specific commitments. They claim to want to be more responsive and transparent, but it's just part of the charade. This is their strategy of crisis management: waiting it out, saying as little as possible, making empty promises, taking no direct action, and sequestering the last hardliners in some farce of a listening committee, where their complaints can be ignored more directly part of the pattern.

This response does not resolve the crux of the issues at hand. I think we as a community deserve much better than that. If you want to actually fix this instead of waiting for what will probably be hundreds of editors going on strike, I have this advice. Clovermoss (talk) 23:55, 24 May 2026 (UTC)

I appreciate this response, especially the willingness to return to periodic voting on the Wishlist. However, a vague promise of a proposal in three months is ridiculous. There was a working Community Wishlist Survey for eight years, until the Foundation unilaterally scrapped the Survey and all related advertising, which destroyed community engagement. The solution is very simple and shouldn't take three months of discussions to figure out: Bring back periodic voting, or at the very least a periodic advertising campaign asking folks to contribute wishes and vote. Toadspike [Talk] 09:24, 25 May 2026 (UTC)

Thanks for your statement! All of this is an issue of trust in my opinion. WMF Community Tech is highly trusted by the community – because of their track record, implementing features the community deeply cares about while involving the community in a better way than most other WMF product teams do. Of course they are also trusted because many team members are well known community members themselves. There are a few other WMF product teams with a similar level of trust (e.g. Moderator Tools; stewards also recently highlighted their good relationship with Product Safety and Integrity). These teams typically do a good job communicating with the community and responding to community feedback.

Disbanding a team which is highly important to the community and asking the community to trust that a "program that multiple teams are officially responsible for supporting" will sufficiently take care of our needs was almost guaranteed to lead to backlash – how could the community trust these changes if you don't even mention which teams specifically are committed to work on our wishes in the future? Yes the old process had their flaws, but given how often WMF priorities misalign with community needs (e.g. the decisions in recent years to stop working on the charts extension and to stop supporting Commons) most community members apparently prefer to stick with the current process and CommTech rather than trusting other (yet-to-be-named) WMF teams. Trusting the new "multi-team program" would be much easier by the way if it came with a commitment like "each team will work on x wishes per year on average".

The trust issues also extend to allegations like union busting or the belief that the employees were laid off already (thanks for clarifying what's actually happening). I believe that you were honestly trying to improve a broken process but it was communicated poorly. There are lot's of amazing staff members working in Movement Communications – surely they could have warned Suman if he had consulted them on how to communicate this. Unfortunately there's a reoccurring pattern of WMF management completely misjudging how the community might react to certain announcements. --Johannnes89 (talk) 11:13, 25 May 2026 (UTC)

Broadly agree, but I don't think her statement says that these employees have not been laid off already. If that had happened, we might've been able to prevent that happening in the first place, and she makes it pretty clear that people getting their jobs back is an if. Clovermoss (talk) 11:22, 25 May 2026 (UTC)

if he had consulted them on how to communicate this. A small note. How it was communicated is probably not the crux of the issue. Communicating the same message to us but with more skill would probably not have solved the issue. It was what was communicated (the decision itself). The idea was in my opinion not properly socialized, but instead very sudden. –Novem Linguae (talk) 11:49, 27 May 2026 (UTC)

There are multiple issues with the decision to disband CommTech: Some are about the way WMF treats their employees, the allegations of union busting etc., but there's also the community concern that the re-structuring will make it harder to get community wishes implemented – that's a concern that could have been mitigated with better communication (e.g. explaining in detail how this multi-team program will look like, how they want to ensure that the re-structuring doesn't lead to a declining number of wishes implemented (or product managers only picking wishes which are less relevant to the community), how they are planning to involve the community given that other WMF teams are working differently than CommTech...). Johannnes89 (talk) 14:25, 28 May 2026 (UTC)

I am sorry to say that, at least with the current information, I am finding it at least a little difficult to believe that the affected employees could not just have been (e.g.) reassigned to other roles, rather than being laid-off and invited to re-apply for other roles.

This is not the first time that a WMF team has been disbanded -- two other recent examples that have come to mind so far (from within the last ~year) are the Structured Data team & the Design System Team. I suppose I don't currently know for certain that the employees in those former teams weren't also made to re-apply for a new job if they wanted to stay at the WMF; but, if that is the case, I suppose it (among other things) just seems like a ....cruel.... thing to put staff through whenever WMF senior management makes the decision that its engineering workforce should be made up of a different set of teams.

Going back to CommTech in particular (given that that's what's being discussed right now) -- in addition to lots of things that other folks have already written in the sections above, it feels like this decision to lay-off these engineers will likely make the already-bad problem of unstewarded code even worse.

There is a whole bunch of code that is deployed within Wikimedia production that is unstewarded as things currently stand (Ctrl+F on mw:Maintainers for unassigned gives me 142 results; Ctrl+F for active volunteer gives me a further 8). That is, with the current number of engineers that're employed by the WMF, there is a very large number of software components that have no WMF (or equivalent) team looking after them.

And so, especially with the ongoing WMF work regarding code-stewardship, I suppose I'm thinking something along the lines of: (directed towards WMF/WMF management) you already have a whole bunch of code that doesn't have anyone stewarding it, with all the risks that that entails -- isn't laying-off engineers going to make that problem worse?

(It feels like asking the WMF to 'hire more engineers' might be a bit of a cliché at this point, but it really does feel to me like the WMF needs more engineers, not less.)

This is all without also mentioning the vast quantities of invaluable institutional knowledge that the folks that've been laid-off will undoubtedly hold; relating to (among other things!) the operation of the Community Wishlist, & the pieces of software that CommTech has developed. (Surely laying-off the folks that hold this institutional knowledge is another risk unto itself?)

This really does feel like the wrong direction to me, for these reasons among others; and I am sorry to say that - as time is going on, and as additional statements are being posted - I am losing more and more hope in the WMF regarding this situation (and, by extension, in the WMF in general). Best, ‍—‍a smart kitten_[meow] 11:35, 25 May 2026 (UTC)

...and the longer this goes on for, the more hope is drained.

The best time to reverse-course on this was to have not done it in the first place. The second best time was anywhere in the last 8+ days. The third best time is now. ‍—‍a smart kitten_[meow] 18:22, 28 May 2026 (UTC)

Several of the affected engineers came into the Foundation through the volunteer community first, and that pipeline is part of why the Wishlist worked at all. The new program will need exactly the community-facing experience they have been carrying, and the most credible signal to both staff and the community would be to keep that experience inside the program, in roles that touch the Wishlist directly. Trust here is built by bringing community voices into the decision before it is made, not only into the review after. HakanIST (talk) 13:09, 25 May 2026 (UTC)

For the sake of transparency, are your answers written by or consulted with Jones Day union busting law firm which WMF seems to have on the payroll?

Which countries and which laws are you refering to that do not allow relocation to a new role but firing and rehiring? Can you provide sources for this argument of yours?

In solidarity with the union! Irdiism (talk) 06:21, 26 May 2026 (UTC)

There is evidence that in 2018 and 2021, w:Jones Day acted against unions for w:The Boston Globe, w:Slate (magazine) and w:Politics and Prose; and that WMF has been consulting with Jones Day in 2020 and 2021, and in 2025 The Legal 500 listed WMF as one of Jones Day's nine "key clients". So both Jones Day being a union busting law firm and WMF seems to have [Jones Day] on the payroll seem to be supported by the sources. Boud (talk) 17:58, 26 May 2026 (UTC)

There was some discussion about this on the enwiki Discord server a couple of days ago and someone pointed out that pretty much every major US law firm has been involved (allegedly) in union busting activities. The WMF needs a big law firm which is able to represent them both in the US as well as in other countries given the many lawsuits they are involved in (e.g. [5]). Johannnes89 (talk) 05:23, 27 May 2026 (UTC)

Fair points: it's credible that most major US law firms have been involved in union busting activities; and hiring a single big all-types-of-cases law firm may be more practical and effective than having to hire smaller specialist law firms for particular types of cases. As a (weak) analogy, apparently there are very few countries with no police and judicial corruption, but calling the police (in a typical country) after a violent break-in and then testifying in court against the intruder doesn't imply that you're supporting corruption.

It remains the case that SDeckelmann-WMF still hasn't given us (as far as I can see) any w:WP:RS for w:role-change labour law, which appears to be a hitherto-unknown-to-Wikipedia area of w:labour law that forbids shifting an employee from one role to another, even with the employee's agreement. I couldn't find anything in w:List of International Labour Organization Conventions that seems related, i.e. seems like w:WP:OR. Boud (talk) 14:55, 27 May 2026 (UTC)

I'd like to offer an option that I haven't seen proposed yet: because the annual plan didn't make comtech a priority, they decided to remove the thing that didn't meet the new annual plan. not unionbusting, just bad decision making on the boards part. As someone who has been on both sides of a nonprofit BoT, (albeit on a much smaller scale then the WMF) they seem to be drinking too much of their own kool aid and should come down from their board room and realize that acting like a normal cooperation/nonprofit doesn't work when everything you do is based on unpaid volunteers. So far, all the BOT did was make the organization more accurately match their "annual plan" that was reviled by the community for not covering this area. So this isn't union busting, it's just one of many really bad ideas by the board. Welcome to the WMF. The union busting is just a benefit. As far as I can tell, the goal of the current BoT is to avoid making headlines or getting on the wrong side of the current administration, rather than it's actual mandate. All the best -- Chuck ^Talk 18:02, 26 May 2026 (UTC)

References

Proposed direction for Wishlist

For the discussion on the English Wikipedia, see w:en:WP:VPWMF#WMF Community Tech team has been disbanded, engineers laid off

Copied from enwiki

Over the past days, there have been many suggestions on what shape the wishlist process should take. Community members are unified in demanding a stronger rather than weakened process. Selena Deckelmann has indicated she is open to some changes suggested by the community, and suggested that the foundation could come up with a new plan in 3 months in collaboration with meta:PTAC. First, I think it's important that we adopt a clear community proposal. Drawing from Sohom's, Novem Linguae's, and my proposals (@Sohom Datta and Novem Linguae), I suggest the community support the following as a route forward:

1. CommTech to be reinstated. We want a team intimately familiar with community norms maintaining community-critical tools, conducting wishathons, and working on smaller-scale wishes. This would also prevent wishes from going unaddressed because they do not fall into any particular team's purview.
2. Other teams to be given a quota of wishes they must work on, which is separate from annual plan obligations. That is, teams are required to pick up a certain value of wishes, and cannot be obligated by management to work on wishes that align with the annual plan.
3. Yearly survey to be reinstated. With wishes being handled by various teams across the WMF, the major problem of the old annual wishlist – the disproportionate amount of time spent on wish intake vs solving them – will have been solved. A yearly well-publicised survey brings together our different editing communities, and prevents the wishlist becoming an evergrowing backlog.
4. Individual ranking of wishes. Focus areas to be dropped altogether.
5. Prioritisation process to be majority community-owned. Simply formulating and voting on wishes should not constitute the entirety of the community's involvement. Feasibility should be assessed by engineers with community-facing development experience, like Community Tech staff and volunteer developers. The communities will further be responsible for ensuring that underserved communities like Commons, which have historically seen comparatively small turnout in the wishlist process, should be prioritised according to their need and not their turnout.

In solidarity, —Femke (talk) 🐦 08:34, 25 May 2026 (UTC)

Survey

• Support. This proposal will bring transparency and give the communities, whose work drives donations to the WMF, an actual say in what gets developed. It will allow bugs to be fixed and features added even if they do not meet arbitrary criteria that lack community support, such as being useful for Abstract Wikipedia. Certes (talk) 08:42, 25 May 2026 (UTC)
• I... can't support this proposal. I'll just weak oppose the whole proposal. The yearly top ten stuff was great at its time, but I really disdain creating the same failing wish annually. In the old one, if it gets very few or no votes, almost or most likely no chance that wish would be achieved. The newer one allows indefinite amount of time a wish can receive votes without expiration or whatsoever. I also don't like individually ranking every wish or top ten wishes. Too cumbersome, IMO. I like the #5 idea, but that would pressure a lot of staff too much, IMO. Should be broken down into parts re-proposed separately some other time, if not sooner. George Ho (talk) 09:14, 25 May 2026 (UTC)
• Strong support. While this doesn't (and isn't meant to) address the full suite of issues that prompt the Wiki Workers United solidarity petition, it is the best proposal I've seen to address the immediate issues, including by addressing the wrongful terminations that the WMF has now made three attempts at explaining without being able to answer why they did it. I hope that the WMF will take this proposal for what it is: an incredibly kind gift from Femke, and by extension Sohom and NL, to rescue WMF leadership from a crisis entirely of their own making and put them back in the good graces of the community. If they can't take advantage of this golden opportunity, I think it would be time to start discussing whether emergency leadership changes are needed. -- Tamzin^{[cetacean needed]} (they|xe|🤷) 09:15, 25 May 2026 (UTC)

  strong +1, though personally I'd rather place emphasis on systemic failure and the institutions that reward and encourage such decisions rather than individuals Kowal2701 (talk, contribs) 09:21, 25 May 2026 (UTC)

  I agree, but I mention leadership changes because, usually if an organization is stuck in an untenable position, those systemic changes aren't possible with at least some change at the top, because there'll usually be someone there who is actively or passively blocking change. Again, hopefully the WMF can take this as a great opportunity to turn things around and show they're on the same page as the community. Now would be a great time for someone senior (the CEO or a Board member, for instance) to take charge and really hit home to others in leadership how much of an inflection point this is. -- Tamzin^{[cetacean needed]} (they|xe|🤷) 09:34, 25 May 2026 (UTC)

• I personally think it makes more sense to focus on what can be done immediately before we start complex discussions about how to make the wishlist better. I also agree with Newslinger that the biggest issue was not the cadence, but the fact that the team was not given the resources to succeed. The foundation has never really taken the wishlist seriously enough beyond being obsessed with restructuring it instead of doing more practical things like assigning more engineers. Firing everyone and expecting other teams to magically have 10,000 extra hours to spend is even more nonsensical of a solution than normal, but that's a choice that they are actively choosing not to backstep on every hour. Clovermoss🍀 (talk) 11:28, 25 May 2026 (UTC)

  Our proposals have strong overlap: we both want the team reinstated, we both want more resources (this proposal provides the mechanism via quotas on other teams). I think it's good to keep the two intertwined discussions somewhat separate: how to improve the wishlist, and how to a safe work environment should be created for staff. What I want to prevent is a 3-months closed-door process that might only marginally improve the wishlist. PTAC has been ignored before on the topic. In solidarity, —Femke (talk) 🐦 11:37, 25 May 2026 (UTC)

  I agree that we need to prevent a 3 month closed door process where nothing actually happens. I just think the easiest way to improve the wishlist is bring back the people that were fired (along with everything I mentioned), hire more engineers, and stop forcing people to "clarify the need" over and over again every time they have a wish. What I don't like about the old wishlist system is that it's basically a competition of what technical features are the most vital to the community when we don't need to be having a competition in the first place. People should just be able to get the things that they need. Sure, some things are more immediately needed than others, but the state of things now is unsustainable. Another problem that can be more easily fixed by hiring more engineers. Clovermoss🍀 (talk) 11:43, 25 May 2026 (UTC)

• I broadly support these points, especially #3 and #1. I'm not sure what to make of the Annual Plan stuff – the way it was originally written, the idea was that closer Wishlist–Plan integration would mean putting large wishes into the Annual Plan, which is great. I can't say how much that has happened, though. I'm pretty sure it hasn't, really, so I support point #2, but if there is strong counterevidence we may have to rethink it. I'm also not sure pushing for the deprecation of Focus Areas is necessary when they seem to just be another level of organizational tag. If it helps WMFers combine wishes for simultaneous work, that's fine. Toadspike [Talk] 12:12, 25 May 2026 (UTC)

  An important feature of annual voting that we lost with the end of the Survey was an annual round of advertising (banners etc.). That needs to come back, and I wonder if @Femke is willing to add it to point #3. That's how I found the wishlist as a very new editor. Toadspike [Talk] 12:14, 25 May 2026 (UTC)

  Done. In solidarity, —Femke (talk) 🐦 13:06, 25 May 2026 (UTC)

• Strong support here. Discussions about the Wishlist and about supporting laid off employees can and should be held in parallel. Without a strong plan for the future of the wishlist, finding positions for employees in question will be much harder, and, conversely, the Wishlist plan will be at its best with experienced folks at its helm. In the future, we may rethink the Annual Plan to involve more community wish input, but we should build this iteratively and start with reforming the core aspect (the Wishlist itself) first. Chaotic Enby (in solidarity · talk · contribs) 13:03, 25 May 2026 (UTC)
• Strong support, I really like this plan, because it matches how I think the Wishlist should operate. It builds on mechanisms I know the WMF already uses, such as "Essential Work" quotas for necessary maintenance work outside the Annual Plan. The prioritization might seem complicated but it is roughly aligns with the way the way the Unsupported Tools Working Group convened by the WMF and PTAC already rank requests. I also do think the structure proposed does not preclude a tighter coupling with the Annual plan in the future, but rather makes it so that wishes that have significant community support and are not necessarily aligned with the plan at the moment get worked on regardless. -- Sohom (talk) 14:48, 25 May 2026 (UTC)
• I am not as conversant as my colleagues with the organizational details. But the basic principles here, of reinstating the team and prioritizing their work based on the community's desires, ought to be common sense, and have my strong support. Vanamonde93 (talk) 17:02, 25 May 2026 (UTC)
• Strong support. Point #1 by itself is enough for me to strongly support the entire proposal, as these unjustified layoffs are the most urgent matter being discussed, and I believe it is critical for the community to stand together on this. I also support points #5 and #2, respectively, to increase community representation in product decisions and allocate additional resources for community priorities. On #3 and #4, I am neutral because I am open to different ways of structuring the Community Wishlist, as long as there is a substantial increase in the amount of resources dedicated to fulfilling the wishes. (Per Clovermoss, adjusting the Wishlist cadence without ensuring that the wishes are adequately resourced is not going to deliver the results the community is looking for.) Altogether, these five points are an excellent first step that Selena and the rest of Foundation leadership can implement right away to show that they are serious about recovering from this controversy and restoring positive relations with the community. — Newslinger talk 18:32, 25 May 2026 (UTC)

  On #3 and #4, I am neutral because I am open to different ways of structuring the Community Wishlist, as long as there is a substantial increase in the amount of resources dedicated to fulfilling the wishes.

  Personally, I'm not very fond of scrapping out the "Focus Area" all together. The "Focus Area" is more organized and well straightforward. However, as I see, others like to rank individual wishes more.

  For annual voting, I'm thinking some sort of secret vote similar to how we vote candidates of board of trustees, arbitration, and administration... or some sort of secret ranking. Also, I would never wanna repeatedly create the same wish annually if it attracts very few votes, so perhaps a secret vote might prevent the same wish from being repeatedly created over and over. Nevertheless, the wish should remain open even if it fails to attract a lot of yearly votes. George Ho (talk) 20:04, 25 May 2026 (UTC)

  No secret votes or rankings please. I'm ambivalent to Focus areas, but my compass on them is that WMF folks do not use them much and the community views it as a failure. Sohom (talk) 20:15, 25 May 2026 (UTC)

  To clarify, you mean "No secret rankings", not "No rankings", right? If you mean the latter, my mind could very much be changed by your arguments. ~ le 🌸 valyn (talk) 20:25, 25 May 2026 (UTC)

  No secret rankings is what I meant :) Sohom (talk) 20:42, 25 May 2026 (UTC)

• Strong support from me. I agree with others that we will need two parallel solutions for the immediate problem of commtech/wishlists and the larger problem of the WMF's institutional disconnect from the community; this proposal addresses all my concerns for the former. ~ le 🌸 valyn (talk) 19:57, 25 May 2026 (UTC)
• Support I'm not sure I agree with killing the entire concept of focus areas, but the rest of this all seems very sensible. * Pppery * _{in solidarity} 20:32, 25 May 2026 (UTC)
•  Support I would like to remember the implementation of uploading textures meshes on Commons. We need enough manpower to add great additions to projects like Commons to stay relevant also in the future. --PantheraLeo1359531 (talk) 12:44, 26 May 2026 (UTC)
•  Support 1, 2, 3, 5. I need to write this out in more depth ASAP, but the new format has produced a higher volume of work. I think the work has sometimes been in the wrong places (ok maybe frequently), but the focus areas are the one claim of improvement from when the Wishlist was demolished that has come to pass in terms of increasing team efficiency by letting them focus on specific parts of the code base for a time. We shouldn't abandon it just because it was initially implemented poorly. Best, Barkeep49 (talk) 15:20, 26 May 2026 (UTC)
• Personally, I agree with the WMF needing to preserve its understanding of the community and its priorities, which generally means keeping the same people involved with community interactions over extended periods of time. However I don't like dictating a specific org structure (as long as the interface to the community and the prioritization of development remains consistent, I'm indifferent about who reports to who). I think that for feature development that spans multiple development teams, ingraining responsibility for the feature with the code owners is the best way to put the feature on a strong footing for ongoing maintenance and support. There are different ways to achieve this, and I feel those in charge of development should be able to structure their teams as they best see fit. isaacl (talk) 17:32, 26 May 2026 (UTC)
• Support all five points. After reading on the matter in the last few days, I think all five proposals are helpful; I am not opposed to further tweaks though, as the precise wording is less important than the movement here. Whether a reinstated CommTech would comprise the same people or not is to me less important than all the members that were let go be retained, to not lose their invaluable technical+community experience, and that we do not lose technical staff in any way. Like Clovermoss says, at the end of the day, we need more engineers, not less. Choucas0 🐦‍⬛ 17:39, 26 May 2026 (UTC)
• Support, this sort of proposal is what we needed, and I appreciate Novem's effort to make this happen from the start in the original enwiki Village Pump post, even if it got lost in the mix for a while. You can also assume my support on wording changes or similar wishlist proposals unless otherwise specified. Especially if they're endorsed by Sohom Datta and Novem Linguae, who are more in-the-know and whose judgement I trust. Thebiguglyalien (talk) 21:14, 26 May 2026 (UTC)
• Strong support on all five points. --Grnrchst (talk) 11:26, 27 May 2026 (UTC)
• Generally support, except #3, which I find per my discussion below to be a nostalgia-based distraction that would take up WMF time to reconstruct when we already have a (technically) working ongoing wishlist system in place. Also per my discussion is we have to have a plan of what to do if the proposal isn't accepted. StefenTower (talk) 20:45, 27 May 2026 (UTC)

  Upon further reading and pondering, I am more neutral on #4. Focus areas – secondarily – can be useful, but at the same time, these should "bubble up" from the individual wishes for the sake of combining ideas and focusing developers' work. StefenTower (talk) 20:56, 27 May 2026 (UTC)

• Support, although I agree that it does seem a little like some of the proposals are in slight conflict with each other — these need to be clarified a little (I at first thought we were being asked to vote on them individually). But OTOH any one of them, by themselves, would be an improvement on the status quo, such as it is. Daniel Case (talk) 21:03, 27 May 2026 (UTC)
• Support at least as an interim solution until something more concrete can be hammered out. Takerlamar (talk) 22:35, 27 May 2026 (UTC)
• Support, and Strongly support Clovermoss's suggestion. This is just the latest episode in a long series of tone-deaf and trust-damaging actions taken by the WMF. In previous instances, the response has been to ignore community outrage until it becomes unignorable, then to placate with conciliatory words, then to walk back just enough to quiet the storm and move on. The problem with the strategy is that it leaves the community expectant of increased awareness of community expectations in the future, and each successive incident receives less patience from the community. At this point we need to see decisive action to realign leadership with community expectations. A commitment to improvement isn't enough, - we need to see immediate, actual improvement. LWG (talk) 03:58, 28 May 2026 (UTC)
• Oppose 2, 3, & 4 As to 2, a quota is a poor system. It just encourages doing lots of little wishes rather than the big, important wishes. Further, saying "teams, you must do this in addition to your annual plan" is us trying to insert ourselves into complicated corporate and managerial planning. If teams want to tackle wishes that align with their annual plan goals, then that means their annual plan goals are aligning with community wishes. That's a good thing. As to 3, the old wishlist is dead. Point 3 is an attempt to revive it. As I said before, the solution to the issue of participation could be more easily solved by once a year simply publicizing the wishlist and soliciting wishes. As to 4, individual ranking may be a good idea, but dropping focus groups entirely is not. Support 1 & 5 As to 1, If there is no dedicated team to manage the wishlist...it will fall by the wayside. CommTech was that team. Either CommTech needs that responsibility, or some team needs to have dedicated staff who is focused on the Wishlist, and not just the part of it that applies to their team. As to 5, I agree that the community is best suited to say what it needs the most. Though we must remain sober about the interplay between what we want and what can be delivered. CaptainEek ^{Edits Ho Cap'n!}⚓ 06:49, 28 May 2026 (UTC)

  @CaptainEek: Wrt to 2, some context. The current structure used by the WMF already has quotas, but this system has gone unused since teams typically chose either the smallest possible wishes, did not fill up their wish quota at all or worked on wishes that were largely aligned to the annual plan (if you need data for this, feel free to look at the tasks associated with the editing and the web team in Barkeep49's analysis). With 5, and the addition of "these wishes must be done outside of the annual plan" the idea is that we would plug two holes, 1) provide teams with an already prioritized list where they are dis-incentivized from choosing only the smaller tasks 2) separating the quotas from the annual planning structure and thereby discouraging folks from only choosing tasks the align with their annual plan. Sohom (talk) 13:28, 28 May 2026 (UTC)

  @CaptainEek, #2 clearly states that the teams cannot be obligated to pick wishes that align with their annual plan. It doesn't say they can't pick wishes that do. There's absolutely nothing here that would prevent a team from only picking up plan-aligned wishes, provided that they still met the quota. asilvering (talk) 18:05, 28 May 2026 (UTC)

• Support I am sympathetic to prior arguments that English Wikipedia's priorities dominated smaller communities, but nuking the CommTech team is the most ridiculous solution. Shushugah (talk) 07:57, 28 May 2026 (UTC)
• Support _signed, Rosguill ^talk 14:10, 28 May 2026 (UTC)
• Support. Freedom4U (talk) 15:23, 28 May 2026 (UTC)
• Support on all points. Betseg (talk) 19:46, 28 May 2026 (UTC)
• Support I want to add something, related to point 5, "Prioritisation process to be majority community-owned." I am a major supporter of and beneficiary of the wishlist, but also I have observed a conflict which is challenging to address and discuss. In the project management cycle, completing a wish is a measured success metric. There are uncomfortable, high-pressure evaluations at the end of wishlist projects, where someone on the WMF side asks the Wikimedia community how completely the result fulfills the wish. I greatly appreciate the work of the developers who contribute to the wishlist, but in giving feedback, if the wish is not actually fulfilled, especially for niche projects where not everyone understands the feature, then there is pressure on community members to withhold criticism and to consent to give the project a satisfactory evaluation when actually the product does not fit the need. In addition to the community deciding which wishes to prioritize, I would also like the community to be empowered to give a community evaluation of the results.

If the community can speak freely to evaluate projects, especially with other community members, then there will be fewer pressures and conflicts leading to errors in evaluation. The wishlist can actually have a counterproductive effect if a wish results in an unusable outcome, because then the label of a fulfilled wish blocks future efforts to address the problem. Bluerasberry (talk) 21:51, 28 May 2026 (UTC)

• Support the overall direction of this proposal. I do have some minor concerns, such as whether focus areas necessarily need to be abolished, but imo those details aren't particularly important compared to the broader direction being proposed here. --𝓰𝓲𝓷𝓪𝓪𝓷기나ㅏㄴ(T/C) 01:36, 29 May 2026 (UTC)
• Support While details could be argued, it is better to have clear support for a good proposal rather than diffuse efforts finding something perfect. I have reservations about the annual wishlist, namely that vote counting can promote glitz over boring but essential stuff such as the improvement of anti-abuse and anti-spam tools. That can be worried about later. Johnuniq (talk) 02:03, 29 May 2026 (UTC)
• Support TheJoyfulTentmaker (talk) 06:27, 29 May 2026 (UTC)
• Support. I am not sure about abolishing focus areas, as I don't know much about it. But overall, I support the proposal. Repakr (talk) 07:28, 29 May 2026 (UTC)
• Support There is really important and needed. Yann (talk) 09:20, 29 May 2026 (UTC)
• Support Though I agree realising some of the wishes is complicated, I think some kind of yearly wishlist is a good idea and should be kept. Perhaps there should be space and time for engineers to comment on the wish/proposal (there kind of was space for that but IIRC not always happened). This should be much like with a citizens' budget, people from the city council check whether a certain proposal is feasible and give their opinion for the consideration of the community. A similar thing could happen for the Community wishlist and having a team more dedicated to the wishilsts that is proposed above would definitely help. Nux (talk) 10:51, 29 May 2026 (UTC)
• Support — these are much-needed corrections to make the community wishlist work better for the community and bring things back to the way they were. I haven’t participated in the last few wishlists because of the WMF’s changes to the process, and this proposal (if implemented) would go a long way toward making the wishlist more accessible and useful. — pythoncoder  (talk | contribs) 13:37, 29 May 2026 (UTC)
• Support needed course correction. AirshipJungleman29 (talk) 17:34, 29 May 2026 (UTC)
• Support the WMF need to focus a significant proportion of their resources on improving the software in ways that editors suggest, and this seems a good approach. --Yodin^T 19:03, 29 May 2026 (UTC)
• Support. Mbkv717 (talk) 21:25, 30 May 2026 (UTC)

Discussion

Will you divide the support, oppose, and neutral/other votes? That way, the votes would be easy to see, IMO. George Ho (talk) 08:43, 25 May 2026 (UTC)

If the survey starts becoming too complicated, that might be an option later, but I feel that an open-form survey where people can have more complicated opinions is better for a consensus-forming discussion. In solidarity, —Femke (talk) 🐦 09:03, 25 May 2026 (UTC)

I think it is generally a bad idea to have two sections as this tends to make a more polarised poll. I mean if there are separate sections then you go to one section and read some comments in that section only and you will probably have even more radical then you had. If you read comments from both sides you have the chance to read more arguments. Nux (talk) 15:03, 29 May 2026 (UTC)

In this case, the support for this proposal has gotten huger and huger, and I'm afraid there isn't anyone convincing others to oppose this proposal. Indeed, this proposal is just advisory to the WMF, especially for those hostile to the WMF.

Generally, nonetheless, readers tend to have shorter timespan when skimming through comments. Having one combined survey section makes votes much longer to read, while dividing up the survey section into at least two or more is more closer-friendly, IMO, and helps the closer determine whether there is a consensus... or not. George Ho (talk) 17:49, 29 May 2026 (UTC)

You can just ctrl+f and count matches. It's even easier with syntax highlighting search feature. Nux (talk) 00:22, 30 May 2026 (UTC)

This seems as good a place as any to put this: one of the frequent issues the WMF has when engaging with the enwp community is the volume and variation of opinions, the difficulty in discerning what has consensus, sussing out shared underlying concerns and interests, separating what's being said loudly by a few people from the goals of the group, and what actually represents the thousands of users that don't participate in these threads. This sort of explicit proposal is one way to deliver a clear message, but it also occurs to me that when it comes to technical processes, there are a reasonably small number of enwp contributors who (a) are up on issues regarding the wishlist and other "community tech" matters, (b) have a civil-enough-to-get-things-done relationship with WMF staff, (c) are technically competent enough to have practical conversations with engineers, and [perhaps most importantly] (d) enjoy broad trust within this community to talk about such matters. When I saw Novem's initial post at the top, one of my first thoughts was "let's just tell the WMF that Novem, Sohom, [and a couple others] can speak for us on this issue". Obviously this thread has expanded to be about the union, too, since then, but I still wonder if there's something to say for such a structure (assuming those who have that trust would want that gig). I think one of the reasons ArbCom is able to be [at least sometimes] effective in interfacing with the WMF is because it's a small group with demonstrated trust to speak on our behalf within a specific range of contexts. It simplifies communication, in other words -- the WMF knows who to listen to, and that there will probably be problems if our chosen representatives are routinely brushed off. Community Tech seems like another case where such a committee, of sorts, might be useful. Food for thought. Feel free to move this elsewhere, if that's cleaner. — Rhododendrites ^talk \\ 14:11, 25 May 2026 (UTC)

There is a small group that acts a bit like that, the meta:PTAC, where Sohom is a member. This group was not listened to in terms of CommTech. I hope getting a clear community signal will change that, and make their community advocacy more effective. In solidarity, —Femke (talk) 🐦 14:23, 25 May 2026 (UTC)

Thanks. Was reluctant to pitch a new committee in part because, well, it's tough to keep track of all the committees. I suppose the important thing would indeed be some sort of signal that PTAC (or something else) speaks on behalf of this community and is vetted by this community, rather than just being interested parties that are vetted by the WMF. — Rhododendrites ^talk \\ 14:33, 25 May 2026 (UTC)

I can also add, @Rhododendrites, that Product Safety and Integrity has been doing something like this in their work with stewards and checkusers, and it's working very well. So I believe it can be done, though obviously PSI has a huge advantage here in that functs are a small group that's easy to find. Working on the scale of the whole community is much harder. In solidarity, asilvering (talk) 14:42, 25 May 2026 (UTC)

I think part of the problem is expecting people to come to the places the WMF prefers to engage in (endless committees and annual plans) instead of paying someone to consistently be "on the ground". The board of trustees offers one-hour calls a few times a year and prides themselves on "listening" for the simple fact that other organizations don't even let you complain at them. But if the wmf wants to be better, it needs to actually walk the walk. I'm not saying stuff like PTAC isn't useful because it is very important, but it needs to be supplemented with regular, sustained effort. It doesn't help that a lot of people tune out the discussions the wmf even offers in the first place because they're tired of not having the heart of the matters be addressed. Another problem of firing all these people is that they're some of the most recognizable wmf staff to the average editor. People knew they could come to these people if they needed something done. Like, 2/3rds of the people I trusted to be able to listen are straight up gone now, and I'm aware of more staff than most. And they're taking their irreplaceable expertise with them. Clovermoss🍀 (talk) 14:57, 25 May 2026 (UTC)

I get as annoyed with "yet another committee" as anyone, I think, but this suggestion isn't about where to have the debate but rather (a) how we can ensure specific messages are heard by the WMF, and (b) how the WMF can ensure what it's acting upon is representative of the community. An utterly massive VP thread can do a lot of things, but distilling the opinions of thousands of Wikipedians into a handful of concrete, actionable suggestions is not typically among them. If there's an opportunity to just say "these people have unusual levels of trust, let them speak for us" IMO that rare phenomenon is going to be more productive not because of where those debates take place but because it makes the communicative task substantially less noisy. — Rhododendrites ^talk \\ 21:30, 25 May 2026 (UTC)

This would certainly be very helpful, although PTAC only partially plays this role. The group is focused, as its name implies, on product matters (rather than governance matters), is hand-picked by the WMF without community involvement, and is not bound to community voices. These matters give them a fundamentally different role from "community spokespeople", and one closer to "qualified advisors with community experience".

Both of these roles are very much necessary, assuming WMF leadership wishes to keep in touch with community needs. However, if PTAC isn't fundamentally reformed – which may carry it away from its initial goal –, it shouldn't be made to assume both roles by itself. In that case, the incentive to build such a spokespeople group should come from the community itself, not from the WMF, to avoid creating what has been likened to a company union. Chaotic Enby (talk) 21:44, 25 May 2026 (UTC)

My argument is that there's a difference between people talking amongst each other on a committee about new things to plan and someone actively being a point of contact for people within a community and having some degree of authority with the WMF (ideally there'd be at least one person for enwiki, commons, and other big communities doing this sort of role). The last village pump thread I started about these issues when we weren't in the middle of a controversy convinced me this would be a good idea. A lot of people care whatever it is that they care about and can be frustrated that whenever the foundation wants to engage with them, it's in a very specific capacity like product testing. They don't nessecarily have a place for everything else they might want to say and have it be heard. The foundation is very reactive when it should be proactive. Someone argued that Movement Comms is meant to be this, but almost no one on enwiki even know that they exist, hence my "on the ground" suggestion. Ideally someone in this role would have had years of experience contributing to the project they are representing so people know who they are and can rely on them long-term instead of trying to keep track of all the people who come and go at the foundation (another reason that inexplicably getting rid of a bunch of established employees like the ones at CommTech is a terrible idea). And since this role would easily be full-time, it should be compensated. Clovermoss (talk) 21:58, 25 May 2026 (UTC)

I think we're in agreement here that a new committee is urgently needed for that matter. It should clearly be built from the bottom up, by the communities involved, which will both give us more freedom in approaching the matter and save us from relying on the WMF being proactive. I'm not sure about having it be compensated: if it is a single person per community, it would be full-time, but it would also (likely) be overwhelming. Plus, having several people cross-reference their readings could avoid issues where a single editor misunderstands community positions, on top of alleviating the individual workload.

This could allow us to do away with compensation and have a group that isn't reliant on the good will of the WMF for its continued existence – and thus be less susceptible from pressures, as reminding the WMF to listen to that group is easier when the livelihoods of editors in question aren't at play. Chaotic Enby (talk) 05:48, 26 May 2026 (UTC)

cc I suppose the important thing would indeed be some sort of signal that PTAC (or something else) speaks on behalf of this community and is vetted by this community, rather than just being interested parties that are vetted by the WMF - I've talked with @SDeckelmann-WMF about having some kind of community-vetting of the candidates but I think she has reservations about it. (I will let Selena explain if she can, since this was last year, and I forget what the exact problem was). Sohom (talk) 15:11, 25 May 2026 (UTC)

With all respect to the people on PTAC, who i do genuinely like, I always felt that PTAC was essentially WMF's attempt to setup a Company union for volunteers. Bawolff (talk) 16:47, 25 May 2026 (UTC)

I have shared this worry in the past, and that is one of the reasons why I strongly argue for volunteers to be able to choose who represents them through PTAC. As amazing as the current PTAC volunteers are, the fact that the WMF is ultimately picking them makes me worry that they might be subject to the same pressures to avoid overt dissent, even if that doesn't represent their true motivations (or the community's). Chaotic Enby (in solidarity · talk · contribs) 17:25, 25 May 2026 (UTC)

Knowing some of the folks on the list, I'm confident they won't cave to those pressures, even if they are subject to them. In solidarity, asilvering (talk) 17:57, 25 May 2026 (UTC)

True, but that's only because of who is currently on that list. If we want to build a more resilient system for the future, we shouldn't take that for granted. Chaotic Enby (in solidarity · talk · contribs) 19:13, 25 May 2026 (UTC)

Thanks Sohom for the invitation. First, there are multiple challenges with any selection process for the PTAC, so I don't want to make it sound as though any process might be perfect. To begin, I faced a bootstrapping problem where it was unclear how to begin, and I recall us discussing that. I also have thought about some of the issues User:Rhododendrites has gently raised in this thread about distillation and representation. We may have discussed timing of votes relative to other onwiki processes and volunteer capacity and attention. We also have discussed finding expertise and familiarity with web-scale software and distributed systems, and how to support better and clearer communication over time. I am in listening mode, so I am not intending to put forward any proposals, but I hope that gives a sense of the kinds of things we discussed at that time. SDeckelmann-WMF (talk) 00:04, 27 May 2026 (UTC)

@SDeckelmann-WMF, this may very well be an argument from ignorance, and if so I apologize. I've heard that there were multiple rounds of interviews to select PTAC members, and that struck me as a very costly way to go about selecting people, and one that has very little community input. Ideally, it would be the other way around: cheap, and with lots of community input. Now that you have had the experience of a working PTAC, could the current PTAC members, and the WMF staff who work with them, not put together some kind of report that (relatively briefly) summarizes what kinds of tasks PTAC members do, and what qualities and experience are most useful to have in PTAC members? Then for the next round, the community could have candidates put themselves forward and we could vote on a shortlist. That allows for quite a lot of community input, while still leaving the final choice in the hands of the staff who will be working with them. asilvering (talk) 03:06, 27 May 2026 (UTC)

@asilvering thanks for this proposal to describe better what the PTAC does. It may be that some of that is answered by a recently produced a charter that describes some but perhaps not all of what you suggested be put into a report. The charter was part of helping us through the bootstrapping problems I mentioned earlier. Just speaking for myself, I am grateful for candidates who offer to spend precious volunteer time in this way. Most of the people I spoke with during interviews put themselves forward, or were approached by long term community members and long tenured staff to put themselves forward. In a few cases, in order to ensure representation of a variety of sister projects and regions, I approached individuals to ask them to consider participating. From my perspective, the interview process which involved 2 rounds of interviews was cheap in terms of my and my team's time -- relative to other situations that I've been involved with since 2022 that are reactive, unstructured and don't have clear end dates or goals, and also relative to what we learned from the conversations. I agree with others in this thread who have said that not everything can be solved through the involvement of the PTAC (or another committee), and the group would need to agree to any next steps. I will bring this as a proposal to consider to the PTAC. SDeckelmann-WMF (talk) 14:52, 27 May 2026 (UTC)

From my perspective, the interview process which involved 2 rounds of interviews was cheap in terms of my and my team's time

Thanks a lot! Could be great to also hear candidate perspectives there. Chaotic Enby (talk) 15:07, 27 May 2026 (UTC)

From my POV, the 3 interviews were definitely atypical in the requirement of allocating synchronous "talk-to-somebody" time. If I am running for any other community position, yes there would be more questions to answer, but I could answer them asynchronously, say while eating, or in a coworking space. That being said, I do kinda agree with relative to other situations that I've been involved with since 2022 that are reactive, unstructured and don't have clear end dates or goals since I think the P&T dept hasn't had formal committees, but rather had unstructured community consulations. (I think m:U4C and en:WP:ARBCOM, en:Ombudsman Committee are owned by Legal and Trust and Safety?) It might make some sense to take a peek at their homework, to see if there is a way to do only one interview, and then let there be some lightweight community voting for a week as well. (I'm also acutely aware that representation is definitely a concern in that context) Sohom (talk) 13:07, 28 May 2026 (UTC)

These days, we're all technically next door to T&S with the Community Governance Support team. Izno (talk) 00:59, 29 May 2026 (UTC)

Shouldn't this take place on Meta? Otherwise it looks like enwp imposing something on the whole Wikimedia community. Nardog (talk) 20:21, 25 May 2026 (UTC)

That is a good point, I wasn't quite sure what the best place would be, given that such a large part of the discussion has been taken place here. Cross-wiki transclusions are not a thing right? Will post there too. In solidarity, —Femke (talk) 🐦 20:23, 25 May 2026 (UTC)

Probably best to just cut and paste the section. Nardog (talk) 20:30, 25 May 2026 (UTC)

If you do so, please ping all involved editors as they won't automatically be subscribed. Chaotic Enby (in solidarity · talk · contribs) 20:38, 25 May 2026 (UTC)

Done. —Femke 🐦 (talk) 20:57, 25 May 2026 (UTC)

Pinging everyone involved: @Certes @George Ho @Tamzin @Kowal2701 @Clovermoss @Toadspike @Sohom Datta @Vanamonde93 @Newslinger @LEvalyn @Pppery @Rhododendrites @Asilvering @Bawolff @Nardog. Chaotic Enby (talk) 21:01, 25 May 2026 (UTC)

The subthread at VPW should probably be closed and redirect here? Kowal2701 (talk) 21:04, 25 May 2026 (UTC)

I've already redirected the survey and discussion here. Keeping the proposal in duplicate to make it easier for people to see what's going on. —Femke 🐦 (talk) 21:11, 25 May 2026 (UTC)

Dunno why this proposal occurs here rather than as an RFC subpage. I'm thinking this serves as an immediate pressure on WMF, while an RFC might conclude a year later or so. —George Ho (talk) 16:05, 26 May 2026 (UTC)

After years of very slow conversations around the wishlist, scattered with different volunteers, having a central more rapid conversation makes more sense. —Femke 🐦 (talk) 16:15, 26 May 2026 (UTC)

We should probably do a MassMessage to other language wikipedias' village pumps, @Chaotic Enby's done this before. I think people from smaller wikis will want measures that ensure there needs aren't dwarfed by enwiki's, but tbf I think that's something you alluded to wrt. Commons. Tbh I'd suggest sneaking in "and non-English-language wikis" Kowal2701 (talk) 16:23, 26 May 2026 (UTC)

Yep, I can do this when I'm back home in an hour or so. Chaotic Enby (talk) 16:30, 26 May 2026 (UTC)

Maybe something like

Apologies if this has not yet been translated into your wiki's language. You are invited to voice your opinion on a new [[m:Talk:Community Wishlist#Proposed direction for Wishlist|community-proposed direction]] for the [[m:Community Wishlist|Community Wishlist]]. Thank you ~~~~~ sent to Distribution list/Technical Village Pumps distribution list Kowal2701 (talk) 16:31, 26 May 2026 (UTC)

Looks good, only worry is that it misses out on a lot of wikis that have a "main" village pump but not a technical one (although not all, some like frwiki have their main village pump included). Probably the best target nonetheless.

Courtesy link to Special:Diff/30455401 which is how I did it. Chaotic Enby (talk) 16:36, 26 May 2026 (UTC)

Yeah, also when we send it we should put a notice somewhere in this thread that explains the situation to newcomers Kowal2701 (talk) 16:42, 26 May 2026 (UTC)

I have been posting on a few languages already. Is it easy to exclude languages? I've done french, spanish, italian, portuguese, swedish, hindi, japanese, dutch, danish, hungarian and afrikaans. —Femke 🐦 (talk) 17:30, 26 May 2026 (UTC)

First, the proposals from Sohom, Novem and me should be added. Then post at techical village pumps where they exist and main ones where there is not one. Also @Femke I'd like an apology, for ignoring my proposal, thanks. Don't just post to Wikipedias and Commons, there are more WMF wikis than that. Snævar (talk) 17:34, 26 May 2026 (UTC)

Hi @Snævar: could you link your proposal, I missed it? I've tried to synthesise a proposal from the ones I saw, and apologise I didn't notice yours. I've linked already to Novem's and Sohom's proposals, and you can see from the above that Sohom is happy with this synthesis. I'm keen to hear from @Novem Linguae too. Good point about posting to other wikis too, is that on your radar @Chaotic Enby. Are you taking this forward? —Femke 🐦 (talk) 17:43, 26 May 2026 (UTC)

I'm taking this forward, most distribution lists include wikis beyond Wikipedia editions and Commons. Chaotic Enby (talk) 18:01, 26 May 2026 (UTC)

I can’t speak for Femke, but I think #5 is purposely vague on how to ensure smaller wikis get their needs attended? The exact measures for that can designed at a later date, but I agree that that was a very big problem with previous Wishlists Kowal2701 (talk) 17:45, 26 May 2026 (UTC)

Yes, that's right. The big problem now is that the Foundation has been deciding how to weight the wishes top-down. These kinds of decisions can be made more fair in a bottom up manner. —Femke 🐦 (talk) 19:27, 26 May 2026 (UTC)

Request sent! Chaotic Enby (talk) 01:01, 29 May 2026 (UTC)

Sent MassMessage 𝓰𝓲𝓷𝓪𝓪𝓷기나ㅏㄴ(T/C) 04:36, 29 May 2026 (UTC)

Why am I the only one so far opposing the whole proposal? Is the whole crowd giving the if-it-ain't-broke-don't-fix-it attitude lately? Even partial supports from isaacl, Barkeep49, and Pppery still has neither increased my confidence with this proposal nor persuaded me into changing my stance about this... yet. --George Ho (talk) 21:57, 26 May 2026 (UTC); edited, 21:58, 26 May 2026 (UTC); self-corrected, 04:10, 27 May 2026 (UTC)

My comments are more on the collaboration between the WMF and the community, and not really in support for the specific proposal (though there is one common underlying principle regarding continuity in community support). I've previously stated how I think those responsible for determining the MediaWiki development plans need to work more closely with the community so there can be a shared understanding on the prioritization of work items. On its side, the community needs to appreciate that there are real limitations in supporting a legacy code base with a large number of users. isaacl (talk) 02:37, 27 May 2026 (UTC)

Thanks for clarity, so I can stand corrected on that, especially after rereading your "Survey" comment. --George Ho (talk) 04:10, 27 May 2026 (UTC)

@isaacl Can you say more about MediaWiki development plans and any examples that come to mind? I am not disputing a need for additional shared understanding, but just wanting to learn more about your perspective. SDeckelmann-WMF (talk) 19:07, 27 May 2026 (UTC)

I think that the high level plan is presented at the beginning of the year and that some projects have checkpoints during their lifecycle where user feedback is sought. But there are still significant numbers of users who feel like their concerns are not taken into account when decisions are made on program priorities and project implementation.

Akin to Scrum, I think there should be faster, tighter feedback loops with users throughout the development cycle, so adjustments can be made more quickly. (This can be adapted based on need; for example, small, optional features might not need more feedback loops.) As I wrote earlier this year on the English Wikipedia WMF village pump, I appreciate it's very challenging to get a sense of what will best serve most users, given the large silent majority and the diversity of views among those who do speak up. I appreciate that given the many different wiki communities, this would require significant staff support, depend on finding sufficient interested volunteers from the communities (or finding willing community members willing to come on staff), and would inevitably be imperfect. Nonetheless, I think the user base appreciates honest efforts to understand its needs.

While projects on features to attract new users are important, continuous improvement for existing features is also critical to retain users for a longer tenure. In cases where technical debt is inhibiting improvement, it would be encouraging to the community for plans to be made to transform the code base to a more sustainable state. As I discussed two years ago, I know software without a revenue stream doesn't have a profit metric to help determine how much to spend on that type of improvement. Nonetheless, as long as the MediaWiki software remains a core component to achieve the WMF mission, many users want to see more investment into MediaWiki, even at the cost of other WMF programs. We need to take care of the heart that underpins the movement, so that the rest of the body can thrive. isaacl (talk) 04:06, 28 May 2026 (UTC)

I am in listening mode, so I am not intending to put forward any proposals, but I hope that gives a sense of the kinds of things we discussed at that time.
— User:SDeckelmann-WMF 00:04, 27 May 2026 (UTC)

When you said you won't put forward any proposals, this includes (but not limited to) this whole proposal, parts of it, proposals restricting uploads by newbies at Commons, and other proposals and non-binding advisories at Meta-Wiki RFCs, right? Also, how else do any of us send you feedback about anything related to Wikimedia projects at hand besides WM:FORUM and RFCs? —George Ho (talk) 01:02, 27 May 2026 (UTC)

@George Ho: I think she meant specifically surrounding PTAC membership/community representation. For sending feedback in general, I'm pretty sure Selena is open to hearing from you on her talk page or by pinging her onwiki (or even talking to her through offwiki channels). Also, I'm hoping proposals restricting uploads by newbies at Commons is a joke? Sohom (talk) 01:30, 27 May 2026 (UTC)

Not a joke exactly: Requests for comment/Restrict non-confirmed users of all wikis from crosswiki-uploading files to Commons. George Ho (talk) 01:34, 27 May 2026 (UTC)

I see! Sohom (talk) 01:43, 27 May 2026 (UTC)

@George Ho: I just meant with respect to PTAC membership and the thread Sohom invited me to. SDeckelmann-WMF (talk) 17:21, 27 May 2026 (UTC)

Pinging all volunteers who have commented on the this talk page since 2024, but excluding those who have commented since May 20 to avoid the impression of canvassing: @It's moon, Polygnotus, Matěj Suchánek, Commander Keane, Cookai1205, Sabelöga, আফতাবুজ্জামান, Jdlrobson, EdoAug, Ahecht, Putnik, RoyZuo, Ita140188, GhostInTheMachine, Stjn, CaptainEek, Prototyperspective, Jack who built the house, TheDJ, Johannnes89, Ponor, Iniquity, A smart kitten, StefenTower, Klein Muçi, and Kudpung:. —Femke 🐦 (talk) 19:20, 27 May 2026 (UTC)

(Came here before noticing I was pinged) So much to process here. On #3, that reminds me of when people say "I wish we could bring the 70s back", and I have to be the objective butthole who reminds them "it's fun to reminisce but there's no going back, deal. Your only choice is to live in the now-time." And this is how I regularly lose friends (kidding... or am I?). Anyway, a lot of us certainly had great fun with the annual surveys, but I agree with the idea already expressed that the cadence isn't the issue, it's the dedication (or lack thereof) to resolving wishes that is at issue. Also, a couple years ago, I already had expressed my misgivings about changing to the new system, but I now admit that both approaches had and have their upsides and their downsides. But the current infrastructure is what we have, and should continue improving that as much as we can. Going back is too nostalgia-based for me to take that idea seriously.

On the rest of the proposal, I feel it for the most part, but I think it's missing something: the "or else". In my view, the "or else" perhaps should mean individual projects handling their own wish lists and certainly, the behemoth English Wikipedia threatening to do that may just jar the right people. If this approach was to come into being, then any wishes that are related to core software or common tools would go into Phabricator for the international community to chew on. This doesn't obviously resolve funding for developers, but projects could develop their own donation collections for developers, which may be best handled infrastructurally via development hubs like Github, with projects doing whatever they feel appropriate to direct site users to this funding approach. Of course my preference is for WMF to take the wishlist seriously and faithfully consider the demands of the proposal (outside of #3). StefenTower (talk) 20:19, 27 May 2026 (UTC)

@StefenTower, one of the major problems with the new system is that community engagement with it is way down. If our only choice is to live in the now-time, we are going to have to fix that problem for volunteers to feel that their requests are being heard. asilvering (talk) 20:59, 27 May 2026 (UTC)

The lack of community engagement largely comes from your latter point. If people saw that the process was bringing a lot of useful improvements, they would engage with it more (akin to why many folks don't vote in elections, IMHO). Also, more regular advertising of the wishlist wouldn't hurt. StefenTower (talk) 21:04, 27 May 2026 (UTC)

Also, more regular advertising of the wishlist wouldn't hurt. I think this is the secret sauce. It needs to be on a set date every year and it needs to be coupled with a marketing campaign (central notice banners, etc.) In my opinion, this is why engagement was high before, and why it isn't now. Without this yearly time for everyone to focus on prioritizing wishes, the wishlist takes on some similarities to an endless backlog. –Novem Linguae (talk) 08:57, 28 May 2026 (UTC)

So I think, sensibly, #3 as stated is unnecessary. We can have an annual managed event surrounding the current mechanism. If BOLD applies here on Meta too. :) We could even make it semiannual, or whatever frequency we desire. Of course, this doesn't make wishes get worked on efficiently, but it could attract better ideas and discussion, and keep the wiki movement's eye on what can be done here any time of the year. I think we agree on the bottom line that we cannot let the Wishlist fade away from inattention and non-use. StefenTower (talk) 20:09, 28 May 2026 (UTC)

What do you see as the solution to the wishlist growing constantly? It makes it less exciting for people to vote if they have to go through a long list of accumulated unpopular wishes. The good ones get picked up, the other linger making the list worse each year.

When we had the yearly list, I was excited to go through all wishes, point editors to existing solutions if their wish already existed, and vote. I no longer find that worth my time. —Femke 🐦 (talk) 20:56, 28 May 2026 (UTC)

Since the wishes are sortable by create date, if we had an event, you could just look at the new ones. Also, you can use the Statuses filter to keep certain items like "Done" or "Long term opportunity" off your view. Maybe there's further usability changes to the mechanism we can push as well. StefenTower (talk) 06:42, 29 May 2026 (UTC)

If we were to reintroduce the annual survey, what lessons or learnings from previous years should we keep in mind? For the submission of wishes and voting, do we see this working exactly as it was prior to becoming a continuous system? I understand that the execution / fulfilment side of it is intended to be different, and agree that we can definitely do more advertising. SCherukuwada (WMF) (talk) 21:40, 28 May 2026 (UTC)

@SCherukuwada (WMF): The non-negotiable part for me is that voting needs to be annual and we need a return of a similar user interface where folks can click on specific categories to view wishes and can subsequently support or oppose a wish. Wrt to the "community proposes wishes", I do think a well advertised explicit wish solicitation period is a must. That being said, I do think Femke and Asilvering have strong opinions on this as well (and I'd invite other folks to comment)! Sohom (talk) 17:14, 29 May 2026 (UTC)

My strong opinions are less about how to solve the problem (eg, an annual vote) and more about what is obviously wrong, which is the total collapse in editor participation in the wishlist. The annual process had a lot of buy-in. Editors participated, submitted wishes, voted, etc, and had the clear expectation that the top wishes would be worked on. The WMF could demonstrate commitment to community needs by fulfilling those top wishes. Most wishes under the current system receive effectively no participation and are not fulfilled. The obvious conclusion for any editor to make is that participating in this process is not worth their time and they are simply casting their wishes into the void. Meanwhile, the WMF has no realistic way to demonstrate commitment to community needs by fulfilling these wishes, since they are so numerous that most editors' wishes will never be worked on. Unless they're really quite extraordinarily lucky, any editor is likely to come out of this process feeling alone, dispirited, and ignored - even if the WMF is actively completing very many wishes. Even if by some metric productivity went up in this model, no one gets to feel happy about it. asilvering (talk) 22:31, 29 May 2026 (UTC)

I agree with Sohom that the annual voting is a must, and that we should go back to a system with clear categories as the primary navigation system. The annual vote gives wishes the same chance to be seen, and brings communities together to talk about our joint needs. I also think that an annual wish reset is necessary, either in terms of the old system (a short period each year in which you can submit wishes), or a system where you can start submitting wishes from early January with a more well-advertised wish solicitation period just before voting opens. The reset of wish intake is necessary to ensure that the wishlist doesn't become a sprawling list of unpopular wishes that never made it, or so big that nobody wants to engage. —Femke 🐦 (talk) 18:27, 29 May 2026 (UTC)

I agree with Femke's comment. She does a good job of explaining some of the "why"s. With that in mind, returning to the "old wishlist" model with minimal changes is what I'd recommend. The biggest change should be a switch to using mw:Extension:CommunityRequests, which was written recently. However, if needed, the extension should be modified to support the behaviors and architecture of the old wishlist. Other than that, try to copy the old wishlist as closely as possible. It's just like a wiki page: if a change isn't good (in this case we changed the wishlist and editor engagement went down 92%), revert to a known good version. Hope that helps. –Novem Linguae (talk) 10:36, 30 May 2026 (UTC)

Makes sense. Would it be easier if we moved this to Phabricator to continue to capture concrete actions? SCherukuwada (WMF) (talk) 11:30, 30 May 2026 (UTC)

Phab is a high barrier of entry and would restrict community participation even futher. asilvering (talk) 12:00, 30 May 2026 (UTC)

Fair point. if one were to summarize the suggestions being proposed and dive deeper into some pros and cons, what forum would you recommend? SCherukuwada (WMF) (talk) 16:30, 30 May 2026 (UTC)

I think using Phabricator to plan the details of agreed to, actionable things is fine. I've gone ahead and created a couple tickets so we can start hammering out technical implementation:

• phab:T427719 - Change Wikimedia wishlist homepages to de-emphasize focus areas in favor of ranked individual wishes and wish categories
• phab:T427721 - Pick a 2026 date for all wikis to vote on wishes, then market it

I think anything not yet agreed to, still vague, or in the brainstorming page should probably remain on wiki for further discussion. –Novem Linguae (talk) 20:06, 30 May 2026 (UTC)

The discussion has grown too wild regarding formatting and link rabbit holes that it took me quite some minutes to even understand what it was about. In relation to that unfortunately I don't have much to add. Things are simple: Let people express wishes simply and make those wishes come true. If we/WMF can't handle that for some reason, don't have a wishlist. We already have Phabricator for bugs and features. We already have Gerrit for volunteering Mediawiki patches. Local admins already can make JS scripts to handle their own communities local problems. A wishlist therefore supposedly should exist to close gaps that the aforementioned places and functionalities can't properly reach and that is mostly about "niche" things on the server side preferably handled by WMF dev staff. For everything else already exist places where one can "express their wish". Personally I've spent quite some emails discussing with the original team that designed the current wishlist. Then I've been involved in quite some discussions here regarding its features. Now quite some time has passed and we are still discussing about the basics or even scrapping the whole process and restructuring it from the start again. Whatever design we choose, if there is no guarantee the staff behind it can handle the requests in a timely manner, the wishlist is useless in my eyes. - Klein Muçi (talk) 21:48, 27 May 2026 (UTC)

A wishlist therefore supposedly should exist to close gaps that the aforementioned places and functionalities can't properly reach and that is mostly about "niche" things on the server side preferably handled by WMF dev staff. In particular, I think the wishlist can be a good way to get big software projects worked on, such as a new MediaWiki extension. This is a gap that cannot be covered by volunteers (both for volunteer time reasons, and because each MediaWiki extension needs to be sponsored by a WMF team to get approved). –Novem Linguae (talk) 09:00, 28 May 2026 (UTC)

As I already mentioned in previous discussions on this page, turning the Community Wishlist into a wrapper around annual plans is a mockery of the community. Considering that it is unclear how the WMF defines its priorities and how, for many years, it has ignored technical debt and improvements necessary for editors’ actual work, the more I read this discussion, the less I believe that the dismissal of the team working on the Wishlist is in any way connected to improving the Wishlist itself.

Instead of focusing on the globalization and long-term development of tools and accumulated experience, the WMF constantly jumps from one new tool to another, leaves them unfinished, and then abandons them. And no annual planning process is going to solve that. Iniquity (talk) 17:54, 28 May 2026 (UTC)

I'm not so sure that last bit, about planning, is true. Certainly, if annual plans every year prioritize the New Cool Thing, the problem continues. But that's not a problem with planning in general, it's a problem with the specific plans that have been made to date. And that can be changed, going forward. (Instead, we got Abstract Wikipedia. Alas.) asilvering (talk) 18:13, 28 May 2026 (UTC)

Yes; I agree with much of Iniquity's diagnosis of the problem, but I think no annual planning process is going to solve that goes in the wrong direction for the treatment: a different annual planning process may be the only way to solve an organization that points its big-picture, large-scale priorities in the wrong direction. Certainly I don't see how an organization could, e.g., identify and resolve technical debt without a plan to do so.

The hard part of the problem is having an annual planning process that can robustly help the org distinguish between things like VisualEditor (which caused outcry when released in an incomplete state, but which I think was obviously worthwhile in the long run) and Abstract Wikipedia or the Knowledge Engine (which, I'd argue, caused outcry because of a genuine mismatch in core priorities between grantmaking orgs and the wiki community).

Then again, it may be wrong the point to the Annual Plan in this case, since laying off experienced developers is directly counter to that fourth "Enable" goal to "Build speed and resilience: Support the people and systems behind this work." And building tools to improve the actual editing experience is a pretty good way to "Deepen engagement: Support our contributors and turn casual readers into repeat readers, editors and donors." LEvalyn (talk) 23:11, 28 May 2026 (UTC)

MediaWiki development is fairly straightforward to separate from new projects. I think the organization needs to re-assess how much it allocates to supporting MediaWiki, versus other initiatives. I don't agree with those who say the WMF should only focus on specific core services (some go as far as to say that the WMF should just keep the servers running). Planning for future directions and supporting relevant research is important for the long term. But as others have stated, there is room for more investment into MediaWiki. isaacl (talk) 23:27, 28 May 2026 (UTC)

"some go as far as to say that the WMF should just keep the servers running" - to be honest: has MediaWiki changed that much in the past, say, 10 years? What specific things would we lose if we were still running MediaWiki 1.28 with just the security fixes and under-the-hood stuff (Parsoid, moving edit section links out of headings, using <figure>s instead of <div>s for files, etc.)? ~2026-32241-35 (talk) 20:53, 29 May 2026 (UTC)

A lot, just the words with security fixes is doing a fair bit of heavy lifting since that would require that WMF fork and maintain a EOL version of PHP and MySQL for 10 years with zero external support alongside making security fixes to MediaWiki. Sohom (talk) 21:48, 29 May 2026 (UTC)

We would lose, in addition, all the development; a WMF that keeps the servers running and nothing else is one that completely ignores the community's needs and also the changing landscape of the internet (AI, scrapers, mobile browsing, etc etc). asilvering (talk) 04:28, 30 May 2026 (UTC)

External/news/press attention related to the wishlist changes/CommTech lay-offs

• Hundreds of prolific Wikipedia editors are threatening to go on strike (The Verge)
• Hundreds of Wikipedia editors are threatening to go on strike and the reason is these engineers (The Times of India)
• Wikipedia’s Volunteer Army Threatens Strike Over Foundation Power Play (Gadget Review)
• Wikipedia’s Volunteer Army Is Threatening To Walk Out — And The Internet Should Be Worried (Baller Alert)
• Wikipedia editors plot strike and banner sabotage after Wikimedia layoffs (The Register)

(feel free to add more; these are just a few that I'm aware of, and I can't see any linked above so far) ‍—‍a smart kitten_[meow] 11:45, 30 May 2026 (UTC)

May 29 update

I’m very glad to hear that two of the employees have already been re-hired. However, it concerns me that we have had no confirmation that there were at least six suitable open positions at the WMF. This suggests that the WMF has not addressed the community’s most central concern, namely, the retention of staff with extremely specialized technical and community knowledge. Are there available positions for the other employees? LEvalyn (talk) 20:10, 30 May 2026 (UTC)

A voice of modest experience

Came here because of the Register report, and because I experienced exactly this once.

Was part of a team developing an innovative business function. After a few years, it was deemed that our work now bore on everybody else's responsibilities, it was going mainstream and we were not well placed to scale. So we were dissolved and our skills scattered across other areas most desperate for them, often disguised as some existing role because bureaucracy.

Was both good and bad. Everybody got to integrate our innovation in their workstreams, and faster, but without central coordination some did better than others. Corporately, it was a kind of a "move fast and break things" effect.

My recommendation would be to find mainstream roles for most of the team, where they can keep pushing the wishlist agenda from seats within the teams who are building them in, but keep a core management role, perhaps a couple of folks no more, who can continue to prioritise and coordinate wishes, offer training support, etc. Don't let people go if you cannot find another place for them, as it undermines the capability you are rolling out and is self-defeating. Keep them in the old team until you can move them.

Anyway, whatever happens, I hope the outcome is good. Steelpillow (talk) 21:19, 30 May 2026 (UTC)