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 3

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

11 September 2026

			22:49		Talk:Community Wishlist/Community Wishlist 2027 3 changes hist +1,694 [Thryduulf; StefenTower; Femke]
					22:49 (cur | prev) +1,072 Thryduulf talk contribs (→Stage 2: Voting: disagree rather than oppose?) Tag: Reply
					20:20 (cur | prev) +347 Femke talk contribs (→Stage 2: Voting: Reply) Tags: Mobile edit Mobile web edit Advanced mobile edit Reply
					18:27 (cur | prev) +275 StefenTower talk contribs (→Stage 2: Voting: Reply) Tag: Reply

10 September 2026

12:46

Talk:Community Wishlist/Community Wishlist 2027 diffhist +400 Femke talk contribs (→Stage 2: Voting: re)

			09:31		Talk:Community Wishlist/W572 4 changes hist +1,446 [PFischer-WMF (2×); Nardog (2×)]
					09:31 (cur | prev) +137 Nardog talk contribs (→Note)
					09:28 (cur | prev) +311 Nardog talk contribs (→Note: Reply) Tag: Reply
					08:46 (cur | prev) +173 PFischer-WMF talk contribs (→Note: added note regarding new redirect keywords)
					08:42 (cur | prev) +825 PFischer-WMF talk contribs (→Note: Reply) Tag: Reply

9 September 2026

			20:14		Talk:Community Wishlist/Community Wishlist 2027 5 changes hist +2,792 [Femke; SPerry-WMF (4×)]
					20:14 (cur | prev) +234 Femke talk contribs (→Questions for the community: Reply) Tag: Reply
					19:57 (cur | prev) +1,404 SPerry-WMF talk contribs (→Status labels and definitions: Reply) Tag: Reply
					19:45 (cur | prev) +31 SPerry-WMF talk contribs (→Status labels and definitions: Updated label with new text for clarity)
					01:43 (cur | prev) +593 SPerry-WMF talk contribs (→Potential timeline: Reply) Tag: Reply
					01:27 (cur | prev) +530 SPerry-WMF talk contribs (→Stage 2: Voting: Reply) Tag: Reply

			12:05		Talk:Community Wishlist/W497 2 changes hist +922 [Samwalton9 (WMF); Ladsgroup]
					12:05 (cur | prev) +436 Ladsgroup talk contribs (→Update from WMF: Reply) Tag: Reply
					11:14 (cur | prev) +486 Samwalton9 (WMF) talk contribs (→Update from WMF: Reply) Tag: Reply

N    11:11

Talk:Community Wishlist/W565 diffhist +757 Samwalton9 (WMF) talk contribs (→Learning more: new section) Tag: New topic

8 September 2026

			16:55		Talk:Community Wishlist/Community Wishlist 2027 6 changes hist +3,495 [Femke (6×)]
					16:55 (cur | prev) +978 Femke talk contribs (→Stage 3: Post-vote: my 2c)
					16:42 (cur | prev) +224 Femke talk contribs (→Stage 4: Implementation: makes sense)
					16:38 (cur | prev) +512 Femke talk contribs (→Potential timeline: Reply) Tag: Reply
					16:34 (cur | prev) +365 Femke talk contribs (→Stage 2: Voting: Reply) Tag: Reply
					16:31 (cur | prev) +323 Femke talk contribs (→Status labels and definitions: Reply) Tag: Reply
					16:29 (cur | prev) +1,093 Femke talk contribs (→Stage 1: Triage: Reply) Tag: Reply

Archives

---

1, 2, 3

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)

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)

Hi @Klein Muçi - thank you for your feedback!

In our update for April, we did point out that, while the number of long-term opportunities went up from 204 to 210, the number of prioritized wishes also went up by the same amount from 15 to 21. We continue to work through new and old wishes to see how they may fit into team plans - whether existing plans or new efforts.

Recently we also started highlighting more wishes that other teams are working on, so this could also be a perception that more wishes align with existing annual priorities.

Note that since the wishlist is now open all year around, we have to balance incoming requests with annual plans that are already in flight.

You can see a full list of everything that is prioritized or in progress, which continues to evolve every month and we have publicized our general guidelines to how to get more wishes prioritized. MikeZ-WMF (talk) 13:37, 1 June 2026 (UTC)

