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)

Hello everyone, please note that while this conversation has not yet received a response, CommTech is actively taking notes and will reply. (Feel free to move this box to a less obstructive but visible spot so it can reassure arriving discussants that their concerns are being acknowledged.) Thank you all so much. –– STei (WMF) (talk) 11:11, 22 January 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)

–– 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 and 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 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)

Hello everyone, as usual please know that CommTech is reading your comments and will reply. Feel free to move this box to a less obstructive but visible spot so arriving discussants can be notified. Thank you.

–– 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

Stuck at submitted

May I ask what needs to be done to get wishes like this, this, and this out of the "submitted" status. I responded to your inquiries nearly half a year ago. Nardog (talk) 15:38, 30 January 2025 (UTC)

Hello @Nardog, the wishes need to be marked for translation and then moved to open. I have attended to one. I will see to the others later in the week. Thank you for your patience. STei (WMF) (talk) 19:10, 3 February 2025 (UTC)

That does not answer the question. What about these wishes in particular prevented them from being marked for translation and moved to open while others were? What needs to be done before a wish can be marked for translation and moved to open? Nardog (talk) 02:02, 4 February 2025 (UTC)

There are still many wishes with Submitted status as well as wishes of either status that aren't valid development-related requests – please

1. Check which of the wishes that have been suggested to be archived on their talk pages should be archived (link)
2. Check all nonrecent wishes that still have status "Submitted" and either move them to "Open" or clarify what needs to be done to enable them getting moved or why they haven't (and won't?) be moved (the latter may also need some info somewhere so that users know what the difference is and what that status means or implies)

Prototyperspective (talk) 16:02, 28 May 2025 (UTC)

"Later in the week" is apparently more than six months. Nardog (talk) 08:22, 7 August 2025 (UTC)

Community Wishlist/Wishes/Voice dialing is barely intelligible and the request for clarification on its talk page has not been answered, but it's just been given the open status after a month. Meanwhile two of the wishes mentioned above remain "submitted". Now you're just begging for frustration and distrust. Nardog (talk) 11:04, 8 March 2025 (UTC)

Mention the Community Wishlist on the Main Page

Might the wishlist be mentioned on the Main Page (or other prominent locations in Meta) so more people could be directed here? The traffic seems much lighter than I expected. StefenTower (talk) 22:49, 31 July 2025 (UTC)

The main page of Meta, or another wiki? This is a good idea :) cc @Sannita (WMF) JWheeler-WMF (talk) 19:48, 1 August 2025 (UTC)

Since I'm on Meta, I meant Meta, LOL. But certainly, if this can be placed somewhere in community spaces in other wikis, that should be very helpful for traffic. StefenTower (talk) 20:50, 1 August 2025 (UTC)

It used to be on the Meta MainPage but it's not linked there anymore. Please readd it. A banner in other projects would of course be great but I suspect that's planned for certain phases of the wishlist such as after voting has been enabled or things like that. Maybe a banner for the Wishlist could always show on tech-related Wikipedia pages like en:Wikipedia:Village pump (technical). Many MediaWiki wiki users probably would also be interested and if/once there are categories, on Commons, the category for Commons-related wishes could be linked. Prototyperspective (talk) 10:50, 9 August 2025 (UTC)

@StefenTower @Prototyperspective Hi, thanks for your messages, I'm back from my vacations and I'm currently reading my backlog.

I am in favour of asking to re-add it to the main page, I'm not feeling that bold to re-add it on my own. I will open a discussion later in the day about it, your opinions (and maybe support) are welcome.

As for "advertising" the Wishlist on other project, we do have plans on doing that in several ways in the upcoming months. Not sure some communities will like permanent banners, I was thinking more recurrent Centralnotice + recurrent messages at Technical Village Pumps (or just Village Pumps once in a while). Thoughts? Sannita (WMF) (talk) 09:27, 11 August 2025 (UTC)

