Talk:Community Wishlist

This page is for discussions related to the Community Wishlist page.

Please remember to:

Sign posts using the four tildes (~~~~)
Remain civil and polite during discussions.
Place new text under old text (start a new post).
Archives: 1

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

Archives

1

Reflecting on the new process to date

Latest comment: 2 months ago36 comments15 people in discussion

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)Reply

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)Reply

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)Reply

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)Reply

@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)Reply

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)Reply

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)Reply
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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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

@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)Reply

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

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

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

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

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

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

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

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

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

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

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)Reply

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)Reply

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)Reply

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)Reply

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

"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)Reply

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)Reply

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

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

"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)Reply

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)Reply

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)Reply

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

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)Reply

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)Reply

@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)Reply

Discussion continued below

Stuck at submitted

Latest comment: 2 months ago11 comments5 people in discussion

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)Reply

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)Reply

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)Reply

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

Check which of the wishes that have been suggested to be archived on their talk pages should be archived (link)
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)Reply

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

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)Reply

Stuck at Under review

The status is now called "Under review". Now there's an even larger fraction wishes still having the "Under review" status. Is there anything users – the creator of the wish or other users – can or should do to get them out of that status? If there's currently no capacities for reviewing wishes, please change the review procedure, or reduce the criteria of things that must be done to review a wish, or change the overall approach (see below), or raise the capacities for reviewing wishes.

Moreover, it seems kind of unnecessary to create this much of a barrier for wishes. Nearly all of the ones with the "Under review" status are reasonable coherent valid wishes and the ones that aren't by now probably all already have comments on the talk page that suggest archival (or the 'Done' status) or ask for something critical to be explained. Thus, it may be a better approach to just mark all wishes under review as 'Accepted' except the few where archival is suggested (and those may largely not even have the "Under review" status).

Waiting for various wishes to move out of that status (example, example) and looking at the table, it's an increasingly large fraction of wishes that have that status.

It's also somewhat unfair and possibly leading to suboptimal outcomes because those wishes can't yet be voted on so people read them but can't vote and then don't reread them when they can.

@STei (WMF) and MusikAnimal (WMF): could you take a look? --Prototyperspective (talk) 23:17, 19 November 2025 (UTC)Reply

Yeah, I don't understand why wishes aren't accepted by default and then closed once problems are pointed out, like most requests on wikis and Phabricator. It might have made sense when wishes had to be reviewed in a time crunch, but now that wishes can be voted on all year round, it feels like WMF/CommTech are unnecessarily burdening themselves with tasks they clearly are not catching up with, while also making the wishlist less engaging and more tedious. Nardog (talk) 02:08, 20 November 2025 (UTC)Reply

I think that's exactly it – in the past when we had voting on wishes, there was a large influx at once and a regimented procedure for us to carefully review them. If we mistakenly let something technically infeasible slip through and it got a ton of support, then we're either stuck with upsetting users midway once the issue is spotted, or a lot more disappointment at the end of the survey when it still can't be done despite its popularity. That was also a time where wish inclusion criteria was more strict, as those who took on wishes was more limited (mostly just CommTech for long-term projects). What you see now are indeed remnants of that system.

This sort of ties into the discussion below about asking for help from the community to assist with Wishlist maintenance. There's also an intersection with the idea to re-introduce promotional periods of proposal gathering and voting. Clearly we are still trying to figure it all out, and we hope to have some answers soon.

In the meantime, as has been suggested, perhaps it makes the most sense to allow voting on wishes that are still "Under review", but have it still keep the same meaning. Longer-term, maybe we might want to change it back, or at least during active CentralNotice banner campaigns when we expect a large number of duplicates, etc. I will bring this all up with the team tomorrow.

Thanks as always for the feedback! MusikAnimal (WMF) (talk) 08:23, 20 November 2025 (UTC)Reply

I have been accepting some wishes that I felt clearly qualified. I'm probably being overly cautious, though, as the lack of documentation for what the standards are doesn't help. * Pppery * _{it has begun} 16:12, 20 November 2025 (UTC)Reply

I went through the old pre-migration wishes and moved any that were "open" that were "under-review" in the new system to "accepted" (except for one I thought deserved a re-evaluation). That got the under review backlog down quite a lot. * Pppery * _{it has begun} 16:46, 20 November 2025 (UTC)Reply

Redlinks to existing talk pages in wishes

Latest comment: 5 months ago3 comments2 people in discussion

When reading a wish that has been translated to your language in your language, the Discussion page is a redlink even if the Talk page does exist. This makes it seem like there have been no discussions about the wish which is problematic as then a user who reads the wish and is interested in it is much less likely to go to the talk page where issues & ideas may have been described.

For example, Community Wishlist/Wishes/Sortering av kategorier på en side/en linked from the Wishes table has its talk page "Discussion" be a redlink but when clicking on it, it shows an existing Talk page.

Please fix this. Is there an issue about this? Prototyperspective (talk) 21:42, 30 July 2025 (UTC)Reply

Hi @Prototyperspective, thank you for your message. I will forward this issue to the team, and see if we can fix it in a short time. I hope to update you soon about it. Sannita (WMF) (talk) 10:25, 11 August 2025 (UTC)Reply

Hi @Prototyperspective, this problem will be fixed with the upcoming extension for the wishes. We currently filed phab:T401639 about this, so if you want you can subscribe to it and follow the works. Thanks again for your report! Sannita (WMF) (talk) 10:29, 12 August 2025 (UTC)Reply

Mention the Community Wishlist on the Main Page