@MikeZ-WMF: the number of prioritized wishes also went up by the same amount from 15 to 21 This is a meaningless metric. "Prioritized" does not mean "will be worked on". I spent the last week looking at the "in-progress" and "prioritized" tasks and my assesment is that even for the "In progress" stuff a lot of them lack a clear owner or any direction. To give you a few examples, who exactly owns Image Editor for Commons (Community Wishlist/W298), A way to see why a file is somewhere underneath a specific category (tool to show cat-path) (Community Wishlist/W393), Special pages should have language links (Community Wishlist/W385), Make the Chart extension beginner-friendly (Community Wishlist/W414), In the Global Watchlist, move buttons first like in normal Watchlists so their locations don't vary (Community Wishlist/W459), or An annotation tool (Community Wishlist/W416) ? Sohom (talk) 14:05, 1 June 2026 (UTC)

Also, @MikeZ-WMF the prioritization metrics are extremely flawed since (a) it assumes familiarity with OKR metrics (which I strongly believe the average person putting in a wish should never have to know) (b) it deprioritizes almost everything else that is not already a OKR, since the community will typically not report "Unbreak Now!" requests through the wishlist that has a reputation of taking one fiscal year to deliver tasks. Sohom (talk) 14:35, 1 June 2026 (UTC)

I think there is a consensus against the usefulness of the 'how to write a good wish' page: it's unreasonable to ask people to read jargon-laden OKRs, the prioritisation is ad hoc and not designed with communities, and people generally believe a problem-led approach reduces the influence to steer decisions and leads to overly vague wishes. It might be best to delete the page while a more community-centered approach is designed. —Femke 🐦 (talk) 07:36, 2 June 2026 (UTC)

Couldn't agree more. That page is about how to write a wish that reads good to staff tasked with triage, not even to developers. To fellow wishlist participants it might as well be named how to write a bad wish. Nardog (talk) 11:22, 2 June 2026 (UTC)

Whew. If the Community Wishlist can't settle down, I'm losing interest in any participation, fast. I'm just one community member, of course, but I seriously feel like I'm being jerked around (not just by yourself, but this whole shebang). There's no reason we can't use the current system with perhaps a few tweaks. Waiting who knows how long for yet another new one is bollocks. I am pretty much decided to completely give up, and just use other approaches for making positive change in Wikipedia. In fact, that's been my approach for a while anyway, including making some things myself. The wishlist may as well be a fairy tale turned into a nightmare where you can have good ideas but get mostly ignored, and when not ignored, having ideas opposed by people who don't know what they're talking about. Meanwhile, in reality land, I can get stuff done without this mess. Unless this all settles down, bubbye. StefenTower (talk) 22:57, 2 June 2026 (UTC)

@Sohom Datta

Please wait for the next monthly update since we aim to include highlights based on those "prioritized" and 'in progress" wishes. You're also welcome to engage in Phabricator tickets that are listed, where possible.

As far as OKR related metrics - please remember that these are just one factor out of many that have been listed in the table. All the other factors have their weight and in the end OKR metrics are also related to community needs. When wishes aren't related to OKRs, they can and are still prioritized thanks to other factors such as non-core metrics, severity and scope. MikeZ-WMF (talk) 15:46, 8 June 2026 (UTC)

Hello, @MikeZ-WMF!

Thank you for your detailed answer!

Unfortunately that is more or less what I've stated in my feedback just using other words. What you've described is what feels a bit disappointing to me as it leans further and further more towards bureaucracy. At the risk of being called a parrot, I'll repeat We already have Phabricator. Based on the name, the Wishlist was supposed (maybe, wrongly so, only by me) to be different in these aspects.

One writes a wish, it gets fulfilled, they're eager to write more wishes.

One writes 3 wishes (after having to read the guideline). They are sent through different hooks and loops and get lost in tech-limbo. They likely won't write further ones.

Is "more people writing more wishes" necessarily/inherently good? It's not. But if we agree to have a Wishlist - a non-stop one, non the least - then we've already made the choice. After that choice is made, extra steps that limit it feel counterintuitive to the supposed purpose of it. Klein Muçi (talk) 10:42, 2 June 2026 (UTC)