I've added the link to Template:Main Page/Core issues and collaboration . Johannnes89 (talk) 11:15, 11 August 2025 (UTC)

I hope that sticks. That's about where I thought it belonged. Thanks! StefenTower (talk) 02:45, 12 August 2025 (UTC)

@Johannnes89 Thanks a lot! Sannita (WMF) (talk) 10:32, 12 August 2025 (UTC)

Sannita, those sound like good ideas. Also, banners and/or userboxes people can put on their user pages would be helpful. And perhaps have an ad in en:Template:Wikipedia ads. No permission is necessary for doing either of those. StefenTower (talk) 02:52, 12 August 2025 (UTC)

@StefenTower I didn't know about the Wikipedia ads template, I'll include it in my avenues as soon as I have a working message for it, thanks a lot, very much appreciated! Sannita (WMF) (talk) 10:33, 12 August 2025 (UTC)

Could there please be a banner on some projects like Commons and English Wikipedia at some point / during some times? One could also limit it to certain types of pages such as showing the banner only above Help pages, Village Pump pages, and other meta pages. Prototyperspective (talk) 22:08, 23 October 2025 (UTC)

@Prototyperspective We have it in our plans to send messages and put up banners to invite people to send their wishes. We're still adapting to the new system, though, so for the time being it might be still early to do so. But yes, we do have plans in this sense. Can I count on your help to set them up, when it will be time? Sannita (WMF) (talk) 11:11, 3 November 2025 (UTC)

Makes sense and sounds great that these two things are in your plans! Would love to help out but in case the help referred to is some kind of software development, I may possibly not help much. In any case, looking forward to this. By the way, I'd propose creating badges for volunteer devs who implement wishes for increasing incentivizes and interest...or more broadly also thinking about how to increase number of valid wishes delivered. Prototyperspective (talk) 12:14, 3 November 2025 (UTC)

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)

Converting wish number to wish title

Is there, or is it possible to create, a template that converts e.g. "W1" to "W1: Stewardship needed for Adiutor MediaWiki extension" or "FA1" to "FA1: Make it easier for patrollers and other editors to prioritize tasks" (or translation thereof in the interface language if available), i.e. equivalent to {Tn} on Phabricator? This seems like an essential feature for the new numbering system to be useful on wiki. Nardog (talk) 13:50, 5 October 2025 (UTC)