Latest comment: 3 months ago13 comments5 people in discussion

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)Reply

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)Reply

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)Reply

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)Reply

@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)Reply

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

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

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

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)Reply

@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)Reply

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)Reply

@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)Reply

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)Reply

Watchlist filtering

Latest comment: 4 months ago19 comments11 people in discussion

Placeholder section for folks to put their thoughts! (or y'all can create wishes on the topic). Sohom (talk) 19:34, 26 August 2025 (UTC)Reply

I would dearly love the ability to pattern-match on page titles (on any of Watchlist, Contributions, or Revision history). I often know I'm looking for something under (for example) Wikipedia:Featured article candidates or Template:Did you know/Queue. What I typically do now is execute the Poor Man's SQL Query: ask for 500 (or, via URL editing, 5000) entries then search with my browser's Find function. I'm sure that having that filtering happen on the server side would be much more efficient, but you use what tools are available. RoySmith (talk) 20:03, 26 August 2025 (UTC)Reply

Namespace filtering is the most useful current filter for me (helps with poor man's SQL Query too), but if there is still a desire to move wikidata edits onto more watchlists, a separate watchlist for wikidata edits is likely the only way to make them viable for long watchlists. CMD (talk) 01:25, 27 August 2025 (UTC)Reply

I'm guessing PTAC is familiar with the recent research report on this? I found the recommendations for high-impact, low-effort tasks on page 24 (in particular the idea to add a note about why you watchlisted a page) to be good ideas. For watchlist filtering, I'd value the ability to color-code or otherwise differentiate pages in my watchlist that I've watchlisted for different reasons (i.e. some are geographically local to me, some relate to an interest of mine, etc.). Being able to have only two watchlists and having the second limited in pages would substantially diminish the utility of this. Sdkb ^talk 03:57, 27 August 2025 (UTC)Reply

@Sdkb For the avoidance of doubt, this isn't something that the PTAC was looking at the moment :) @JWheeler-WMF (and other folks on Community Tech) was looking for some feedback/wishes in this area and I was trying to act like a bridge and connect folks to places where they would see the call for feedback! (but that report is a interesting read!) Sohom (talk) 05:53, 27 August 2025 (UTC)Reply

@Sohom Datta Thank you for getting the discussion started, very much appreciated. And @RoySmith, @Chipmunkdavis and @Sdkb, thanks for your ideas, I'll be sharing them right away with the team! Sannita (WMF) (talk) 13:37, 28 August 2025 (UTC)Reply

@Sohom Datta: Focusing on watchlist filtering is a mistake. Instead, we need a general filtering system that can also be used for watchlist filtering. I want to be able to filter contribution lists. I want to be able to filter various Special pages. Improve the scope! See Community Wishlist/Wishes/Add Namespace filter to all Special: pages (where applicable) and the relevant talk page. Make the various filtering systems consistent. Polygnotus (talk) 01:26, 29 August 2025 (UTC)Reply

@Polygnotus, For what it is worth, the technology used to filter Special:Watchlist (and by extension Special:RecentChanges) is very specific to those two pages, porting it to other pages is a significant amount of work (on top of what should already be done for those pages). I agree that contributions lists are a interesting target, but for the rest, it will individual care and typically isn't something that can be strapped on in one go. Sohom (talk) 05:18, 29 August 2025 (UTC)Reply

(not saying that it is a bad idea, just contextualizing why this particular scope was chosen) Sohom (talk) 05:19, 29 August 2025 (UTC)Reply

@Sohom Datta I am excellent at reading between the lines and I can tell you think it is an excellent idea.

But then we can frame it a bit differently; let this be the start of a larger project adding and overhauling filtering on other pages. Start with the watchlist, and then use that experience to make the best filtering available everywhere. Also maybe look at en:User_talk:The_Transhumanist/WatchlistSorter.js. Polygnotus (talk) 05:24, 29 August 2025 (UTC)Reply

Can't recall the script I use, but I have three watchlists and could have more as I can choose what namespaces I want in each. Doug Weller (talk) 13:23, 29 August 2025 (UTC)Reply

Yeah it may be a good idea to look at which scripts exist because those were usually created in response to an unfulfilled need. Polygnotus (talk) 19:22, 29 August 2025 (UTC)Reply

sounds like en:User:MusikAnimal/customWatchlists. Johannnes89 (talk) 06:32, 30 August 2025 (UTC)Reply

I'd love to be able to ignore pages where all edits were made by a bot since I last visited that page. If the most recent edit was by a bot, but there were edits by human editors since I last visited that page, I still want to see that, it should still be bolded in my watchlist. Bogazicili (talk) 18:31, 30 August 2025 (UTC)Reply
Relevant issue: phab:T11790; if this was solved you could already do that by filtering out bot edits with the Watchlist filters. Too bad it's not (yet) known how changes from bots could be ignored in multi-edit diffs. Prototyperspective (talk) 23:05, 21 September 2025 (UTC)Reply
This sounds pretty great – I myself have a ton of watchlisted articles that can be user talk pages of users I warned, or pages I follow to catch specific LTAs, or noticeboards I'm interested in, or articles I'm working on, and it could be quite practical to be able to separate all of these. I'm not sure what the technical limitations are regarding having multiple simultaneous watchlists, and I'm curious why the proposal aims to limit itself to two to begin with. Otherwise, the aforementioned solution of "tagging" watchlisted pages and being able to organize/filter them that way could be equivalent, and potentially more intuitive as it could allow a broader overview than looking at watchlists one after the other.
I am less convinced by the option to filter by namespace. Don't get me wrong, that would absolutely be a great addition (and could be configured as a way to auto-sort new pages between watchlists), but that alone doesn't solve the whole issue, as some pages in the same namespace can be followed for different reasons (or the opposite). Chaotic Enby (talk) 14:49, 8 September 2025 (UTC)Reply

The Community Tech team is looking for feedback on a critical aspect of Wikipedians’ day-by-day activities – Watchlists and Recent Changes pages […] We already have announced in the last update that we were looking for feedback regarding how watchlists and recent changes pages are used across projects, and we are still looking for input from you! I suppose this is the place to provide that feedback. Filters I use and think are best for most editors with mixed editing (not just patrolling to spot vandalism) on English Wikipedia:
- Unseen changes – clearly a basic filter as this allows going through the list and eliminating those already done (a problem: rereading a wikipedia page on your watchlist marks the unseen edits as seen which is why I often open articles in a private window so these edits don't get marked as seen when I'm just reading (parts of) the article itself without checking the diffs)
- Changes by others – also basic as it doesn't make sense to use the Watchlist to check your own edits
- Human (not bot) – as described above the filter hides pages that were edited by a human editor but were subsequently edited by a bot which is a big problem but since on relatively very active ENWP those articles will just be on the Watchlist again at the next human edit, I still use this as a way to filter out pages with just 1 unseen edit by a bot
- Latest revision – also a basic filter despite that quite a few may not have that enabled for strange unknown reasons (maybe this could explained more here?); this is so that there's just one item per article since otherwise the Watchlist becomes a huge timewaste (more than already without a button to see a since-last-seen multi-edit diff), chaotic and doesn't make any sense for users with more than say 50 articles on their watchlist afaik)
- Type of change filters to filter out Wikidata edits – I have a separate Wikidata watchlist; speaking of Wikidata there is a large lack of a way to filter out edits to languages one doesn't speak (or missing machine translation for the respective values so users can understand and check them)

The number of max days and max edits to show could also be considered to be filters and those are way too small, especially for English Wikipedia. If there are performance reasons for those small limits, I suggest allowing users to get a watchlist with entries of say 10 times that limit a few times per day. When I want to see edits for the last 30 days but they don't show because the edit count is too large one can use filters like the talk vs article namespace filters as a workaround to go through the watchlist in several runs. Those super low limits are really strange and I don't know why they're there. --Prototyperspective (talk) 23:38, 21 September 2025 (UTC)Reply

Still not sure if this is the right place to provide the sought feedback (in part because there is so little which surely is in part due to it being unclear where and how to provide it which in turn puts the interest in that feedback data question). we are still looking for input from you! In particular, we are interested in knowing how users would want to create multiple watchlists, and what each watchlist might be used for. This would develop over time as I'd use the multiple Watchlists feature but the initial usage that I can see now is to have:

A separate Watchlist for top-priority items i.e. articles on subjects one knows a great deal about where one has extensively edited the article or which one simply likes to get notified of changes as soon as possible etc.
Then also a watchlist for articles where one added just a small paragraph or similar info and likes to check it every now and then (other users may not care about that part despite it being important or don't check the changes). For this Watchlist or probably multiple Watchlists for this, it would be very useful if one could add a note to the item so one can remember why one watchlisted the page initially. If it's because of watching content I previously added, I sometimes go to the page revision history to see what I added long ago (for example a chart).
Maybe a separate Watchlist for fast-moving meta discussion pages like VillagePump. Moving them out of the watchlist for example better enables to use of gadgets that open x since-last-seen diffs in new tabs so you only click one button (t = 1 s) and then wait until the tabs are loaded (t = 10 s) and can then without any hassle and exhausting clickery go quickly check them off one by one by going through these tabs until opening the new batch of tabs.
Probably also a separate watchlist for items that are particularly low-importance in terms of regularly checking them and that I watchlisted partly as a kind of bookmark and because I'd like to get notified major news on the subject (plus where it's enough to check them once every few months). In my case such articles could be about relatively untested or novel supplements where I'd like to get notified when it had trials/reviews or other study subjects & innovations (such as Klotho (biology)). This part is relevant to my wish W384: A 'Because You Read and recently edited a lot / updated' tile in the Wikipedia app. I basically only want to get notified of content of substance being added like a sentence referenced with a new study and just bookmarking requires me to check these manually (and iirc one can bookmark articles only in the mobile app anyway so would have to use browser bookmarks). Note that such items can also make the Watchlist more interesting as one is learning about recent developments.

Prototyperspective (talk) 17:04, 7 October 2025 (UTC)Reply

@Prototyperspective Thank you for your comments and feedback. This is the place, for now, to share feedback. We're still very involved with restarting the Wishlist with the new extension, so we still didn't restart work on Watchlists, but we will soon, and I'll make sure the engineers will see your comments. Sannita (WMF) (talk) 17:09, 7 October 2025 (UTC)Reply

Count wish author as support

Latest comment: 20 days ago8 comments3 people in discussion

It doesn't seem appropriate that the vote count starts at 0 instead of 1. The authoring of a wish should in and of itself be seen as a support for the wish.

The author should also be able to retract the initial support in the event they change their mind (without withdrawing the wish entirely as others might still support it) or they created the wish on someone else's behalf.

Likewise, whenever a wish is closed as a duplicate, the support votes should be transferred to the target (i.e. +1 at least). Nardog (talk) 03:03, 3 October 2025 (UTC)Reply

Retracting and updating votes is coming soon (Wednesday, we hope). I suppose the solution for automatic proposer votes is to have the system add an actual vote (with no comment) on wish creation, then they can retract or reword it as they please. That should work nicely with the new system! We'll get this implemented. MusikAnimal (WMF) (talk) 15:37, 3 October 2025 (UTC)Reply

Transferring votes when closing a duplicate is perhaps questionable, since the new target may be slightly different enough that voters don't necessarily support it. Transferring the proposer's vote makes sense, though! I have added that as an acceptance criterion at phab:T401638. MusikAnimal (WMF) (talk) 16:01, 3 October 2025 (UTC)Reply

Thanks for implementing something for adding some vote for the original wish proposer. Will the change also add the initial vote to already-existing wishes? If not, please also add those there and I think it's important to have this and even more so if this retractable auto-vote is implemented for newly created wishes. As for transferring votes, I think if the votes on the wish that is merged are not all transferred to the merge-target wish, then I think the merge should ping all of them so they can do it themselves (or alternatively provide feedback on what they miss or dislike in the merge-target wish). Prototyperspective (talk) 19:02, 4 October 2025 (UTC)Reply

We wouldn't deploy an auto-vote mechanism without backfilling existing wishes, indeed. I hate to add another migration phase to this extension, but this one should be fine because we can look only for wishes created before the auto-vote feature went live. Certainly, I don't think we should postpone re-opening the Wishlist just to get this feature out.

We can look into transferring votes a bit more. It does seem like more often than not, a vote for duplicate wish would apply to the original. The nice thing is that, unlike with the old gadget and bot-powered Wishlist, this is actually possible without any hackery. MusikAnimal (WMF) (talk) 00:14, 5 October 2025 (UTC)Reply

Tracked in Phabricator:
Task T415231

Every new wish now automatically has one support vote by the author since the patch for phab:T406670 has gone live, but it looks like proposer votes for existing wishes were not retroactively filled in. So wishes submitted before T406670 are at an inherent disadvantage and the list of wishes is now skewed towards new wishes. This seems not ideal, to say the least. Nardog (talk) 13:11, 20 January 2026 (UTC)Reply

Agree. This really needs to be filled retrospectively for wishes submitted prior to this, otherwise it would be very unfair and skew results. Maybe a new separate phab code issue is needed for that? Prototyperspective (talk) 14:50, 20 January 2026 (UTC)Reply

The task includes "After deployment, run a script to add the auto-votes for all the wishes created prior to this feature being released" as one of its acceptance criteria, so it appears it was closed in error. Nardog (talk) 14:27, 21 January 2026 (UTC)Reply

Declined upon migration

Latest comment: 1 month ago15 comments6 people in discussion

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)Reply

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)Reply

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)Reply

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

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