@Klein Muçi

Thank you for the feedback. We're taking all your opinions into consideration as we think of new ways to restructure the wishlist. You can follow the Updates page for announcements on changes to the process. MikeZ-WMF (talk) 15:48, 8 June 2026 (UTC)

@MikeZ-WMF can you or Suman or someone explain what the Foundation sees as the purpose of the Wishlist? Because if it is "a forum for Wikimedia project contributors to share ideas or "Wishes" aligned with strategic goals targeted through the Annual Plan to improve our product and technology, and then collaborate with each other and the Wikimedia Foundation to prioritize and solve these opportunities together." I think there is a large chance that this is just a continued fundamental mismatch with what the community sees as the purpose of a Wishlist, with that being something much closer to "proposals for features and fixes that you'd like [the WMF] to work on" to use wording from the Wishlist Survey. Best, Barkeep49 (talk) 23:11, 9 June 2026 (UTC)

Hi @Barkeep49

I will cite the original text that was there before the user edit that added the line about the Annual Plan (I thought we had reverted mentions of this, e.g. here):

The Community Wishlist is a forum for Wikimedia project contributors to share ideas or "Wishes" to improve our product and technology, and then collaborate with each other and the Wikimedia Foundation to prioritize and solve these opportunities together.

We do indeed prioritize wishes that have nothing to do with the Annual Plan. They just shouldn't run so contrary to the plan that we erase with one hand what the other writes. For example, the current year's plan says the newcomer mobile edit abandonment rate should go down, so we shouldn't implement wishes that may cause the rate to go up. We haven't declined anything for this reason since last November and we will be more detailed if it comes up again.

We'll also work on rewriting this cited text with examples as ongoing threads coalesce, so thank you for flagging it. MikeZ-WMF (talk) 14:52, 11 June 2026 (UTC)

Thanks for this clear response. Best, Barkeep49 (talk) 14:55, 11 June 2026 (UTC)

Thanks for sharing all this helpful feedback! @MikeZ-WMF is absolutely right that we need to ensure we don't prioritize work that erases or clashes with other prioritized work. I believe one of the most important proposals mentioned in Marshall's post from last week is that we make sure that highly-voted wishlist work gets resourced, regardless of how well it is aligned with our annual plan. Of course that doesn't mean we can blindly work on any top voted wish -- some of them might simply not be technically feasible for example. This is a strong deviation from how the wishlist process worked over the last couple of years and I believe this deliberate delineation between wish work and strategic work is needed to make the wishlist successful again. That being said, if a highly voted wish goes entirely against our strategic goals, even contradicting them, there is a bigger discussion to be had to understand where that discrepancy comes from. It could be that we didn't factor everything into our strategic plans, in which case we should take another look at them to understand how our approach can be better aligned with community expectations. Or it could be that we had considered the contrary approach and dismissed it because we have data to support that its implementation would do more harm than good. Or maybe something else. Either way, if that happens I believe we need to have a conversation about it. That's where I think the proposal of having a working group (including community members) could be really helpful. Do you all have any ideas what shape this working group could take and how we could determine who should be included from the community? SPerry-WMF (talk) 16:45, 26 June 2026 (UTC)

Oh, and I realized I haven't posted on this page yet, so I should have introduced myself -- I'm Sonja and I lead the teams responsible for the contributor experience here at the Foundation. SPerry-WMF (talk) 16:47, 26 June 2026 (UTC)

@SPerry-WMF: In that case, can we start by reopening the wishes declined as contrary to strategic priorities (as community opportunities)? It never made sense (as it prevents those wishes from being voted on) and still doesn't. Nardog (talk) 03:42, 30 June 2026 (UTC)

That makes sense to me, though I would say that now may not be the right time to do that just yet, because we're still figuring out some open questions around the new process, like whether the wishlist should remain open for submission year round and what happens to wishes that are not prioritized. We plan to answer these questions together with the community in the coming couple of months, so if you have thoughts on those, please share them here. That being said, when we do open voting for the annual vote we're proposing to happen this year in October/November, I agree with you that it would make sense to open the wishes that were previously declined as contrary to strategic priorities so that they are included in the voting. Some of them may have multiple reasons for having been declined, so we may need your help to figure out which would be important to bring back. SPerry-WMF (talk) 17:20, 30 June 2026 (UTC)

