Community Wishlist/Updates

September 25, 2025: A new extension for the Community Wishlist

Hello everyone! We are happy to announce that we will deploy the new Community Wishlist extension on October 1! We hope this extension and the upcoming improvements will help you in submitting and translating your wishes to the Community Tech team, while also streamlining the influx of new wishes and navigation of the Wishlist.

The new extension comes with an updated intake form that will standardise the way wishes are categorised. We have introduced a concept called “tags”, which are keywords or phrases that associate a wish with a high-level concept. This essentially brings back the “Categories” that users may remember from the Community Wishlist Survey of years past. The older “Projects” field for wishes will be removed and replaced with tags.

As requested by the community in many instances, and as we already announced, it will be possible to support individual wishes again. This will help WMF teams prioritize their work when assigning a wish to a new or existing focus area, and choosing a new focus area to work on.

Another notable change is we will no longer be using the wish title as part of the page title. We’ve learned that wishes and their meanings can evolve, but moving pages to reflect the change in meaning isn’t particularly easy, and in some cases it is impossible. Instead, we will assign autogenerated IDs to each wish and focus area, i.e. W1, W2, W3, and FA1, FA2, FA3, etc. This is similar to how Phabricator and Wikidata work. This way, links to a particular wish or focus area are guaranteed to always be the same.

Browsing through wishes will now be done using pagination, as opposed to having all wishes listed on one long page. You will be able to sort by vote count, title, and creation date. The old system, which was powered by a bot, will be permanently retired. There will be a brief period of downtime while the extension is deployed and wishes are migrated to the new system.

Wishes will continue to be grouped and assigned, after review, to focus areas, by identifying the common themes across wishes. This will help teams to see if they can address related issues which could significantly improve your editing experience.

Within a week or two following deployment, we will add the ability to filter the existing wishes by status, tags and focus areas.

We hope this new extension will be welcomed by you, and we are interested in your feedback. This will be the first part of a series of new releases regarding the Wishlist, so stay tuned for other changes. Please do not hesitate to contact us in our talk page, and share with us your thoughts! We hope that you appreciate the changes we’re making based on your feedback, and that you want to continue being part of this process together with us.

Also, we remind you that we are collecting feedback around our next feature, Watchlist labels (formerly known as “Multiple watchlists”). We already have announced in the last update that we were looking for feedback regarding how watchlists and recent changes pages are used across projects, and we are still looking for input from you! In particular, we are interested in knowing how users would want to create multiple watchlists, and what each watchlist might be used for.

Thank you in advance for your help!

August 21, 2025: Back from Wikimania and next steps

Hello everyone! We’re back from Wikimania, where we had a presentation about the Community Wishlist. You can read our slides and follow the recording of our presentation on Wikimedia Foundation’s official channel.

We were also pleased to notice that our work of the last months was well received by people at Wikimania, and by the Wikimedia community at large: we had users with extended rights thanking us for our work on Multiblocks, and we noticed that the number of users adopting the Favourite Templates feature is rising. Right before Wikimania, on August 4, 3,916 users were using the feature, with 591 users adopting more than 5 favourites.

As we are back from Wikimania, we are now fully working on the deployment of the new Community Wishlist extension, which will likely be deployed at the beginning of September. The new extension will allow users to add tags to their wishes to better categorise them, and (in a future iteration) to filter them by status, tags and focus areas. It will be possible to support individual wishes again, as requested by the community in many instances. This may help the CommTech team to prioritize a wish within a focus area.

In order to ensure a connection between community wishes and WMF Annual Plan, and allow for a better prioritization of developers’ work, WMF staff will review and assign statuses to incoming wishes on an ongoing basis, and every three months statuses will be re-assessed in their product domains, to create focus areas, and prioritize the work as necessary. You can consult the current documentation on MediaWiki.