@Nardog: That sounds useful. It could be a parser function such as {{#CommunityRequests: wish-link}} and optionally show the current status, or vote count, or other info inline. I've created task T406537. SWilson (WMF) (talk) 02:38, 7 October 2025 (UTC)

I've created {{Community Wishlist link}} (shortcut: {{cwl}}). It's pretty hacky, so the parser function is still needed. Nardog (talk) 09:56, 20 October 2025 (UTC)

A parser function is coming :) I must say though, this is a clever workaround! Thank you for creating it! MusikAnimal (WMF) (talk) 19:41, 23 October 2025 (UTC)

DISPLAYTITLE not working

Hi! I've just created a new wish but the DISPLAYTITLE magic word is not working, I was wondering if this is intentional or maybe has an easy fix, otherwise I'll open a ticket on Phabricator. It's moon (talk) 13:13, 7 October 2025 (UTC)

The extension itself sets the display title (hence why we are able to have the wish title there), so I'm not sure it's possible to override it. For your case, I would just recommend putting quotations around "In other projects" to give it emphasis. Merging a display title defined in the wikitext with our own may be possible, but my guess is it's likely not worth the code complexity. MusikAnimal (WMF) (talk) 16:39, 7 October 2025 (UTC)

No problem, I'll use quotations then. Thank you! It's moon (talk) 00:28, 8 October 2025 (UTC)

FWIW my mere experience of going "huh, I wonder if this is going to work" made me realize how wanting the wish editing experience is (or put another way, how smooth the default wikitext editing is) and submit a bunch of feature requests on Phab. Nardog (talk) 10:59, 8 October 2025 (UTC)

Now that you mention this, I would appreciate a preview button when editing wishes. I'll probably submit that to Phab if you haven't already. It's moon (talk) 11:08, 8 October 2025 (UTC)

A preview would be nice, and should be totally doable. I think we didn't do it before because it, well, was less doable :-P Here in extension-land a lot more functionality is within reach!

Related, you can expect mw:Extension:CodeMirror to make it's way to the wish editor relatively soon :) MusikAnimal (WMF) (talk) 17:41, 8 October 2025 (UTC)

Please link the phab issue if you created it. I also think having the preview function would make editing a lot easier. Prototyperspective (talk) 09:53, 6 November 2025 (UTC)

I've just created the following two issues: phab:T409418 and phab:T409421. It's moon (talk) 11:29, 6 November 2025 (UTC)

Some have supporters already

Some wishes have supporters already, while new wishes are still being added? That creates an advantage for wishes that were submitted early. Polygnotus (talk) 01:23, 22 October 2025 (UTC)

1. Only few people so far are voting 2. Wishes that are not yet accepted but not new have the same disadvantage 3. WMF isn't doing much technical development to implement wishes, even those with the most or many votes so it doesn't seem like there is a big disadvantage 4. New wishes in contrast have the advantage of being show high up in the table. These four points don't fully address your reasoned concern. Prototyperspective (talk) 13:20, 22 October 2025 (UTC)

I for one don't understand why we can't vote for wishes under review. It adds the burden of having to remember or make notes of wishes you intend to vote for. Why not just hide the votes until the wish is accepted... It might even facilitate the review process since the numbers of support votes would indicate which wishes have merit. Nardog (talk) 13:32, 22 October 2025 (UTC)

It is debatable. The idea was to add some barrier before something unwanted gets support-bombed ("Delete this article me and my friends disagree with!"), or should we allow opposes, it'd shield a good-faith proposer with a bad idea from being discouraged to participate again. There is also an undocumented understanding that it shouldn't be marked for translation until "approved", i.e. the wish is understandable, feasible, and technical in nature. The other side of the coin, as you say, is that allowing voting while "under review" would help surface wishes of high interest or ones that should clearly be declined.

So what's the middle ground? The idea we're toying with is empowering the community to help us to do it. We just need to come up with the guidelines for Community Wishlist managers. This was discussed above, and we're still working on figuring it out.

Long-term, we just feel this will thrive best if we work together, much like Phabricator and its many volunteer moderators. For now, local sysops should feel free to make any sane actions such as changing the status of a new wish to "Accepted" for a clearly valid wish, which will allow voting. The other statuses are mostly WMF product-oriented and we don't expect volunteers to make that call, and we trust it won't be abused.

If anyone has ideas on this collaborative effort, please share! An (in)formal RfC of sorts might be better to get broader input at some point, but no harm in starting the conversation here where it came up organically :) MusikAnimal (WMF) (talk) 04:48, 24 October 2025 (UTC)

Yes, let us moderate! It's what volunteers do anyway, even if not in the strict sense like closing discussions and assessing the consensus but in the form of reverting vandalism and filling in signatures. We're used to this, and if we dispute you can have the final say. You have a months-old backlog, we're frustrated, it can be a win-win.