@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)Reply

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)Reply

@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)Reply

Not done but Done

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

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

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

Converting wish number to wish title

Latest comment: 3 months ago4 comments3 people in discussion

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)Reply

@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)Reply

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)Reply

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)Reply

The Community Wishlist has re-opened

Latest comment: 3 months ago11 comments4 people in discussion

We apologize for the multiple days of downtime. After fixing a few critical issues, we are ready to start receiving new wishes again.

We hope you enjoy the new features of the software upgrade, including the ability to vote on wishes, and tagging wishes by subject matter. You can look forward to a number of other improvements to come over the next few weeks, including the ability to filter for wishes at Community Wishlist/Wishes by tag or status.

In preparation of the upcoming filters feature, we invite all user to help us "tag" wishes so that they are easier to find.

Thank you! MusikAnimal (WMF) (talk) 22:26, 6 October 2025 (UTC)Reply

Congrats on the new extension!!

When sorting Community Wishlist/Wishes by number of votes there's a small bug where W1 gets displayed as having 1 vote, while on the page itself there are none. This denotes an underlying problem where removing a vote or blanking the voting page doesn't remove the vote(s) from the vote count. It's moon (talk) 14:56, 7 October 2025 (UTC)Reply

You guessed correctly! If there are >0 votes, the count should be correct. But when they are all removed, it doesn't update it to zero as it should. That is a bug, but per #Count wish author as support above, we will soon be adding auto-votes on behalf of the proposer, meaning very few if any wishes will have zero votes. So the bug should incidentally not surface again (though I still intend to fix it :) MusikAnimal (WMF) (talk) 16:43, 7 October 2025 (UTC)Reply