I did that figuring out above in #Refocus. TLDR I would re-decline W334 and W121 and reopen the others. * Pppery * _{in solidarity} 00:17, 1 July 2026 (UTC)

If you submit any wish, however ridiculous or inappropriate, it can be voted on right away right now. As can be any wish that may or may not be included in the proposed annual voting. So if you're not reopening the wishes declined as contrary to strategic priorities now, that should mean you think they should not be voted on unlike all the other undeclined wishes for now. But you haven't articulated why. If you find any other reason to decline any of them, you can do so at any time, stating that reason in {{Community Wishlist/Decline}}. It's not just about what would make sense if an annual voting were to take place, but about what makes sense and what doesn't right now. Nardog (talk) 05:17, 1 July 2026 (UTC)

Thanks, both! One of the big things I've taken away from discussions with the community over recent weeks about the wishlist is that the current prioritization process doesn't match community needs and expectations for the wishlist, so opening these wishes now for voting just wouldn't change much, I think. It makes more sense to me to wait until the new process is in place, ideally in October or November this year. That way we could include these wishes in a voting and prioritization process that the community helped define. SPerry-WMF (talk) 20:48, 2 July 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)

@Snævar I definitely know about this, what does this mean when Group1 gets 75% of the wishes and group2 gets 25%? ~2026-33106-46 (talk) 05:53, 5 June 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)

So far:

Watchlist expiry, watchlist labels -> moderator tools

w:Wikipedia:Article wizard was never maintained by commtech but instead by the enwiki community. mw:Extension:ArticleCreationWorkflow, which is not the same thing, is now being maintained by LPL

TemplateWizard is now being maintained by editing team

CopyPatrol, who-wrote-that, and Xtools are now being maintained by moderator tools

About a dozen tools still need new maintainers, more than a month in.

— The preceding unsigned comment was added by Pppery (talk) 01:07, 30 June 2026 (UTC)

June 5 update

Thankfully, three former CommTech members will be able to keep their WMF careers/jobs. However, still awaiting fate of three others.... (If the other three can keep their jobs, then I can forego the idea of a Meta-Wiki RFC on campaigning to rehire one of them.)

Nonetheless, saddened that focus areas process was botched and then abandoned per community feedback. Will individual rankings replace the "focus areas"? If not, then what else will replace the "focus areas"? I can image something of blend of "focus areas" and "individual rankings", but that's my speculation. George Ho (talk) 05:17, 9 June 2026 (UTC)

This information shouldn't come from me, but it is my understanding that the remaining three CommTech members have said their goodbyes. In that sense, it's likely there will be more delays on current wish work / gaps in maintenance knowledge. —Femke 🐦 (talk) 07:23, 9 June 2026 (UTC)

As I see, Karolin Siebert and Dayllan Maza are tagged recently by TheDJ as no longer employees. Haven't seen their public statements to us the community yet. Can't find the third person out yet. --George Ho (talk) 14:38, 9 June 2026 (UTC)

@George Ho I've determined this based on their Phabricator accounts getting disabled this week. I'm sure without me, someone from WMF would have done it later this week. The third person would be HMonroy it seems (which I guess I forgot to save the edit for, now tagged as well). —TheDJ (talk • contribs) 08:10, 10 June 2026 (UTC)

Thanks for the heads up. I don't wanna campaign to have them three rehired yet. First, we'd still like to hear statements from these three about recent events affecting not just them but us as well. How long shall I await their statements until I'm ready for the Meta-wiki RFC on these three? George Ho (talk) 08:36, 10 June 2026 (UTC)

Have you considered these three have different things to do than worry about than what we’d like from them ? —TheDJ (talk • contribs) 08:52, 13 June 2026 (UTC)

┌──────┘
Even their being busy IRL still hasn't eased my concerns about the Wishlist without these remaining three (now tagged as "former") and tech management without these three. Dunno how skilled the three had been, but the three were part of now-defunct Community Tech. Well, "Community"....