But I still don't understand why that should be mutually exclusive with being able to support unreviewed wishes. Restrict it to auto- or extended-confirmed or whatever if you must, but it just throws a big wet blanket on your willingness to participate when a good wish pops up but you'd have to keep coming back to it again and again if you really wanted to vote for it (most of the time you don't, so you just forget the wish but not the frustration and the overall motivation for the wishlist diminishes). Nardog (talk) 16:35, 24 October 2025 (UTC)

One cannot vote for a wish that hasn't been submitted yet. That's natural. I wonder what a counter-proposal would be. --Matěj Suchánek (talk) 16:02, 22 October 2025 (UTC)

I assume the counter-proposal would be opening the votes only during a certain period of time, just like it used to be. Nardog (talk) 00:14, 24 October 2025 (UTC)

It seems like a lot of folks really miss the excitement of a timed-based survey. Meanwhile others complained there wasn't enough time to get their wishes in, or to find time to cast their votes. I just returned from WCNA where I discussed this with several volunteers. One idea that came up was to do regular voting campaigns, say right before Annual Planning. After the end of the campaign, we'd take a "snapshot" of the wishlist, and publish the results for that year. That'd hopefully help drive planning (and vice versa!), then we'd reset the votes for all unfinished work. This way, no one has to be bothered to re-write wishes but can still update them, votes stay current, and the historical voting snapshot is there for viewing. Apart from saving the "snapshot", this is all technically doable with what we have now.

This is just an idea! We are keen to bring back all the things people loved about the Wishlist, but I think to make it work we need to pace it out, and work together on reviewing wishes. The stress of the timed-based surveys was never enjoyable nor without its mistakes. Racing to review each and every single wish for technical soundness, patiently exchanging with proposers, then making the right undisputed call on whether it's worthy of inclusion, followed by the stress of being the center of attention for two weeks… It's a lot! If we give ourselves the whole year, that might be a viable compromise? MusikAnimal (WMF) (talk) 05:15, 24 October 2025 (UTC)

I like having a yearly snapshot for prioritisation, and for bringing the community together one a year.

An alternative to resetting the votes is potentially archiving wishes when they don't get any support in the preceding 12 months (assuming they are translated into English for fairness). That way, the total number of wishes stays manageable. —Femke 🐦 (talk) 20:10, 6 November 2025 (UTC)

It seems like a lot of folks really miss the excitement of a timed-based survey It does not seem like that as of now. It's certainly not "a lot of folks" but even more generally I wonder why that is what you got away from supposedly this talk page. It's important not to conflate time-based survey with time-based banners and campaigns around an ideas bank and technical development. So far, not much outreach about the Wishlist has been done, unlike for prior surveys so there isn't really any basis to claim this.

we'd reset the votes for all unfinished work strongly opposing this. It doesn't make sense. Should people then write down the wishes they voted on so that they can vote again next time? What's the benefit or need for purging wishes? If you'd like to have things start at a fair blank slate, remove the votes column during that time. If the issue is that people are unlikely to ever change their vote even when issues and Cons with a wish have been pointed out, these so far aren't really displayed on the Wish pages so next round the same thing would occur. Imagine if GitHub repos periodically purged all issues and said "now is the next round of issues". That defeats the whole point of it.

Femke's proposal is even worse and it may well be the thing I most strongly opposed ever so far on Wikimedia. It makes the whole point of this mute and is making this a deeply inefficient something. Nothing against regular voting campaigns but please don't remove wishes, that's an absurd idea and not thought through and in any case any benefits or why there would be a need for that haven't even been named. And this is not about keeping the number of wishes "managable" – and they aren't managed in the sense of much effort being there for getting them implemented – that's also quite an absurd way to think of this; it's about deliberating on and sharing important constructive impactful ideas that are valuable. This is as absurd as "archiving" all the phabricator issues that don't yet have an assignee because the number is not manageable – imagine all the time and effort wasted, the inefficiency, the things lost, the same things having to be raised again etc...all the same things apply here. One has yet to see any argument for removing wishes that could be addressed so I could only criticize these two ideas – when it comes to "excitement" nothing of that is specific to having voting limited to just a short time-frame and even if it was, "excitement" is a meaningless metric that's offtopic to a flourishing future of Wikimedia. Prototyperspective (talk) 23:45, 6 November 2025 (UTC)

One thing to avoid is that the wishlist becomes a duplicate of phabricator, with a huge backlog of wishes that we don't have the capacity to address. As a voter, I'd like to look at all wishes in a category and support or not. Maybe that's what other people like to do as well. At some point that category becomes so full that people can't do that anymore. We already have a lot of wishes now. Just like deleting votes causes voter time to be wasted, keeping wishes with only one supporter does.

I get the idea however of not prioritising old wishes over new ones. Old wishes will have more votes. But perhaps we can sort wishes by wish rate (wishes per year), as well as total wishes. —Femke 🐦 (talk) 22:55, 9 November 2025 (UTC)

Yes and that is exactly why I think wishes about increasing the capacity to address wishes should be among the top-priority things and could be most impactful. Secondly, things don't get solved just because there's too many issues and requests – they get done when and if they're done and one shouldn't pretend they're solved or archive them when they aren't. It's like saying let's just remove the task of Decarbonizing the food system because there's too many issues in addressing climate change already – it doesn't matter how many tasks there are or how unoverseeable the tasks are, the task itself is valid and shouldn't be archived from say Wikipedia and the news coverage (other things like a broader overview of summarized subtasks/problems of climate change can be done; see below).

The key thing here is that a problem of too many wishes can be addressed in other ways. Here are some and maybe other users can think of more:

• Tags (implemented but could be extended e.g. with additional tags and a way for category pages to also display wish titles)
• Hub issues that are summarizing a problem or solution with tasks that are about parts of them or subtasks being underneath them with just the hub wishes showing in the table or some filter/button to make it so
• Focus areas (implemented but not all relevant wishes have been assigned to these and just few focus areas existing and a small number having misleading titles or titles that often get misinterpreted)
• Ways to sort wishes (implemented but currently that's only votes)
• Search to find wishes of interest (implemented)
• Archving invalid wishes (implemented but quite a few wishes that are probably invalid per talk page haven't been archived yet)
• Subcategories
• Combine tags functionality (e.g. combine tag Wikidata with tag Multimedia…maybe even also allowing search terms in addition)

keeping wishes with only one supporter does strongly disagree, especially when less than a few hundred people have voted on wishes.

voter time to be wasted they don't have to spend the time. Voting to begin with was just added by some user requests and is fairly irrelevant. What matters is how big of a need or impact implementation of a wish has and whether it's implemented. The things in the list above can be used to reduce time spent by voters.

You seem to mistake the Wishlist to be a place for voters to find and vote on wishes but that isn't the goal (votes weren't even possible before so it's difficult to argue that was ever the goal). I think the value is in communicating requests and ideas and for these to get implemented. For example, it's enough if one volunteer developer uses it to find a wish with 0 supporters and understands the value and goes ahead and implements it. Maybe adding voting was a mistake because then people apparently mistake this as the key value or goal of the wishlist when it isn't. In addition, people don't notice much the issue of WMF doing only very little technical development to implement wishes. Votes are metadata to aid implementation as in it having better prioritization, but adding the metadata isn't the key outcome of the Wishlist but improved Wikimedia tech. Similarly, it doesn't matter how many people like the task of 'Decarbonizing the food system' and/or think it's important, it's still a valid task and people in that field and/or interested in it at any point can use the documented tasks to find relevant ideas or things to work on. Prototyperspective (talk) 14:20, 10 November 2025 (UTC)

@Prototyperspective Our actual wish is that the WMF spends more resources on fulfilling our wishes.

I wouldn't even care about the fact that they spend money on all kinds of random stuff if they would also spend enough to support the community. You know, their raison d'être.

Now we got a few tiny teams with usually less than a handful of devs who ask for wishes, receive 27647864983749872633 wishes and then actually work on maybe a handful, if we are lucky.

It is a giant waste of community time to have a community wishlist when there is only a tiny group of devs working on a trillion tasks. Polygnotus (talk) 14:44, 10 November 2025 (UTC)

Problems with /Votes

You can add a comment while supporting, and naturally people would want to reply to some of them. This can lead to splintered discussions between the /Votes page and the talk page. You can also miss a discussion on a wish despite watching the wish page because the /Votes page is separate and created later.

The support form should have a watch checkbox (and preferably an expiry dropdown), which probably should be checked if the user already watches the wish page.

But maybe the votes should not be happening on a subpage but on the talk page so all discussions on the same wish can take place in one place. Nardog (talk) 09:38, 22 October 2025 (UTC)

Thanks for identifying these issues and bringing it here.

• I don't think discussions splintered into two pages that are well-visibly linked to each other is a problem. People can discuss things first and then take their conclusion to the vote comment or discuss things further on the Talk page. They compliment each other. Voting-explanations are supposed to be shorter, succinct and more spot on. Moreover, if comments on the vote page get too long or too many one could cut them by moving it to the Discussion page and adding a [read more] / [continue discussion] link to the voting comments (similar to comments on Stack Exchange answers).
• People may not want to get new votes, sometimes including explanations, on their Watchlist so indeed I what's missing I think is a checkbox for "Watch page" for the voting dialog window.
• I think the votes are best placed directly underneath the wish and shouldn't be moved to a separate page except if they are transcluded onto the wish page, visible there by default.

Prototyperspective (talk) 13:30, 22 October 2025 (UTC)

I touched on the technical reasons for why we don't allow replies below, but what Prototyperspective says about keeping the vote comment short aligns with what we had in mind as well. Discussion can happen on the talk page where it belongs, and anyone is free to change their vote. This isn't a normal wiki page; You can't for example strike out a vote, as would be necessary if you wanted to change or remove your vote when there's a lengthy discussion beneath it.

In effect, you can think of wish, focus area, and votes pages as the storage medium. They can be edited manually, but they're aren't intended to be normally. The votes page is meant to be restricted to users with manually-edit-wishlist, but that's a bug. We'll get it fixed. That said, the whole reason of using the wiki for storage was for its benefits, which includes watchlisting! For those unaware, that is tracked at phab:T408089. MusikAnimal (WMF) (talk) 05:32, 24 October 2025 (UTC)

Then please make it clear each comment should be to the point and can't be replied to in the support form. Nardog (talk) 16:07, 24 October 2025 (UTC)

Link status to explanation

Link the status tags on wish pages and on Community Wishlist/Wishes to Community Wishlist/FAQ#What is a wish status? (pls mark it for translation btw, it had missing message keys), especially as some of them, like "Unsupported", are not self-descriptive. Nardog (talk) 07:20, 5 November 2025 (UTC)

@Nardog Pages are already marked for translation, thanks for noticing us. As for the request, it looks like a good idea. Would you please submit a wish (and a related Phab ticket) about it, so that we can evaluate it and work on it later? Thanks! Sannita (WMF) (talk) 14:04, 6 November 2025 (UTC)

Done: T409448. Nardog (talk) 14:44, 6 November 2025 (UTC)

A wish might be overkill for this one. Phab ticket is probably better. Which I see Nardog made, so should be all set :) –Novem Linguae (talk) 15:30, 6 November 2025 (UTC)

Thanks @Nardog, I can already say it's going to be high on our priorities, but I can't quite assure you on timings. I'll keep you posted on this. Sannita (WMF) (talk) 12:34, 7 November 2025 (UTC)

@Sannita (WMF): If I was to create a wish (not that I am), what would be the tag for that? I wondered why there wasn't a tag for wishes about the wishlist. Nardog (talk) 01:59, 8 November 2025 (UTC)

a tag for wishes about the wishlist I think a 'meta' tag would be great and a bit broader than that. It would for example also fit for W463: Volunteer software development recognition badges which isn't only about the Wishlist. Prototyperspective (talk) 11:02, 8 November 2025 (UTC)

I was thinking it might make sense to have a focus area for Wishlist improvements. MusikAnimal (WMF) (talk) 20:20, 14 November 2025 (UTC)

Would also be good. I don't think there would be many issues in it so far so because of that and also in general I think having the scope be broader would be substantially better: if the focus area was about technical wishes to improve Wikimedia technical development in general, including changes to the Wishlist tech. Prototyperspective (talk) 22:54, 17 November 2025 (UTC)

Votes that misunderstand focus area or remove comments

See Special:Diff/29600633 – the user voted on the focus area saying they think the focus area is about most importantly, categories should not be hidden in the mobile view when that focus area is not including the wish about it, W225: Show categories on mobile .

Moreover, another user already made the same thing, voting with a false assumption that this is also about showing categories and I clarified that it isn't in a comment underneath it. However, that comment got removed with the latest vote. Prototyperspective (talk) 22:00, 9 November 2025 (UTC)

Votes in focus areas and wishes

Inside a focus area Community_Wishlist/FA8 we had multiple votes for a specific wish Community_Wishlist/W326, as you can see in the comments of the votes and dates . There where at least 13 votes (many voted for it without commenting) for that wish but with the new system the wish now is close to 0.

Is it possible to move the votes from the focus area to the wish?

It looks very rare to have a focus area with many votes and all of the wishes inside the focus area with very little votes. Seems reasonable that the total amount of votes of the focus area could be the sum of the votes of all the wishes in it.

Many thanks for the effort. — The preceding unsigned comment was added by GabrielLucas (talk) 00:06, 11 November 2025 (UTC)

It may be a better approach to notify voters to a focus areas that and which wishes included in a focus area are open for voting and/or users who mention a specific included wish about that wish being open for voting. If it's possible a wish is included in multiple focus areas, then auto-supporting the focus area makes little sense and users may not agree with the framing or problem described in the focus area.

• A related topic is that there's quite a few wishes that are highly similar or the same as wishes in earlier Wishlist and from the earlier Wishlist, it can be inferred that these contributors most likely also support the latest wish (assuming they haven't changed their mind or have an issue with differences between the wishes).

Prototyperspective (talk) 14:13, 11 November 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)