That's great news; thanks! 1. Is it possible to create new tags and if so how? 2. Why does it display Long-term opportunity for wishes with type = unknown in the top right? I think in such cases it should display nothing, or unknown, or something else since some of those wishes are readily quickly implementable. 3. When clicking "Edit with form", the tags added in a prior revision of W225: Show categories on mobile don't show up and I guess this has to do with the translation tagging. This would/does impede adding tags. Prototyperspective (talk) 16:33, 7 October 2025 (UTC)Reply

4. Please show the English title by default or for those users who configured English in the preferences / visit the English-language site instead of the original wish title. It was like that in the previous table where wish titles in Korean etc would only show if there wasn't yet an English translation. Prototyperspective (talk) 16:38, 7 October 2025 (UTC)Reply

Thanks for this feedback!

Creating new tags – not at this time. The tags are set by site configuration. I don't know that we want to allow creation of any arbitrary tag, as that would necessitate a moderation effort just to make sure there are no duplicate tags. We may also probably want to allow "tag redirects" etc. It could get messy! So I think for now we invite recommendations for new tags, and perhaps later it could be made configurable at Special:CommunityConfiguration.
"Long-term opportunity" displaying for the "unknown" status – That's a bug, alright! Could you point me to an example? We don't have an "unknown" status anymore. Instead we have a default status of "Under review", and that's what should be displayed.
Tags aren't editable until page is marked for translation – Another interesting bug! This one might be tricky to solve. I am inclined to figure something out, because as you say, most users are not translation admins and everyone should be able to assist with tagging. Another possible solution here is to auto-mark for translation when there are only changes to the translation template, and no changes to the translation units.
"English title by default" – This should already be the case. We are supposed to be following the same language fallback rules that are used everywhere else. Could you give an example?