Anyways, I'm also worried about either a supposed AI project or even twenty more new tech engineers inadequately replacing them, but I can stand corrected about the "inadequate" part. Speaking of AI, I'm unconvinced that even having more power or even more "man"-power would properly manage an AI project. How can a nonprofit organization like the WMF be able to well manage what Big Tech companies have done or what other AI-focused companies have done or failed to do? —George Ho (talk) 15:57, 13 June 2026 (UTC)

It looks like this saga has been successfully contained, despite not reversing the decision and failing to comply with even the first and most basic step. Kowal2701 (talk) 05:20, 10 June 2026 (UTC)

Please explain/expand on the word contained — GhostInTheMachine ^{talk to me} 07:16, 12 June 2026 (UTC)

I received an email telling me to reconsider the idea of campaigning because it may affect the odds of an (ex-?)employee from being rehired. I won't reveal the email recipient sender, but I can't help wonder whether that person has point in all of this. Perhaps I'll await the statements from those (ex-?)employees indefinitely, so I won't rush into making a Meta-Wiki RFC at this time. --George Ho (talk) 17:53, 12 June 2026 (UTC); self-corrected, 15:20, 13 June 2026 (UTC)

the email recipient That was you, you probably mean the sender? --Matěj Suchánek (talk) 08:52, 13 June 2026 (UTC)

Whoops. Thanks for pointing my err. —George Ho (talk) 15:20, 13 June 2026 (UTC)

Questions for community

Hello! Today, I posted an update with proposals for how we're thinking about the wishlist going forward, made along with discussion with a group of users with extended rights. We hope to hear from volunteers on what you think of those proposals, and also of these open questions in the update:

1. Sometimes there are multiple wishes that are related to each other, or especially large wishes. These might indicate some important area that requires major investment for editors. An example is the Page Curation and New Pages Feed improvements from the 2019 wishlist, which constituted substantial upgrades to that system. How might the wishlist help surface those major areas?
2. In the past, the wishlist tried various approaches to make sure that wishes from sister projects and smaller languages were prioritized.  How might we make sure that smaller projects and languages get attention?
3. Although it is crucial to have a period of high visibility for soliciting wishes and voting, would it be good to still allow submitting wishes year-round, so that when people have ideas/needs, they can submit them instead of needing to remember to do so months later?
4. Past wishlist years have used various systems for determining exactly which highly-voted wishes are prioritized, and have taken into account aspects like the size of the wish and how to serve smaller projects and languages. We’re still thinking about what would work best going forward and want to hear your thoughts.

Thank you! MMiller (WMF) (talk) 20:21, 17 June 2026 (UTC)

Personally, I think it is a good idea to collect wishes throughout the year, managing them as appropriate (de-duplication, combining similar ideas, and so forth), and then feeding them into the annual publicity cycle for broader feedback. isaacl (talk) 22:33, 17 June 2026 (UTC)

You state "To make sure we’re dedicating sufficient resources toward wishes, we’ll look at past wishlist years and plan to accomplish similar amounts of wishlist work in upcoming years (with the knowledge that wishes vary in size)." However we have previously been told "As I shared in my original post, the decision about the Commtech team and the Community Wishlist was made to help WMF more effectively address wishes by having more teams work on them. We ask that you judge the impact of this change based on how well and how many wishes we are able to support in the coming months.. It also seems odd to be claiming to be eliminating a bottleneck while having a success metric of no worse than previous.Geni (talk) 04:23, 18 June 2026 (UTC)

Thank you, @Geni. I think you're right. As the wishlist becomes a program accomplished across multiple teams, we plan to accomplish wishlist work better. But I'm not sure whether to say "more wishes" or "larger wishes" or "faster completion" -- because depending on the wishes that come in and the needs of the community, the improvements here might manifest on any of those dimensions. In some years in the past, the wishlist had goals around the number of wishes completed, but that doesn't take into account the size of the wishes. So yes, I should say "more wishlist work in upcoming years" -- just still figuring out how much more that will be and the right way to evaluate that. Do you have ideas on how to think about this? MMiller (WMF) (talk) 14:29, 18 June 2026 (UTC)

I would consider the we'll look at past wishlist years and plan to accomplish similar amounts of wishlist work in upcoming years plan to be much more doable than any pie-in-the-sky promise of higher throughput. We are at very much back at "prove this non-CommTech model works at all" (taking 2017-2019 wishlist as a benchmark) and I'd consider exceeding that a stretch goal at this point. Sohom (talk) 16:24, 18 June 2026 (UTC)

