Talk:Community Wishlist/Archive 2

The Community Wishlist has re-opened

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)

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)

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)

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)

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)

Thanks for this feedback!

1. 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.
2. "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.
3. 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.
4. "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)

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)

1. 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.
2. At Show categories on mobile (Community Wishlist/W225) I see long-term-opportunity in the wikitext. Perhaps you're confusing the status with the wish type?
3. 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.
4. 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)

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)

Having done some further tagging,

1. I echo the request to expand the bots and gadgets to something like 'bots, gadgets and tools' or 'technical tools'.
2. I struggle a bit to classify things around patrolling. Should it be in admins and patrollers or patrolling or both?
3. 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)

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)

Can't expand wishes section on mobile

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)

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)

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)

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)

Mention the Community Wishlist on the Main Page

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Converting wish number to wish title

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

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

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

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

DISPLAYTITLE not working

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

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

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

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

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

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

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

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

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

Problems with /Votes

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

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

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

Thanks for identifying these issues and bringing it here.

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

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

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

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

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

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)

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

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)

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)

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

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)

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)

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

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)

Some have supporters already

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Votes that misunderstand focus area or remove comments

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

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

Link status to explanation

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

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

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

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

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

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

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

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

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

Votes in focus areas and wishes

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

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

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

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

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

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

Prototyperspective (talk) 14:13, 11 November 2025 (UTC)

Stuck at submitted

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

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

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

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

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

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

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

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

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)

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)

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)

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)

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)

Show wish titles on Watchlist etc.

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

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

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

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

Thanks! phab:T406993 (wish titles on talk pages) should go live tomorrow. Once gerrit:1202896 is +2'd that will take care of phab:T406957 (change lists) minus categories, and maybe some other places. I will backport it. phab:T409241 (diffs) is still outstanding but should be trivial. MusikAnimal (WMF) (talk) 23:20, 18 November 2025 (UTC)

Reflecting on the new process to date

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hi all,

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

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

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

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

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

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

Discussion continued below

Adding nontag categories to wishes

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

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

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

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

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

Declined upon migration

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Not done but Done

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

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

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

Talk header inconsistency

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

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

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

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

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

False update

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

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

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

Wishes without phab issue

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

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

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

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

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

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

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

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

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

Merging wishes and votes

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

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

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

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

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

Inconsistent wish dates

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

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

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

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

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

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

Allow translating wishes "under review"

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

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

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

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

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

"Existing functionality" not specified

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

Badly written "How to write a good wish"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thanks @Prototyperspective for your feedback! Some points below:

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

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

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

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

Statistics about the implementation of wishes

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

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

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

---

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

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

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

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

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

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

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