Lastly, in the upcoming weeks we will start working on our next feature: Multiple watchlists under the Task Prioritization focus area. We already have announced in the last update that we were looking for feedback regarding how watchlists and recent changes pages are used across projects, and we are still looking for input from you! In particular, we are interested in knowing which filters you use to select relevant edits, when doing your activities. What is considered best for patrolling, for example?

Thank you in advance for your help!

July 24, 2025: Watchlists and Recent Changes pages

Hello everyone! The Community Tech team is looking for feedback on a critical aspect of Wikipedians’ day-by-day activities – Watchlists and Recent Changes pages – and we’ve captured a lot of requests via the Task Prioritization focus area.

Watchlist (on larger wikis) and Recent Changes (on smaller wikis) are critical surfaces that are the “first stop” on Wikipedia, and for some users are the powerful landing pages when editing (see the findings of our latest report). Their feed receives regular review from many users, ranging from quick scans to extremely thorough explorations. Administrators, patrollers and established users rely on their watchlist as their main way to follow pages they care about—whether for governance, content, or communications tasks. Still, these pages have largely been untouched throughout the years, and volunteers often feel like they’re an “overflowing inbox.”

As we received lots of wishes pertaining to this focus area, we decided to make it into our main focus for the upcoming months. Our goal in this effort is to increase the click-through rate from watchlist to an edit. To achieve this goal, we initially want to focus on a core problem: watchlists can be overwhelming for editors with 100+ watched items, and they need ways to “break” their watchlists into component parts. We’ve seen at least 5 wishes that speak to this core issue. We also heard volunteers ask for better filtering mechanisms, performance improvements, and ability to view diffs in their watchlists.

We recognise that those two pages are the starting point of many wikipedians in their moderation activities, and we want to make them a better place to find the edits that need review. We also recognise that there are a plurality of use cases for watchlists and Recent Changes pages, so we need to balance the needs of users with less than 100 items in their watchlists and more than 100. Lastly, we will be facing substantial technical constraints that we will need to take into account when working on your wishes, which we are prioritizing in this quarter and the next.

We welcome you to review the task prioritization focus area and, if another idea comes to mind on how to improve recent changes or watchlist, we suggest you submit a wish!

June 18, 2025: Results of our last Wishathon sprint

Hello everyone! We wanted to share with you the results of the recently closed “Wishathon”, our internal hackathon organized by Community Tech to help fulfill more wishes from Community Wishlist.

The Wishathon, which ran from Monday 19 to Friday 23 May, engaged Wikimedia Foundation staff to help fulfill more wishes, and also foster cross-team and cross-departmental collaboration.

22 patches were written during the week, of which 4 were already merged. This allowed us to grant three wishes from the community, and we have a clearer path ahead for five more wishes.

The wishes granted through our Wishathon include:

Filing a patch to introduce the ability to set default watchlist expiries (phab:T265716; thanks to This, that and the other, MusikAnimal, and Susana Cardenas Molinar)
Fixing a bug that prevented the “[show/hide]” dropdown button of the navigational boxes to be shown by the “edit preview” reload button (phab:T315894, which came also with phab:T394078 to be fixed first; thanks to Sam Wilson and Joydeep Sengupta)
Filing seven different patches to the CSS sanitizer (phab:T324526, phab:T394619, phab:T277755, phab:T360725, phab:T368089, phab:T293633, and phab:T371809) that are awaiting code review at the moment, plus a couple more ideas to be evaluated (phab:T394963 and phab:T394964; thanks to Tim Starling and MusikAnimal)

In addition to that, we also worked on the following tasks and wishes:

Improved the way translation on discussion pages of wishes work (phab:T295862 and phab:T363306; thanks to Nik Gkountas and Joydeep Sengupta)
Realising a functional prototype to select templates by categories, related to Template recall and discovery (phab:T392553, thanks to Sam Wilson)
Completing the design and WIP implementation to revamp pagination of page navigation (phab:T394637, thanks to Michelle Horsey and Bárbara Martínez)
Improved the modules of the Wikimedia Dashboard (thanks to Arina Igumenshcheva, Dayllan Maza, Harumi Monroy, Jack Wheeler, Julieta Fernandez, and Katherine Graessle)