Past wishlist years have used various systems for determining exactly which highly-voted wishes are prioritized, and have taken into account aspects like the size of the wish and how to serve smaller projects and languages. The naive approach would be to include atleast one wish (the top voted one?) as part of the prioritization process? Sohom (talk) 16:33, 18 June 2026 (UTC)

Although it is crucial to have a period of high visibility for soliciting wishes and voting, would it be good to still allow submitting wishes year-round, so that when people have ideas/needs, they can submit them instead of needing to remember to do so months later?

Yes, and I suggest you allow voting year-round as well, or at least "reserving" a vote year-round that will go live once the period of high visibility starts. The arduousness of going through a large list of wishes during a small period of time was the reason I gave up on participating in the wishlist after learning about it for the first few years. Nardog (talk) 06:40, 19 June 2026 (UTC)

One of the main complaints I had in the past about this Community Wishlist was, that it was only done by the small team, while the masses of devs still wasted ressources on unwanted bling like FLOW and such. Wishes were denied, because they were too big instead of giving them as #1 priority to the other devs.

This was the community wishlist, thus should have been the main source of work for the complete dev-workforce, the community pays for with their voluntary work, that generates the donations.

So if the new process would now determine the priorities for the whole dev-workforce, not just some ivory-tower nonsense like FLOW, that would be some mayor progress. Grüße vom Sänger ♫^(Reden) 07:31, 19 June 2026 (UTC)

• There are two ways to highlight these bigger areas: as part of the deduplication effort, links to related wishes are added (quite time-consuming, even if many wishes will not have links). More effective is likely to look at the top-10 wishes, and find related wishes in the top-50 or top-100 or so that can be tacked on.
• A simple rule would be to choose at least one wish per year, with every 3th year possibly a wish from the truly small wikis. My suspicion is that Commons has the most urgent work that their small community won't get high on the wishlist.
• I don't mind wish input being open all year. It will make it more difficult to deduplicate wishes as you'll likely have to read wishes multiple times, so it's a less efficient system, but might surface slightly better wishes. Voting should definitely not be open all-year, as it'll give unfair advantage to early wishes.
• I see two options here too: (1) go back the old old system, and just focus on top-10. (2) Make us vote not only on whether we like a wish, but also on how big an impact we think it'll make. The final scoring could be 70% raw wish, 30% impact score. That way, we can focus the community towards even more impactful wishes, aligning better with the WMF desire to do big things in this challenging time period. That systems might generate more buy-in for the wishlist within the WMF, alleviating my concerns that there is a threat of the wishlist disappearing completely in a few years. As I said privately, I think that might be so demoralising to the community, that we lose the minimal viable community size. —Femke 🐦 (talk) 07:52, 22 June 2026 (UTC)

  Thanks @Femke. Regarding how to identify impact -- I'm not sure how to vote for impact separately. Maybe the way to do it is by limiting the number of votes people have (e.g. everyone gets three votes), so that people are incentivized to choose the most impactful wishes for them, instead of vote equally for every wish that they like. This sort of sounds related to what @Nardog was talking about above -- Nardog, what do you think? MMiller (WMF) (talk) 18:31, 22 June 2026 (UTC)

  I was thinking of giving an optional 1-5 impact score in addition to the normal vote. I dislike a maximum number of votes, because that makes the system of voting less efficient. Normally, people will look a wish, vote or not vote, and move to the next one. With a maximum number of votes it becomes some kind of complicated game, where you have to go back on your votes, without solving a clear issue.

  The problem I'm trying to solve is one to get more buy-in at WMF. We still don't know why the decision was made to disband CommTech, but my guess it was a perception of lower impact, in combination with ignorance of CommTech's impact (at least, those are the two good faith options). People in the community disagree, as CommTech has built a very large share of the tools we use every day. So to some extent this is a question for you; is there a perception that the wishes were not sufficiently impactful? —Femke 🐦 (talk) 18:47, 22 June 2026 (UTC)

  @Femke -- your point about voting efficiency makes sense to me -- yes, it would be hard to keep a mental tally of your favorite wishes and then return to them to vote.

  The reason I am interested in identifying high impact wishes is because many Wikimedians seem to agree that this is a moment that requires bold action to sustain our projects -- both from a reading perspective (with pageviews on the decline), and from an editing perspective (with account creations and some other editing indicators on the decline). When it comes to some groups of people -- like readers, new editors, and UWERs -- there are clear needs that make sense to invest deeply in (like mobile apps, edit suggestions, and suggested investigations, respectively). But for experienced editors, since they do so many different kinds of things across so many different projects, it's less clear what might be some areas that we could make large investments in and have a big impact. And if there is something major we can do to level up our experienced editors, I don't want us to never realize it, and instead spend that time doing a larger number of smaller things.

  If what the experienced editor community really needs is a larger number of smaller tools and improvements, then that makes sense, and that's what we'll do. But to the extent that there are areas where we could go deep and make a big difference, I think it would be valuable for us to be able to see and consider it together in the wishlist. An example area that I'm thinking of is edit checks / suggestion mode: there were a handful of wishes over the years that all hinted at similar things -- none of them directly said "Build edit checks", but they said similar edit-check-like ideas in many ways. A couple of example big areas might be "combatting AI slop" or "make it genuinely possible to do experienced editor work on mobile".

  Just brainstorming -- I wonder if there were some way in the wishlist for volunteers to answer the question of: "what do you think is the biggest problem facing the experienced editors?"

  Again, I just want to make clear that I'm not trying to make the wishlist something it's not -- I know how important the many tools are that the wishlist produced in the past, and when more tools like those are needed, they should be priorities. But to the extent that we do need to do something major, I want us to consider it together. MMiller (WMF) (talk) 22:50, 22 June 2026 (UTC)

  As I wrote on Discord:

  Resetting seems such a bad idea. One of the improvements of the new wishlist is that we don't have to keep coming back to the same wish year after year. And now I don't have to strategically not vote for wishes I nonetheless would like to become a reality because I care more about others.

  Instead have a separate voting period (a "drive"?) where we vote for wishes we really want to be implemented. (now spitballing:) Maybe we each get 10 or 20 points and get to assign them freely or sth, because one thing the voting fails to measure is how badly we want something.

  I realize this is a crude idea (as I said I was spitballing) but something along the same lines would be nice. Perhaps you get a list of the wishes you've voted for (a badly needed feature anyway!) and you get to "boost" a finite number of them during the drive or something. Nardog (talk) 14:45, 23 June 2026 (UTC)