MusikAnimal (WMF) (talk) 16:57, 7 October 2025 (UTC)Reply

1. Okay thanks. Maybe a separate dedicate page about tag proposals would be good sooner or later but maybe the ones available now suffice. If like focus areas tags are also supposed to be solution-driven or general areas, an earlier suggestion of mine in the archives for a FA about the tech used may not be a good idea to add as a tag. If tags are to be added, enabling users to suggest some early could be good as they are then available when people go through the wishes to tag them

2. It's also the linked W225 wish. 3. I don't know how translation tagging works in detail but think something like auto-marking for translation would probably be best. This may also be a good thing to implement more widely, as e.g. on Commons if I understood correctly there's many pages who were edited years ago and still not marked for translation waiting at c:Special:PageTranslation. 4. When I sort by votes, several wishes like W22 show up with 0 votes already on the first page in language Japanese and when I click these one goes to the Japanese page instead of the English translation despite that one exists for these wishes. Prototyperspective (talk) 23:24, 7 October 2025 (UTC)Reply

I don't have an idea in mind on how to formalize a "suggest new tags" system. I think simply asking here in a new discussion would work well enough. I don't quite follow what you're saying about focus areas, or what they have to do with tags. Anyway, I agree with what you're saying about "earlier the better" but given the tags loosely match the categories of the older annual Community Wishlist Surveys (which were formulated with the help of the community), we felt this list should be sufficient.
At Community Wishlist/W225 I see long-term-opportunity in the wikitext. Perhaps you're confusing the status with the wish type?
See phab:T252096 and its subtasks. We don't have the bandwidth to work on the larger solution right now, but we can introduce our own automation. It will still be quite tricky, though. Overall I'm going to have to say the auto-marking is only a "maybe" but I will happily look into it.
Thank you for providing repro steps! You've uncovered a rather critical bug. I have filed phab:T406680 and we are making it our top priority. Fortunately the data is all there, we just need to fix our query :-P

Keep the feedback coming! MusikAnimal (WMF) (talk) 17:56, 8 October 2025 (UTC)Reply

1. Tag suggestions By now after I finished adding tags to the first page of the default view of wishes I've changed my mind in regards to tags – it does need some more I think. 1. Wikivoyage (eg W12 W407) 2. Maps (eg W295 W323 W407) 3. Machine learning (eg W50; this tag is more tech/solution-based but this could also be useful since there could be specific team(s) that work with that / are skilled in that and people who are experienced with this tech in specific) 4. 'Bot and gadgets' should maybe also get tools added or a new separate tag be created for that (eg W392) 5. Metrics/stats or similar (eg W321 W272 W426 W415) 6. since Wikivoyage has been removed I wonder if there's further wiki projects that were set in the earlier version which have not been imported to the tags because no such exists for the project

2. Okay sorry. The button to see the wiki source text is gone and there's only the Edit with form button but I went to the revision history and could go to the source from a diff where I saw that this status is set. As touched upon in the votes, I think that's not a fitting status for that wish at all because it requires just a minor change (the unhiding of plain hyperlinks at for example the bottom of the page) to implement this and it's not a "long-term opportunity". Would be great if that status could be changed and maybe if needed it could be discussed further on the wish's talk page.

Further feedback:

If category pages are the way to browse wishes of a tag, it clearly needs a way to view the wish title on the category page (example example).
It would be nice if one could in a structured way search for wishes created by a given username (would be used mainly to see one's own issues). It would also be nice if the search showed only wishes in the language configured in the preferences (plus the original wish if it's not available in the configured language) instead of searching across all translations which makes wishes show up many times in results because the word or phrase searched for (such as the username) is also there in translated versions. Here is the search I tried and that had to be built manually.

Prototyperspective (talk) 17:35, 10 October 2025 (UTC)Reply

Having done some further tagging,

I echo the request to expand the bots and gadgets to something like 'bots, gadgets and tools' or 'technical tools'.
I struggle a bit to classify things around patrolling. Should it be in admins and patrollers or patrolling or both?
A Miscellaneous one, for instance for the log-out confirmation wish?

Keen to be able to browse wishes by tag too. —Femke 🐦 (talk) 07:08, 11 October 2025 (UTC)Reply

All great ideas! I will bring them up with the team. Some replies to a few things I can answer now:

I struggle a bit to classify things around patrolling. Should it be in admins and patrollers or patrolling or both? – I think we made a mistake and the tag should be "Admins and stewards" for things exclusive or of great interest to privileged users and functionaries, while "Patrolling" is the general bucket for moderation-related wishes. We'll get this fixed.
Renaming "Bots and gadgets" to "Bots, gadgets and tools" – bots and gadgets live or operate on the wiki, which is an important distinction. I'm thinking perhaps we need a "External tools" tag for things on Toolforge/VPS?
Keen to be able to browse wishes by tag too – that will go live this coming Wednesday.