Show wish titles on Watchlist etc.

I've created a user script that shows human-friendly wish titles on Watchlist, Contributions, etc., much like the properties and statements on Wikidata. I hope this proves useful and gets implemented upstream. Nardog (talk) 08:40, 18 November 2025 (UTC)

Nice! Chicagodogs (talk) 14:26, 18 November 2025 (UTC)

Great, thank you! It's very useful.
I wondered whether it may be able to be extended to also show the titles of phab issues. I checked mw:Phabricator/Code and it does not contain any info on a phabricator API (?!) but there does seem to be one (see here note: archived link because the live one seems to be down currently).
So maybe if a page contains phab link(s) it could be queried to display the phab issue title & status next to their generic unique identifier similar to wishes. Then this script would be more useful more widely, including for Wikipedia pages. See also {{Tracked github}} and {{Tracked}}. Prototyperspective (talk) 14:44, 18 November 2025 (UTC)

As mentioned at phab:T406537, CommuntiyRequests (or related scripting) isn't the place for this. The Conduit API is unfortunately a disaster to work with, but that doesn't mean something can't be done. I strongly agree with Nardog's assertion that your idea would make for a great wish :) MusikAnimal (WMF) (talk) 23:25, 18 November 2025 (UTC)

Thanks! phab:T406993 (wish titles on talk pages) should go live tomorrow. Once gerrit:1202896 is +2'd that will take care of phab:T406957 (change lists) minus categories, and maybe some other places. I will backport it. phab:T409241 (diffs) is still outstanding but should be trivial. MusikAnimal (WMF) (talk) 23:20, 18 November 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 as contrary to strategic priorities

This wish has been declined as contrary to strategic priorities. The team responsible for this is focused on other priorities and they don't see this wish as fulfillable based on the direction of the team. To read about what the team is focused on, see the Product & Technology OKRs.

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)

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)

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)