I’d suggest having one list for Wikipedia (with a focus area and quota for small wikis), and another for sister projects. Btw, why is this taking 3 months? Kowal2701 (talk) 08:14, 22 June 2026 (UTC)

I think the CommunityRequests extension itself can be enhanced further.

Is it possible to separate the Status into Opportunity and Status? Right now it is a mix of both sets (Set 1:Long-Term Opportunity, Short-Term Opportunity Community Opportunity, possibly a "Not considered" for the unassigned after review. Set 2: Under review, Prioritized, Open (new, for Community Opportunities wishes that have no 'owners'), In progress, Done.). It would be great to see what type of opportunities have been completed or in progress at a glance.

Also, at the moment, the extension does not give any way for the community to self-serve on those that are labelled as Community Opportunity currently. There's no easy button or steps to claim the tasks or see who is doing the work currently. Maybe a link between the corresponding phab ticket and the extension if we want to minimise the amount of busywork, i.e. the Assigned To field in phabricator can reasonably be reflected as the current task owner. Robertsky (talk) 19:31, 22 June 2026 (UTC)

Hi @MMiller (WMF):, this is a great update to see, and thank you for tackling this tricky topic. :) The relationship between the community and WMF's technical work is so important, and prioritising fixing things that the community raises as issues is critical. Will this be included as part of WMF's annual plan for this coming financial year? Thanks. Mike Peel (talk) 22:54, 23 June 2026 (UTC)

Thanks, @Mike Peel. Yes, it's a good question about the right way to show how wish work fits with the annual plan. We're thinking something along the lines of listing the wishes we're planning on working on explicitly (i.e. in addition to the OKR work), and also showing the cases where wishes will actually be partially or entirely accomplished by OKR work.