Best, MusikAnimal (WMF) (talk) 18:16, 11 October 2025 (UTC)Reply

DISPLAYTITLE not working

Latest comment: 3 months ago8 comments4 people in discussion

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)Reply

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)Reply

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

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)Reply

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)Reply

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)Reply

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)Reply

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

Can't expand wishes section on mobile

Latest comment: 3 months ago4 comments3 people in discussion

Tracked in Phabricator:
Task T407044

I'm using Firefox on Android. I can't expand the two sections (focus areas or wishes) by tapping them. Is that a me problem or is something going wrong? —Femke 🐦 (talk) 18:47, 10 October 2025 (UTC)Reply

Example? The sections are all expanded and can't be collapsed for me, as they are not ‎<h2>...‎</h2>. Nardog (talk) 02:03, 11 October 2025 (UTC)Reply

I think Femke is referring to Community Wishlist specifically, and in Minerva / mobile format. I too am unable to expand the sections. I'm not sure why. I've filed phab:T407044. Thanks for reporting this issue! MusikAnimal (WMF) (talk) 02:42, 11 October 2025 (UTC)Reply

I have changed it to use {{fake heading}} for now until we figure out what's going on. It appears to be some sort of race condition with MobileFrontend. MusikAnimal (WMF) (talk) 05:49, 16 October 2025 (UTC)Reply

Some have supporters already

Latest comment: 3 months ago13 comments6 people in discussion

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

@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)Reply

Problems with /Votes

Latest comment: 3 months ago13 comments4 people in discussion

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)Reply

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)Reply

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)Reply

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)Reply

Oppose votes

Oppose votes have been moved to the talk page or removed – see Special:Diff/29495465. I think for technical wishes, it usually makes sense to just have support votes and keep other things to the talk page. However, that's not always the case and does have drawbacks. Namely, users may not check the talk page before voting or not the relevant part. Not knowing the main issues with a wish can negatively affect voting-decision-making and deliberation. On the other hand, certain things are disliked by some users for e.g. basically subjective bias reasons and/or due to misunderstandings (both of which also negatively affect deliberation and outcomes) and/or it could bloat the Voting section as people reply more to Votes. I don't think a large Voting section is necessarily a problem as each wish has its own page though.

I have no specific proposal as to what the optimal solution here would be. Maybe somebody else has an idea. For example, maybe there could be a hint somewhere on the page that there is criticism or reasoned criticism of the wish on its Talk page. In probably most but not all cases, the wish either gets declined or the criticism is more or less about how important or needed the wish is (e.g. not worth the effort currently or nearly useless to implement). A more visible note about the talk page such as the count of threads about the wish on the wish talk page could also be helpful, making it more likely people check these before voting or even working on a wish. Prototyperspective (talk) 21:53, 23 October 2025 (UTC)Reply

We obviously need to do something about this, but in short: You must use the "Support" button to interact with the Votes page. Subsequent votes will wipe out any comments that are not using the vote parser function. We can consider allowing oppose votes, but until then, we ask you keep them and other discussion on the discussion page. Thanks and apologies for the confusion. MusikAnimal (WMF) (talk) 18:45, 23 October 2025 (UTC)

It makes little sense then that you allow commenting while supporting at all, which is certainly not going to "keep other discussion on the discussion page". At that point the votes section should be just a single-line list of usernames, not a list of

Support, which certainly indicates replies and

Oppose,

Neutral, etc. are also allowed. Because of the increased visibility of the votes page compared to the talk page, you're creating a perverse incentive to say what you're want to say in your support, and that's not going to lead to productive discussions. Nardog (talk) 23:14, 23 October 2025 (UTC)Reply

I think it's visually better to read when there's something colorful. I meant to ask for the section title "Voting" to be changed but it does say "Supporters of this wish" that makes things clear. Why would that be a perverse incentive – people ideally succinctly explain their vote with a short comment. There just is a missing incentive to also address things / discuss on the talk page and to visit it all. Prototyperspective (talk) 23:39, 23 October 2025 (UTC)Reply

I personally am not opposed (no pun intended!) to adding support (again no pun intended!) for neutral and oppose votes. I believe the main reason we coded it as support-only is because we only count support votes, and that's nothing new – dating back to at least the 2017 survey. The new system merely is meant to enforce on a technical level what was already the case, whilst also keeping wish pages concise and not bloated with discussion. Mind you we hope to add an "Updates" section eventually (phab:T406286), so there may be more wish content to come that we don't want users to miss, in addition to reading what users have to say in their votes.

Yes, you could (and erroneously can) edit the wikitext manually, and indeed we got neutral/oppose votes in the past from that, but we still didn't count them. We could do the same here, but the problem is opposes often invite threaded discussion. I'm sure many of us are familiar with the situation where you have a voting-style survey like this or enwiki's traditional w:WP:RFA, where pile-on opposes can get out of hand, and then eventually the heated exchange has to be moved to the talk page. Unfortunately here, threaded replies belonging to a vote is not something we can allow whilst also getting the benefits of our structured parser function-based system. For example, #Count wish author as support asked for transferring votes when a wish is merged. We can do that, but if there are replies, we won't know how to copy them over cleanly as it is not machine-readable, so-to-speak (even if leveraging mw:DiscussionTools did help, it should not be a hard dependency of the CommunityRequests extension).