As you can see, wishes are very different in complexity and feasibility, so in some cases (such as the “[show/hide]” dropdown button and the CSS sanitizer) we were able to resolve all or at least most of the it, others (such as the Wikimedia Dashboard modules) are more experimental in nature, and we could only do some improvements without resolving it completely. Our work will be used to guide the direction of teams in this regard.

May 14, 2025: Multiblocks, Favourite templates, and upcoming Wishlist improvements

Multiblocks, the #14 wish in the Community Wishlist Survey 2023, has been successfully released on four wikis (Polish, German, Italian and Hebrew Wikipedia) and will begin mass deployment by the end of the month: all non-Wikipedia projects plus Catalan Wikipedia will adopt Multiblocks on the week of May 26, while all other Wikipedias will adopt it on the week of June 2. Consult our current deployment schedule on Phabricator to know more.

With Multiblocks, admins get more block options: a sitewide and a partial block can run at the same time with different expiry dates. This eliminates the need to wait for the expiration of one block to apply the other. An admin may want to initially impose a temporary sitewide block on a disruptive user, and later keep their access to specific pages or namespaces restricted. This may be useful in cases of blocking Wikipedians heavily involved in editing specific namespaces or pages.

We are also working on Favourite Templates, a new feature that was suggested by several users, that will provide a better way for new and experienced contributors to recall and discover templates via the template dialog. We hope this will increase dialog usage and the number of templates added.

Since 2013, experienced volunteers have asked for a more intuitive template selector, exposing popular or most-used templates on the templates dialog. At this stage of work, we are focusing on allowing users to put templates in a “favourite” list, so that their reuse will be easier. We are currently exploring additional ways to help users discover or find templates, and welcome your ideas and feedback.

We will involve Polish and Arabic Wikipedias for piloting this new feature, and we are already evaluating involving other projects for a second phase of piloting. We will keep you posted about this.

Lastly we are working on some improvements to the Wishlist:

we are exploring new ways to update the status of the focus areas and wishes, to make them more clear to users;
we will introduce a better way to categorise wishes, as requested, as well as ordering them by date of creation, to make them more browsable;
and finally, we will introduce (in the upcoming months, probably July-September 2025) a way for users to support individual wishes, and not just focus areas.

We also want to discuss one more consideration for the Wishlist, which we’d like your input. As WMF product teams and developers work off Phabricator to prioritize tasks, some teams have asked for a tighter integration between the Wishlist and Phabricator, so they can evaluate wishes and Phabricator tasks when they prioritize work. We’ve evaluated the data, and approximately 30% of wishes have a Phabricator task already. What is the ideal relationship between the Wishlist and Phabricator, and how should that be represented?

March 12, 2025: Multiblocks pilot

Multiblocks, the #14 wish in the Community Wishlist Survey 2023 will be released to the Polish-language Wikipedia by the end of March 2025 for piloting. We are also seeking additional wikis to pilot with. We have a deployment schedule on Phabricator.

With Multiblocks, admins get more block options: a sitewide and a partial block can run at the same time with different expiry dates. This eliminates the need to wait for the expiration of one block to apply the other. An admin may want to initially impose a temporary sitewide block on a disruptive user, and later keep their access to specific pages or namespaces restricted. This may be useful in cases of blocking Wikipedians heavily involved in editing specific namespaces or pages.

Currently, admins must wait for the first block to expire before applying a second one. They need to find other solutions like setting reminders to return and update the restrictions manually. With Multiblocks, this extra step is no longer necessary. As part of preparations for building Multiblocks, Community Tech has redesigned the Special:Block page using Codex. The block log has been repositioned towards the top of the page so the admins can easily access this information to decide the nature of subsequent blocks.