We'll also have a KR that is about running the new version of the wishlist process that will inform the next annual plan (for FY27-28) -- something like, "Run wishlist survey in month X, and determine the wishes that will go into the annual plan).

We'll be posting an update in the next week or so listing the wishes we're planning on doing in the next six months, and those will be the ones that we'll want to show as part of the annual plan.

How does that sound? Do you have different ideas? MMiller (WMF) (talk) 06:34, 25 June 2026 (UTC)

Notes from Wishlist Workshop at Wikimania

Below is a summary of all the ideas that were shared during the workshop I hosted at Wikimania. Thank you to everyone who participated! As a next step, I will work on a proposal consolidating these ideas and other learnings from prior wish years and earlier conversations. Please comment below if I missed anything in the meantime.

What does success look like?

• integrative
• ambitious
• being heard
• empowering
• lots of stuff have been completed and brought up that are serving the intended audience
• unconfusing/clear
• inclusive
• better-maintenance-of-semi-maintained-extensions
• understandable/interpretable
• reasonable

Group A – Wish Triage

General notes:

• Explain the relevant time budget upfront
• Have a committee of community members and staff to do triage
• Keep the overall process simple, responsive, and impactful
• Involve the community and create an open and transparent process
• To make it easy to submit wishes, ask for problems & solutions, and don’t commit to delivering the solution exactly as requested
• Allow both problems and solutions to be presented, and connect solutions to problems during triage
• Connect impossible or bad wishes to problems as well and reframe or offer alternate solutions before voting
• There were some concerns around declining impossible wishes, with the proposal to keep them all open in case someone else ever wants to pick them up / the become possible later
• Consider complexity (keeping in mind new and experienced users)

Suggestions:

• Preliminary effort estimates (T-Shirt sizing)
  • Sizing should be relative, not absolute
• Deduplication
• Clarification & refinement, linking content to other tickets/wishes and explain why it hasn’t been done yet
• Separate wishes by project family
• Group wishes (merge where possible)
• Remove impossible wishes and clearly state why

Group B – Voting

Suggestions:

• Dual voting (do this vs impact, 0-5 range)
• Foundation Tech staff to do technical feasibility?
• Single item voting, not group voting
• Find a way to have more impact for sister projects like Commons
• No exclusion of wiki users with a home wiki that has their own wishlist (like WMDE)
• Annual voting process, widely advertised

Open questions:

• Should the number of votes be limited?
• How do we get people to focus on impact / size?
• What is “impact” anyway? (Personal experience impact vs whole wiki impact)
• How do we increase participation rates?

Group C – Prioritization

Suggestions:

• Small communities should have a way for their wishes to be selected otherwise
• Set a contingent for special interest groups, such as users with extended rights, smaller wikis, Global South etc.
• Categorize wishes by the amount of resources needed for implementation, and then pick the top 5 or 10 of large & small wishes to avoid only having wishes that are easy to implement
• Assign more points to underrepresented groups
• Factor in how long a wish has been an issue
• Rank wishes by votes

Open questions:

• Should impact be a factor? Conflicting opinions:
  • Impact should not be a factor because impact is already determined by the number of votes
  • Prioritize by audience (who is impacted?)
  • Factor impact into voting

Other notes

• Don’t commit to doing X wishes every year only to underdeliver

Again, if you come up with any more ideas, please share them here. SPerry-WMF (talk) 14:27, 31 July 2026 (UTC)

A super late reply, but in our group B, we changed our mind on the dual voting during the discussion already, as suggested impact voting only would convey the same without confusing people as much. With Area C, there is still work to be done on making this a truly community-led prioritization. I can come back in September trying to write a proposal on how this could work, if that works in terms of timeline. —Femke 🐦 (talk) 07:51, 13 August 2026 (UTC)

Thanks, Femke! I've been working on a proposal pulling all these things together as well and hope to be able to post it for community input by the end of the month. So that works great with your proposed timing -- you could share your reactions and feedback to my proposal in early September and potentially offer an alternate proposal as well if you have one. SPerry-WMF (talk) 20:16, 13 August 2026 (UTC)

Community Wishlist 2027 process proposal

A new conversation started about the proposal for the Community Wishlist 2027. Please join! Trizek_(WMF) (talk) 13:13, 2 September 2026 (UTC)