For discussion, you use the discussion page. It's partly the principle, but moreover a caveat of our implementation. Structured data and free-form wikitext can't be mixed, to put it simply. We're going to make some changes to the voting section to help understanding it's not for discussion, as we recognize it's not completely clear due to how the the older annual Wishlist surveys worked. See also phab:T406995. It's clear a lot of you think this is a discussion page, but it is not, and was never intended to be. There are no custom signatures, DiscussionTools is disabled, and the timestamps are formatted and timezone-converted based on your preferences.

Hopefully that makes sense! I'll bring up allowing neutral/oppose votes with the team, and we'll go from there.

Thanks and keep the feedback coming! :) MusikAnimal (WMF) (talk) 03:31, 24 October 2025 (UTC)Reply

I can see how allowing only support votes in the section at the bottom of the main wish page could be beneficial, in that it could prevent the splintering issue I identified above. But I think it's the presentation of the votes that is particularly confusing and invites opposes and replies. If there was no "

Support" and the dialog specifically instructed the user to keep it short and made it clear other users wouldn't be able to reply to your comment, it would be much, much more clear to all any substantial discussion of the wish should take place only on the talk page. Nardog (talk) 16:05, 24 October 2025 (UTC)Reply

Here (perma) is a clear example of a conversation happening on the votes page. I don't know how this could possibly be prevented. Inevitably someone is going to say in their support comment something someone else disagrees with, and it would create a sense of unfairness if the only way to rebut it with the same visibility was to cast a support vote yourself. There should at least be a way to indicate a support comment has a reply on the talk page (Stack Overflow/Exchange's comment system is a good comparison given above). Nardog (talk) 14:22, 25 October 2025 (UTC)Reply

Here's an idea: Create a parser function that takes a username and timestamp that, when used on the talk page of a wish/FA, creates an anchor and adds "this comment has a reply here" next to the matching support vote linking to the anchor. (It should stick even if the supporter modifies their comment, but not if they retract the vote and then support again. It's a shame updating your comment changes the timestamp; this goes against the de facto standard on the web, where editing a comment doesn't change the timestamp but adds "edited" or an asterisk whose tooltip reveals the last edited time—look at Reddit, Facebook, Discord, Slack, SO/SE, etc.) Nardog (talk) 11:40, 26 October 2025 (UTC)Reply

@Nardog Better idea: just use a normal Wikipedia method of freeform discussion, then guage consensus. Get rid of this weird "support a wish" stuff and let's not hide opposes on the talkpage. Polygnotus (talk) 22:49, 5 November 2025 (UTC)Reply

That's how things were like but users wanted votes and recently this functionality was added. One can have both as things are currently. As said, maybe one could make the freeform discussion and the possibly included opposes more visible in the Voting section of the wish, such as with a text like "There are x threads on the talk page" linked to it and maybe expandable to see the section headers. Lastly, I think it would be better if wishes addressed points of opposes, potential things people may worry or dislike about the wish, and challenges in the wish itself even when it makes the wish text longer. I tried to do that for the wishes I submitted, naming and addressing potential issues and challenges directly in the wish. So one idea for an alternative would be to encourage wishes to be edited to summarize the Cons raised on the talk page, including allowing the wish author to briefly address these. Prototyperspective (talk) 10:02, 6 November 2025 (UTC)Reply

Link status to explanation

Latest comment: 2 months ago9 comments5 people in discussion

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)Reply

@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)Reply

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

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)Reply

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)Reply

@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)Reply

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)Reply

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

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)Reply

Votes that misunderstand focus area or remove comments

Latest comment: 3 months ago1 comment1 person in discussion

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)Reply

Votes in focus areas and wishes

Latest comment: 2 months ago2 comments2 people in discussion

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)Reply

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)Reply

Adding nontag categories to wishes

Latest comment: 2 months ago4 comments2 people in discussion

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)Reply

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)Reply

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)Reply

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)Reply

Show wish titles on Watchlist etc.

Latest comment: 2 months ago5 comments4 people in discussion

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)Reply

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

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)Reply

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)Reply

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)Reply

Talk header inconsistency

Latest comment: 1 month ago4 comments2 people in discussion

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

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)Reply

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)Reply

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)Reply

Why were these declined

Latest comment: 30 days ago63 comments10 people in discussion

@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)Reply

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)Reply

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

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)Reply

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)Reply

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)Reply

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)Reply

(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)Reply

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)Reply

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)Reply

@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)Reply

@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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

@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)Reply

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)Reply

@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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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

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)Reply

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)Reply

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

@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)Reply

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

@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)Reply

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

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)Reply

@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)Reply

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)Reply

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

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)Reply

@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)Reply

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)Reply

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)Reply

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)Reply

┌───────────────────────────────────────┘
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)Reply

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

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

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

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

Reason for decline should be mentioned

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

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

Refocus

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

In reverse order:

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

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

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

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

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

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

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

Declined as contrary to strategic priorities

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

Discontinue voting on focus areas?

Latest comment: 2 months ago2 comments2 people in discussion

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)Reply

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).

Focus areas allow people to see the forest instead of the trees and vote on areas of improvement.
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.
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)Reply

False update

Latest comment: 2 months ago3 comments2 people in discussion

@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)Reply

@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)Reply

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)Reply

New wishes vote count

Latest comment: 20 days ago8 comments5 people in discussion

Some (new) wishes, such as Community_Wishlist/W496, have no supporters as of today, yet the table at Special:Permalink/29741670 shows they do - 9 in this case. pon_{o_r} (talk) 11:33, 18 January 2026 (UTC)Reply

I assume because it's "under review" (T409613). It is indeed confusing that the votes are hidden on the wish page yet the count is visible in the list. Nardog (talk) 12:40, 18 January 2026 (UTC)Reply