Blocks can now be applied using precise date selections, providing clearer and more consistent expiration settings compared to written time intervals such as "fortnights." These design changes serve as foundational steps for the Multiblocks implementation.

The refreshed Special:Block page is accessible via applying a url parameter ?usecodex=1 to the end of the link to an admin's block page. You can try it out. Give feedback about the refreshed Special:Block page on the project talk page.

Some communities may need to update their policies or guidelines for using Multiblocks. We encourage you to start considering these needs if they apply to you. Community Tech is here to support your discussions and will also be listening to how communities wish to approach this.

Thank you for your patience as we work towards delivering this helpful new feature.

February 20, 2025: Codex Special:Block Design Testers Needed

As CommTech prepares to fulfil the Multiblocks wish, we are redesigning the Special:Block page using Codex. Admins are invited to test a prototype of the refreshed block page in a moderated user test conducted by CommTech's Principal User Experience Designer Joydeep Sengupta. To sign up, please visit the Multiblocks talk page where we have some slots open for booking.

December 16, 2024: Better stitching between Commons and other projects is open for discussion and support

The Community Wishlist has curated a focus area from requests to improve connection between Wikimedia Commons and other Wikimedia projects. The focus area is titled Better stitching between Commons and other projects. It is also open for discussion and support.

October 27, 2024: Article Creation focus area is open for discussion and support

The Community Wishlist has created a collection of wishes and suggestions over time, highlighting the need for better support and guidance for newcomers as they create articles, while also aiming to reduce frustration and reverts. These ideas have been grouped under the Article Creation Guidance Focus Area.

All who are interested in the improvement of newcomer workflows are invited to explore these wishes, join the discussion on the focus area's collective talk page, and support if this topic resonates with you.

This announcement has been shared with:

Teahouse
African Wikimedians Telegram
Event Organizers Telegram

October 16, 2024: Update on edit restoration

Thank you all for your valuable feedback on the Edit Recovery feature! We've made some important improvements based on your comments on the Edit Recovery talk page. Previously, the feature would automatically recover changes by default when you resume editing and then give you the option to revert them as the next step. With this update, you'll be asked first if you want to recover changes or not. Now, editors have more control over their workflow.

For a visual demonstration of these changes, please refer to the screenshots below:

Previous version: Changes were automatically restored, editors had to discard the changes if they didn't want them.
New version: Editors are notified of unsaved changes and have the choice to recover or discard changes.

October 16, 2024: Conversations Made Easier: Machine-Translated Wishes Are Here!

The Community Wishlist is now testing machine translations for Wishlist content. Volunteers can now read machine-translated versions of wishes and dive into discussions even before translators arrive to translate content. Our goal is to make Wishlist content more accessible. We are inviting you to try this out by activating the "WishlistTranslation" gadget preference on MetaWiki. Please see below a screenshot of the section where you can turn on the feature.

Please bear in mind that these machine translations are not human-reviewed. Therefore, the quality of translations will vary, and we welcome any feedback from you via the Community Wishlist talkpage.

This feature is powered by MinT, a machine translation service hosted in the Wikimedia Foundation infrastructure designed to provide translation from multiple open source translation models.

September 16, 2024: Edit-Recovery feedback requested

Hello community, the Edit-Recovery feature has been active in Special:Preferences, Editing since spring 2024, and based on feedback, we wanted to ask how the feature should behave moving forward.

Currently, Edit-Recovery assumes that a user wants to recover their edits upon reloading or reopening a page, and prompts users to discard their edits. However, based on feedback on our Talk page, some users would prefer for Edit-Recovery to assume that a user does not want to recover edits, and instead, they should be prompted to restore edits.

The Community Tech team, at this stage, seeks community input on whether Edit-Recovery works as expected, or if users would prefer for Edit-Recovery to prompt users to restore edits.

Please provide feedback on the talk page. We hope to make a decision by Wednesday, 26 September 2024.