@Ponor Thanks for reporting this, I'll investigate with the team, and let you know about it. Sannita (WMF) (talk) 18:49, 19 January 2026 (UTC)Reply

It is indeed a bug, we're working on it. Sannita (WMF) (talk) 12:08, 20 January 2026 (UTC)Reply

All "Under review" wishes without "Votes" now

Hi! After this edit [6] all votes dessapeared from this page Community_Wishlist/W469. Other wishes that had their status changed from "Accepted" have the same problem. Iniquity (talk) 20:09, 20 January 2026 (UTC)Reply

Oops, I misread the thread above, it's the same problem. Iniquity (talk) 20:17, 20 January 2026 (UTC)Reply

merged threads --Prototyperspective (talk) 21:59, 20 January 2026 (UTC)Reply

Still working on it, please have patience. Good thing is, votes are still counted, so it's just a matter of making them visible again. Sannita (WMF) (talk) 11:05, 21 January 2026 (UTC)Reply

Badly written "How to write a good wish"

Latest comment: 4 hours ago11 comments5 people in discussion

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

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.
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.
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.
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)Reply

@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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

Space at end of support vote

Latest comment: 2 days ago2 comments2 people in discussion

If my support vote ends with a space, the vote gets rejected: "Unable to parse wishlist vote. It may contain invalid wikitext. Please ensure there are no extraneous pipe characters in the wikitext." pon_{o_r} (talk) 18:52, 7 February 2026 (UTC)Reply

@Ponor This is definitely a weird bug, but a bug nonetheless. Can you open a Phab ticket and link it here, so that I can pass it to the team? Sannita (WMF) (talk) 14:03, 8 February 2026 (UTC)Reply

Wishes without phab issue

Latest comment: 1 day ago5 comments3 people in discussion

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)Reply

@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)Reply

@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)Reply

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)Reply

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)Reply

			23:03		Talk:Community Wishlist/W34 9 changes hist +2,479 [Prototyperspective; Sannita (WMF) (2×); Nardog (6×)]
					23:03 (cur \| prev) +427 Prototyperspective talk contribs (→Response to the wish: Reply) Tag: Reply
			m		13:54 (cur \| prev) +11 Nardog talk contribs (→Response to the wish: clarify)
					13:52 (cur \| prev) +353 Nardog talk contribs (→Response to the wish: Reply) Tag: Reply
					13:46 (cur \| prev) +416 Sannita (WMF) talk contribs (→Response to the wish: Reply) Tag: Reply
					13:43 (cur \| prev) +6 Nardog talk contribs (→Response to the wish)
					13:42 (cur \| prev) +165 Nardog talk contribs (→Response to the wish)
					13:41 (cur \| prev) +173 Nardog talk contribs (→Response to the wish: Reply) Tag: Reply
					13:38 (cur \| prev) +380 Sannita (WMF) talk contribs (→Response to the wish: Reply) Tag: Reply
					04:28 (cur \| prev) +548 Nardog talk contribs (→Response to the wish: Reply) Tag: Reply

			18:05		Talk:Community Wishlist/W447 2 changes hist +1,759 [Prototyperspective; MikeZ-WMF]
					18:05 (cur \| prev) +1,226 Prototyperspective talk contribs (→Update from WMF: Reply) Tag: Reply
					17:02 (cur \| prev) +533 MikeZ-WMF talk contribs (→Update from WMF: Reply) Tag: Reply

			17:52		Talk:Community Wishlist/W443 2 changes hist +2,384 [Prototyperspective; MikeZ-WMF]
					17:52 (cur \| prev) +1,742 Prototyperspective talk contribs (→Clarification: Reply) Tag: Reply
					16:55 (cur \| prev) +642 MikeZ-WMF talk contribs (→Clarification: Reply) Tag: Reply

			18:47		Talk:Community Wishlist/W34 5 changes hist +1,470 [Juwan; Sannita (WMF) (2×); Nardog (2×)]
					18:47 (cur \| prev) +196 Sannita (WMF) talk contribs (→Response to the wish: Reply) Tag: Reply
			m		17:39 (cur \| prev) +16 Nardog talk contribs (→Response to the wish)
					17:29 (cur \| prev) +221 Nardog talk contribs (→Response to the wish: Reply) Tag: Reply
					17:16 (cur \| prev) +379 Sannita (WMF) talk contribs (→Response to the wish: Reply) Tag: Reply
					16:56 (cur \| prev) +658 Juwan talk contribs (→Response to the wish: Reply) Tag: Reply

			17:35		Talk:Community Wishlist/W463 3 changes hist +2,403 [Prototyperspective; Nardog; MikeZ-WMF]
					17:35 (cur \| prev) +1,802 Prototyperspective talk contribs (→Update from WMF: Reply) Tag: Reply
					17:34 (cur \| prev) +164 Nardog talk contribs (→Update from WMF: Reply) Tag: Reply
					17:12 (cur \| prev) +437 MikeZ-WMF talk contribs (→Update from WMF: Reply) Tag: Reply

			20:40		Talk:Community Wishlist/W288 2 changes hist +434 [Warudo (2×)]
			m		20:40 (cur \| prev) +10 Warudo talk contribs (→Opposes: c/e)
					20:40 (cur \| prev) +424 Warudo talk contribs (→Opposes: add vote)

11 February 2026

10 February 2026

9 February 2026

8 February 2026

7 February 2026

6 February 2026

5 February 2026

4 February 2026