Talk:Community Wishlist/Archive 1

Interface improvement suggestions

When submitting a wish at Community Wishlist/Intake I didn't see a link back to Community Wishlist at the top, so I couldn't open the page Community Wishlist (with instructions) in a new tab to know how to write a good wish.

Also, Community Wishlist/Wishes says Users are welcomed to propose their own wishes at any time and also can show support of other wishes submitted by the community. How can we show support? It isn't clear, please explain it or link somewhere. We can't vote on wishes anymore, so I don't know how to support a wish I like. Commander Keane (talk) 06:29, 16 July 2024 (UTC)

That's a good callout. We'll look into adding more instructions on how to write a good wish in the form. Do you prefer it as a link, or more instructive language in the form itself?

Re: Supporting a wish, there are many ways to support a wish, via Talk pages or by subscribing to wish updates. Once wishes are in focus areas, you'll be able to vote! JWheeler-WMF (talk) 21:36, 16 July 2024 (UTC)

@JWheeler-WMF: Just a link would be fine by me.

Re: supporting a wish, please spell that out if they are the only, limited, avenues. I can see it as a great source of frustration otherwise. Commander Keane (talk) 21:50, 16 July 2024 (UTC)

@JWheeler-WMF: how are wishes getting translated? Is there a translation team or something, I couldn't work out where to read the English version of some of the LOTE wishes. Commander Keane (talk) 02:53, 17 July 2024 (UTC)

@Commander Keane we have in our roadmap a plan to integrate with machine translations for ease of use and readability. For now, we are marking wishes for translation, and then following the proper translation processes. I hope these LOTE wishes will be translated in a matter of days. JWheeler-WMF (talk) 16:31, 17 July 2024 (UTC)

Community_Wishlist/Intake in zh

MediaWiki:Gadget-WishlistIntake/messages/zh only applies to zh interface (uselang=zh) but not zh-xx interface (uselang=zh-tw), which most zh editors use.

Is there a way to fix this? Thanks. Cookai🍪 _(💬talk) 07:56, 16 July 2024 (UTC)

Indeed, there are no proper language fallbacks – yet! We hope to move to message bundles soon, which I believe should provide us the fallback functionality. Even if it doesn't, we will find a workaround. I've filed phab:T370230 to track this effort. Thanks, MusikAnimal (WMF) (talk) 23:03, 16 July 2024 (UTC)

Hi @MusikAnimal (WMF), I see the migration has been done and the task is closed. However the problem seems still exist. It seems like the gadget is still using old communitywishlist messages instead of communityrequests messages. Cookai🍪 _(💬talk) 03:53, 25 October 2024 (UTC)

Broken translations on intake form

I don't see any translations in the intake form. This page -> Community Wishlist/Intake. On neither Community Wishlist/Intake/sv, Community Wishlist/Intake/zh, or Community Wishlist/Intake/uk. Community Wishlist/Intake/cs doesn't seem to exist despite there being translations on MediaWiki:Gadget-WishlistIntake/messages. Or is this controlled somewhere else? I thought that's we were encouraged to translate those messages in the first place. Sabelöga (talk) 20:39, 16 July 2024 (UTC)

Hi @Sabelöga! Apologies for the confusion. The Community Wishlist goes off of your interface language. Special:MyLanguage/Community Wishlist will redirect you to the correct language based on your preferences. Simply viewing i.e. Community Wishlist/Intake/uk isn't enough to see Ukrainian translations (except for the display title); you need to have the interface language set too – either by changing your preferences or passing in ?uselang=uk as with https://meta.wikimedia.org/wiki/Community_Wishlist/Intake/uk?uselang=uk. In addition, there are known issues with the lack of language fallbacks as pointed out above.

Swedish had a small error in the translations that broke the parsing. I've fixed that and it should be displaying properly now. Thanks for pointing this problem to us!

Hope this helps and let us know if you have any other questions or concerns. Warm regards, MusikAnimal (WMF) (talk) 22:46, 16 July 2024 (UTC)

@MusikAnimal (WMF) Ah, so it was in my end.  Thanks! I have added my first wish.

Oh, and an other thing. The result part the form is still in English. Could that also be translated? Sabelöga (talk) 23:01, 16 July 2024 (UTC)

@Sabelöga Could you clarify what you mean by the result part? All interface messages should be grouped together in the Community Wishlist interface aggregate group. I see from Community Wishlist/Translation that Swedish is at 100%, but it's possible we missed something. MusikAnimal (WMF) (talk) 23:24, 16 July 2024 (UTC)

@MusikAnimal (WMF) When I press the button to submit my wish, I get to this page basically: Community Wishlist/Wishes/Visa innehållsförteckningen när man redigerar i VisualEditor med Vector 2022. But when I pressed the button from the form, the part below the line "Visa innehållsförteckningen när man redigerar i VisualEditor med Vector 2022", was completely in English. Sabelöga (talk) 23:30, 16 July 2024 (UTC)

I think there's a real bug here, which is that the page renders in English from the time it is created to the time Community Tech bot notices it and sets the page language. That should be fixable at the cost of making the template more complicated, but I'm not sure if it's worth it. * Pppery * _{it has begun} 00:37, 17 July 2024 (UTC)

Ah yes, I understand now. What Pppery is correct. All pages created on Meta are by default English, so we have the bot set the page language for you shortly after a wish is created. That little bit of delay means you will briefly see English labels. I'll give this some thought. MusikAnimal (WMF) (talk) 01:31, 17 July 2024 (UTC)

@MusikAnimal (WMF), Hi, there is a error on Community_Wishlist/bn#Recent_wishes and on Community_Wishlist/fa#Recent_wishes. আফতাবুজ্জামান (talk) 18:25, 26 July 2024 (UTC)

@আফতাবুজ্জামান: It looks like @Cookai1205 has fixed it, the issue was that localized numerals were being passed to {{DateT}}. It should be working correctly now in all languages. SWilson (WMF) (talk) 23:38, 26 July 2024 (UTC)

Not usable on mobile (Android)

I tried using it on mobile but I cannot edit the description. I am also getting JavaScript errors on page load (something to do with includes) which may be related.

In addition to this the form is too big for my mobile phone and adds horizontal scroll.

I took a screen recording that I can share tomorrow. Jdlrobson (talk) 05:39, 17 July 2024 (UTC)

Hey @Jdlrobson - this is a known limitation right now. The description field doesn't load on mobile, and it's something we intend to disable until fixing. Thanks! JWheeler-WMF (talk) 16:34, 17 July 2024 (UTC)

Make the editing mode sticky

It's frustrating to have to switch to the source mode every time I visit the intake page. Nardog (talk) 05:46, 17 July 2024 (UTC)

Fixed MusikAnimal (WMF) (talk) 21:35, 22 July 2024 (UTC)

The edit/discuss button in translated wishes

Should the translated version of wishes (such as Allow uploading AVIF files to Wikimedia sites/zh) allowed to be edit/discuss separately? If not, should the "Edit wish"/"Discuss this wish" button direct to the original wish? Thanks. Cookai🍪 _(💬talk) 07:58, 17 July 2024 (UTC)

Hi @Cookai1205 - we encourage all discussions to go on a single talk page (of the original wish). We have plans to integrate with machine translations to support everyone viewing wishes and discussions in divergent languages. JWheeler-WMF (talk) 16:34, 17 July 2024 (UTC)

Thanks for the reply! So, the button in translations does link to the wrong page.

I suggest in Template:Community Wishlist/Wish:

• {{fullurl:{{PAGENAME}}... -> {{fullurl:{{#if:{{#translation:}}|{{#titleparts:{{PAGENAME}}|-1}}|{{PAGENAME}}}}...
• {{fullurl:{{TALKPAGENAME}}... -> {{fullurl:{{#if:{{#translation:}}|{{#titleparts:{{TALKPAGENAME}}|-1}}|{{TALKPAGENAME}}}}...
• returnto={{FULLPAGENAMEE}}... -> returnto={{#if:{{#translation:}}|{{#titleparts:{{FULLPAGENAMEE}}|-1}}|{{FULLPAGENAMEE}}}}...

So they can direct to the correct page. Cookai🍪 _(💬talk) 17:31, 17 July 2024 (UTC)

Yes, a fix similar to what you're suggesting is in the works. There are some changes to the gadget as well, so it is undergoing code review. See the merge request if you'd like to know more. MusikAnimal (WMF) (talk) 17:56, 17 July 2024 (UTC)

@MusikAnimal (WMF) and Cookai1205: That MR works well; I just merged it. Once you're on the talk page though, should we also be changing the Page link to go to the localized page (i.e. it'd have to check for the existence of the current lang's subpage and then change the target)? Otherwise, it seems you'd have to go from the translated page, to the talk page, then to the English page, then back to the translated page. SWilson (WMF) (talk) 01:29, 18 July 2024 (UTC)

Something that should probably be fixed in Extension:Translate, but yes, the "Content page" link target should be prefixed with Special:MyLanguage. MusikAnimal (WMF) (talk) 21:37, 22 July 2024 (UTC)

Eh, I started write a MR for this, but noticed there are tons of places with links that should have Special:MyLanguage. I.e. if you're on action=history of a wish page we have the same problem, or even other translatable pages for that matter such as Community Wishlist. I think users are probably used to this and fortunately the <languages/> bar is right there at the top, so maybe it's okay. MusikAnimal (WMF) (talk) 21:54, 22 July 2024 (UTC)

Another small problem related to i18n in Template:Community Wishlist/Wish. Currently, the colon in the "Other details" section is based on the user interface language, rather than the content language. It should based on the content language. Cookai🍪 _(💬talk) 18:01, 19 July 2024 (UTC)

@Cookai1205: Where are you seeing this? All colons are being added with the {{colon}} template, which is as you say given the interface language, e.g. <translate> Created</translate>{{colon|{{int:lang}}}} — but it's done this way consistently for all fields like this, so it doesn't look like these ones are different in any anyway. Why we're passing the interface language I'm not sure, as these pages are translated so we should be able to use the page content language (i.e. pass nothing to {{colon}}). SWilson (WMF) (talk) 08:13, 22 July 2024 (UTC)

Sorry for the late reply. I don't fully understand the question, but I'll try give out my thoughts.

I understand the colon is generated by {{colon}}. the colon is part of the content of the page, so it should follow the content language, not the user's interface language. So, I think it should simply be {{colon}} not {{colon|{{int:lang}}}}. Cookai🍪 _(💬talk) 07:59, 27 July 2024 (UTC)

Fixed with Special:Diff/27192724. I see now for example Community Wishlist/Wishes/Wiktionary mobile app/ja shows ： instead of :, so it appears to be going off of the page language now. MusikAnimal (WMF) (talk) 22:49, 29 July 2024 (UTC)

Another problem, the code for adding Category:Community Wishlist/Wishes/Translatable only works when the base lang is en. Cookai🍪 _(💬talk) 15:25, 20 July 2024 (UTC)

This is true, and we could instead go off of the baselang parameter, but it is not always correct (it's the interface language, not necessarily the language of the content the wish author is writing in). However, LOTE wishes are usually quickly translated, so the /en subpage will become present soon enough, I think. MusikAnimal (WMF) (talk) 21:57, 22 July 2024 (UTC)

Anglocentric example

Heya! I was wondering if there was another example that could be used when translating? "Draft articles" is a system that isn't used on the language projects I'm translating to/for. It's really no biggie, but I fear that the communities from those projects may not completely get the weight of the example. EdoAug (talk) 21:16, 19 July 2024 (UTC)

Draft: namespace should be implemented per community consensus as many wikis don't even need such system due to very little influx of articles. A09|(pogovor) 11:53, 20 July 2024 (UTC)

@EdoAug Which wish are you referring to? I don't see any currently that talk about the "Draft" namespace. MusikAnimal (WMF) (talk) 22:03, 22 July 2024 (UTC)

@MusikAnimal (WMF): The example given in the "How to write a good wish" section of the page this talk page is connected to, not an actual wish. EdoAug (talk) 22:22, 22 July 2024 (UTC)

Ah, I see. That example is not referring to the "Draft" namespace. It means the actual word wikt:draft, as in "an early version of a written work". We should probably find a different word to use, as that is confusing for those who are used to the Draft namespace. MusikAnimal (WMF) (talk) 22:48, 22 July 2024 (UTC)

Splitting WishlistManager gadget

Does MediaWiki:Gadget-WishlistManager.js really need to be loaded on all pages? Given phab:T340705, it seems like that could be cleaned up a bit.

It looks like this does sets of two things:

• Things only relevant to WMF staff. That should be split to a non-default gadget which they then enable.
• Things only relevant on views of wish pages themselves. That should be split to template gadget that only runs on Category:Community Wishlist/Wishes and Category:Community Wishlist/Wishes/Translatable.

This would mean not having to load 1,000 lines of JavaScript on every page view unrelated to the Community Wishlist. Thanks. * Pppery * _{it has begun} 01:07, 23 July 2024 (UTC)

@Pppery Unfortunately wgCategories (and mw:Extension:Gadget's knowledge of categories) isn't available on anything except action=view requests, when we need the gadget to run elsewhere, too. That's the main issue. It might actually be a bug with Core or something, as at least for action=edit and action=info the categories are already listed – so I presume not setting categories isn't in the name of performance.

I had pondered about making an "entrypoint" gadget that selectively loads the other gadgets that are needed. We can still do that, but I should mention all of this is temporary anyway, as we have plans to eventually migrate to a proper MediaWiki extension. MusikAnimal (WMF) (talk) 03:07, 23 July 2024 (UTC)

"Discussion" link goes to section=new even if the talk page exists

I don't know if this is a bug or intended, but it's quite annoying and can lead to the same topic raised multiple times. Also, as long as DiscussionTools' quick topic adding is enabled (which it is for new users), the new topic creation appears for red links, so I question the utility of the manipulation of the "Discussion" link in the first place. Nardog (talk) 06:31, 23 July 2024 (UTC)

See #The edit/discuss button in translated wishes above for the reasoning for this manipulation. We're now linking to just the root talk page without any additional parameters, so the experience should be better. It's still not perfect, though; Take Community Wishlist/Wishes/新規利用者が最初の記事を作成しやすくなるようにしてほしい/en for example. The "Discussion" link now correctly points to root talk page, but you'll notice the link is red despite that page existing! So a further improvement might be to do an existence check, and apply action=edit&redlink=1 accordingly. Ideally though, we would be able to tell mw:Extension:Translate that we want consolidated discussion on these pages, and it would fix all the links for us, but alas no such functionality currently exists. MusikAnimal (WMF) (talk) 18:34, 24 July 2024 (UTC)

In that case, adding redlink=1 no matter sounds like a good middle ground actually, since it would automatically redirect to the page if it exists (e.g.) and you wouldn't need to check the existence so it's faster. Nardog (talk) 19:25, 24 July 2024 (UTC)

I don't understand the advantage there, if any? We're currently linking to the page without any parameters, which in my testing appears to be the same behaviour as action=edit&redlink=1 when DiscussionTools is enabled (which we'll largely assume is true for Wishlist participants). The link itself is also the wrong color. I don't see a way to fix that without an existence check. MusikAnimal (WMF) (talk) 19:51, 24 July 2024 (UTC)

Oh, I didn't realize section=new shows the whole talk page when quick topic adding is on. My problem is that you don't get see the talk page even if it exists upon clicking "Discussion", unless you have quick topic adding on. Adding redlink=1 does redirect you to the page if it exists. Nardog (talk) 20:13, 24 July 2024 (UTC)

Also, couldn't a bot create redirects to the main talk page whenever a translation or the talk is created? That way you wouldn't need to check the existence and you can rely on whether the link is red. Nardog (talk) 00:27, 25 July 2024 (UTC)

Again, can you make a bot automatically redirect the talks of translation pages to the parent if it exists? The "Discussion" link e.g. here shouldn't be red. Nardog (talk) 05:01, 16 October 2024 (UTC)

Do you mean the "Discussion" tab beside the "Content page" tab? (If so, I guess MusikAnimal (WMF) might misunderstood your "Discussion" link as the "Discuss this wish" button)

I think the "Discussion" tab works the same everywhere on wikis. It's quite weird to have a bot create redirect for every talk page of translated pages.

Wouldn't the "Discuss this wish" button work just fine for linking to the main talk page? Cookai🍪 _(💬talk) 14:03, 16 October 2024 (UTC)

That the Meta wiki doesn't do something doesn't make it a bad idea.

The "Discussion" link is useful because it tells you whether any discussion about the page exists. "Discuss this wish" is useless for that. Nardog (talk) 03:07, 18 October 2024 (UTC)

Not just Meta but all multilingual wikis that use the Translate extension.

Maybe a new wish for the problem. This doesn't just happen on the Community Wishlist. Cookai🍪 _(💬talk) 03:28, 18 October 2024 (UTC)

There can be valid reasons to have talk pages for individual translations. That's the prerogative of the community at each wiki. I'm just pointing out as a user of the wishlist not redirecting the subpages leads to a frustrating experience of the wishlist. Nardog (talk) 07:40, 18 October 2024 (UTC)

Agree. It isn't just an issue with the Wishlist but with all meta & mediawiki pages (I think one can even land on an /en page instead of the main page from e.g. search engine results – for example I somehow landed here). I think for now all the translated pages should link to the main Discussion page. One could later have different talk pages per language where the /en one redirects to the Main talk page and other language talk pages either have a well-visible link to the Main talk page at the top or include the auto-translated talk page where changes are synced so that new posts in the talk page show up there and other-language posts maybe also get added to the main talk page. Such optimal solutions I think don't need to be discussed or implemented for other language pages' talk pages to be turned from redlinks to redirects for now when there is discussion on the main talk page. Prototyperspective (talk) 09:17, 18 October 2024 (UTC)

Clarification of the process

Thanks for all the work getting this up and running, but I'm pretty confused by the process here.

• What does "generally uneditable" mean for open wishes, as it doesn't seem to be a technical limitation (the edit window appears the same)?
• How does a wish move from Submitted to Open? If it's after WMF review, should this status be called something like "Reviewed" since "Open" implies open for editing?
• Will voting be for individual wishes within a focus area or just the focus area as a whole?
• Will focus areas need a certain threshhold of votes to be worked on, or will they have to "beat" other focus areas in the voting?
  • If the latter, how many focus areas will be competing for attention at once?
• Will all wishes be assigned a focus area, or will wishes that don't fit into a neat box (or wishes where there aren't two or more wishes in the same "area") be discarded?
• Community Wishlist/Wishes encourages editors to "subscribe" to wishes that align to their interests, but are the number of subscriptions tracked and taken into account when prioritizing wishes?
  • And for that matter, will subscribing to a wish itself do anything since it only notifies when new sections are created? Will a new section be added to the wish page when it changes status?

-- Ahecht (TALK
PAGE) 16:02, 25 July 2024 (UTC)

Thanks @Ahecht these are great questions. For one, our wish statuses are still something we're monitoring and tinkering with.

- Users are still able to edit Open wishes, however since they are marked for translation, edits would subsequently need to be re-translated.

- Wishes move from submitted to open by being a complete and well-considered idea or problem. Some wishes have remained "submitted" because we are still seeking clarification from the proposer.

- Voting is on the focus area as a whole

- No, focus areas will not need a voting threshold, however focus areas with more votes will certainly capture attention. In part, this is because focus areas pertaining to sibling projects (for example, Wikivoyage) will likely generate fewer votes than Wikipedia. We believe that the Foundation, affiliates, and developers will organically navigate towards the most compelling focus areas.

- Not all wishes will be assigned a focus area. Wishes that don't fit into a neat box will remain open, in case additional wishes come around and then warrant a new focus area bing created.

- As of now, we aren't tracking the # of subscribers per wish when prioritizing wishes. This is something to consider moving forward. We are evaluating further methods to keep tabs on a wish as it is updated and/or progresses to a Focus area. JWheeler-WMF (talk) 16:28, 25 July 2024 (UTC)

JWheeler-WMF Thanks for the clarifications! -- Ahecht (TALK
PAGE) 17:11, 25 July 2024 (UTC)

You're welcome! JWheeler-WMF (talk) 19:19, 25 July 2024 (UTC)

Exploring Community Wishlist - 19th DCW Conversation Hour

Hello pagewatchers, we are exploring the Community Wishlist in our 19th DCW Conversation Hour, with our guest speaker @Runab WMF, who serves as Senior Director of Product - Languages and Content Growth, at the Wikimedia Foundation. The hour is scheduled at 15:00 UTC (20:30 Indian Standard Time). I look forward to seeing many of you in the conversation. Should you have any queries, please let me know. _signed, Aafi (DCW) ^(talk) 16:34, 27 July 2024 (UTC)

Banner

Just why?! — putnik 14:56, 30 July 2024 (UTC)

@Putnik, can you help me understand better what the issue is? White on Dark Mode? Problematic translations? Wrong target wiki? On standby. Thank you. –– STei (WMF) (talk) 15:33, 30 July 2024 (UTC)

@STei (WMF), the translation is bad as usual. But here I'm talking about a big white block that ruins the idea of the dark mode. — putnik 19:57, 30 July 2024 (UTC)

I don't see where there is a rule that everything in dark mode should be pitch black... Also dark mode is just a couple of weeks old, most editors (including banner makers) will not know how to use it yet. I suggest some patience, or offering to help them out if you know how. —TheDJ (talk • contribs) 13:15, 31 July 2024 (UTC)

Commons needs

we have a bunch of things written down at c:Commons:Requests_for_comment/Technical_needs_survey which are perennial feature requests. RZuo (talk) 10:42, 1 August 2024 (UTC)

Translation tool for wishes

Hiya! I am aware that only "Open" wishes may be translated using the translation tool, however, I noticed that some of "my" wishes have incomplete setups, one for over a week. Is this intentional? As I have been encouraged to submit wishes in my native language, I would like to be able to translate these into the more internationally legible English. 😅

Examples of affected open submissions

• Community Wishlist/Wishes/Standardiserte datoer i referanser for innholdsoversettelse
• Community Wishlist/Wishes/Bedre system for å legge til og oversette undertekster

EdoAug (talk) 21:53, 5 August 2024 (UTC)

@EdoAug: I've marked these for translation now. Sorry about the delay! I think we can blame it on Wikimania (and people travelling to it). :-) Thanks for submitting in your own language, and also translating! SWilson (WMF) (talk) 04:15, 6 August 2024 (UTC)

@SWilson (WMF): Thank you! EdoAug (talk) 19:44, 6 August 2024 (UTC)

Another issue with this translation tool thing: at least one English wish has a translation page shown in the Wishes tables, please fix that. It now links to the A tile for the Current events portal in the Wikipedia app/bn page, not the original EN one. Prototyperspective (talk) 22:18, 24 October 2024 (UTC)

Suggestions to improve focus areas

There are very few votes so far on the focus areas: the engagement is much less than in previous years. I've got some thoughts on how to improve this if we stick to the new system.

• Fewer items per focus area. I've not voted yet as I agree with only one or two problem statements per focus area. Making them have this many wishes makes it unlikely you agree with a majority.
• Less fluff. Please remove the Foundation objectives. They are vague and do not add anything. It takes ages to know what a focus area is about. Be more concrete in the focus area description.
• Make wish titles wishes rather than wordy and vague problem statements.
• Highlight relevant items in the list of wishes. The old system made clear if the wish related to readers, citations. Now we have less relevant information like the last time a wish was edited. Less is more.
• Ask submitters to make their wish concise.
• Add a lead to the wish. When you click on a wish in mobile, you have to manually open sections to see what the wish is about.
• An a more radical suggestion: let's go back to voting on wishes, with focus areas defined after the fact. Say there are 8 ideas about watchlist improvements, 4 that are popular, 4 with only a handful of supporters, the focus area could consist only of the 4 popular ideas. Voting on individual wishes also increases community engagement. Normally, we see way more people give feedback on wishes, including saying that gadgets already exist and resolving the wish that way.

Femke (talk) 08:08, 10 August 2024 (UTC)

Hello @Femke, thank you for your suggestions. Regarding the popularity of the Focus Areas, here is how it is.

We launched the Wishlist approximately three weeks ago, starting with two weeks dedicated to wish intake. This period focused on informing the community about the reopening of the Wishlist, accepting new submissions, resolving any initial bugs, and preparing content for translation.

In previous years, by this time, we would have initiated the voting phase through Central Notice, inviting the entire community to participate. This approach traditionally generated a significant number of votes. However, in this new edition, we have taken a different path. Instead of immediately opening voting, we are concentrating on onboarding the community and explaining the concept of Focus Areas. These Focus Areas are intended to enable the community participate in annual planning on Product and Tech matters.

Currently, our team is actively engaged at Wikimania, promoting Focus Areas and the reopening of the Wishlist as well. We held a session attended by over 40 community members to help create Focus Areas and gather feedback. Additionally, we have set up a table at the conference to engage with attendees further on 3 conference days.

After Wikimania, we will extend a broader invitation to the community to participate in voting (in the absence of any bugs with the voting system). Until then, our primary focus remains on helping people understand the changes and the new structure of the Wishlist process.

Per our schedule it is a bit early to discuss the amount of Focus Area engagement. –– STei (WMF) (talk) 09:40, 10 August 2024 (UTC)

You're right may be early to think about more radical changes. This is the time, however, to make the process accessible. The high level of abstraction and verbosity make it difficult for people like me (with an energy-limiting disability) to participate, and make the process more difficult for beginners.

The German wishlist focus areas are much clearer. From the overview of wishes it's immediately clear what is considered in each focus area. The focus areas have a concise and concrete title. The overview page contains example wishes. On mobile, the line lenght meets accessibility criteria, as there is only one wish horizontally. (Here, the line lenght is too small with two wishes horizontally). They do not contain overly ambitious and broad non-SMART success criteria.

The content of the focus areas themselves can also be improved. Take the first focus area. This could be renamed as "Watchlist improvements". The first paragraph of the background section is what I look for, a clear problem statement. The second paragraph is very broad and does not relate directly to the wishes. The Foundation objectives again distract from the focus area as overly broad. Femke (talk) 10:16, 10 August 2024 (UTC)

Exasperating questions

It's exasperating to be asked to explain something no Wikimedian needs explained. Some of the wishes are copy-pasted from last year so clearly your team members understood what they were about. Can you maybe ask them first? And more important, become a volunteer and learn the ropes? Nardog (talk) 16:09, 22 August 2024 (UTC)

Could you perhaps rephrase this more kindly? And link to an example perhaps, so that others can follow? Femke (talk) 16:25, 22 August 2024 (UTC)

I'm sorry I came out harsh, the questions caught me at a not-so-good time.

I don't claim to have phrased all my wishes perfectly clearly and I'm sure there's always room for improvement, but some of Jack's questions were kinds that make you go, If you don't understand that, what do you understand about MediaWiki/WMF wikis at all?

For instance, this has been on Bugzilla then Phabricator since the aughts. Watchlist and RecentChanges are like the home pages for most Wikimedians, your main feeds if you will. Every Wikimedian knows they don't have pagination. Even if you didn't, one would think visiting the Phab tasks and reading the descriptions would have clarified what the wish was asking for.

I think it would be much less discouraging if questions weren't directed directly at the wish authors, but more along the lines of "Help me understand" and soliciting input from anyone (including CommTech employees, who are amazing volunteers and engineers).

It also appears the case that recommending wishes to be written "problem-led" and getting rid of the proposed solution field is making it harder to understand them. Now the wish has got a note essentially stating the solution. Nardog (talk) 03:23, 23 August 2024 (UTC)

Another possible improvement: a field for links to the same or similar wishes in past surveys. Nardog (talk) 04:19, 23 August 2024 (UTC)

@Femke, thank you for reaching out to Nardog. @Nardog, thank you for clarifying things.

I will forward the feedback about the restrictive nature of "problem led" submissions. The issue with that bit is we have had some wishes that have been very specific with how they should be fulfilled. Any departure from the steps prescribed, would make the proposer very unhappy, although there could be multiple ways of looking at the problem.

In the mean time, if you have any more wishes, just do your best to at least highlight the problem (to help us find a befitting focus area). You can then go ahead to add any other info that per your expertise can help.

Thank you both, and please keep helping us vet and discuss wishes whenever you have time. –– STei (WMF) (talk) 16:26, 23 August 2024 (UTC)

I think the risks of wishes being solved the "wrong" way is higher when wishes are "problem-led" and therefore likely less clear. Historically, I don't remember people being unhappy when the wishes are solved in another way, as CommTech has always had good communications about what is and what isn't feasible and people understood that.

The cool thing about the wishlist is that the non-technical community can help co-create solutions to problems. One of the aims of the new wishlist system is to get more engagement from the community in solving issues. An easy way to do this is let us keep thinking about solutions, rather than just posing problems.

As the wishes are unsorted and often don't have clear titles, I find it difficult to help vet. The categories such as feature request / bug, etc, are not that important for me as an editor. I would like to know if they are about reading experience, adminning, citations etc. Femke (talk) 18:54, 23 August 2024 (UTC)

Yes, bring back categories! It's tiresome to sort out what piques your interest from a long list. Nardog (talk) 02:07, 24 August 2024 (UTC)

Thanks @Femke for these comments. We've historically had a mixed bag of feedback regarding solving wishes. On one hand, CommTech has been effective at solving individual wishes and communicating if a wish is not feasible. On the other hand, CommTech wasn't able to fulfill 10 wishes a year.

Wishes come in all shapes and sizes - there are some wishes that are very tactical, such as Community Wishlist/Wishes/Minor edits made by Source Editor (mobile web), and some that are more abstract. Ultimately, we want to influence prioritization on two levels: surface tactical opportunities to teams at the foundation, while also surfacing strategic problems to solve (Focus area).

Teams will still need to prioritize tactical wishes and certain backlogs can be quite robust. For focus areas, we plan on looking holistically at the problem by reviewing the wishes in aggregate. It's possible that we implicitly solve wishes without building to spec.

As far as the wish organization, I do see the value of categories, and this is something we can continue to explore as we evolve. JWheeler-WMF (talk) 17:58, 11 September 2024 (UTC)

Then emphasize that the proposed solution is optional and may not be adopted. And perhaps allow others to add/workshop their versions as well. When you submit a wish omitting what you want as you were told, and then are asked to clarify what you want, and then the wish is slapped with a note saying what it's actually asking for, it feels not only counterproductive but as silly and goofy as a Rube Goldberg machine. Nardog (talk) 23:54, 23 August 2024 (UTC)

Ideas for improving the layout of Community Wishlist/Focus areas

• Consider not using tiles. Tiles require the reader's eyes to zig-zag around the page in what I find to be an unintuitive way.
• Consider transcluding the list of wishes directly under each focus area, instead of requiring a click. The transcluded wishes should ideally be very concise. Probably a bulleted list of just the wish titles. If space is an issue, maybe only transclude 3 wishes per focus area. Examples help turn each focus area from nebulous to concrete.

Hope this helps. –Novem Linguae (talk) 12:02, 27 August 2024 (UTC)

😀 Those overlap with two of my suggestions above (removing tiles at least for mobile, adding adding example wishes like the WMDE wishlist). Still waiting on a response there from @STei (WMF) :). Femke (talk) 17:17, 27 August 2024 (UTC)

@Femke. @Novem Linguae the WMDE wishlist also uses tiles for focus areas. Are you asking for a list?

Are you suggesting transcluding a few templates into the tile itself? JWheeler-WMF (talk) 14:36, 29 August 2024 (UTC)

Are you asking for a list? Yes. Wiki pages typically have a linear flow. Are you suggesting transcluding a few templates into the tile itself? Yes. Well, transcluding a few wishes rather than templates. No biggie if you choose not to go in this direction, but these are my small suggestions. –Novem Linguae (talk) 15:27, 29 August 2024 (UTC)

Oh. Could also do one column of wide tiles to solve the zigzag issue. –Novem Linguae (talk) 16:11, 29 August 2024 (UTC)

I don't mind the tiles themselves too much. The German tiles do work much better on mobile, as only one tile is displayed horizontally, rather than two. So would love for that to be equally accessible here. Femke (talk) 16:09, 29 August 2024 (UTC)

Bizarre process

On the face of it, voting for a focus area at this stage makes no sense, as there is no deadline or indication that there won't be more of them. A vote for a candidate is a vote against the others in the same race. But we do not yet know what they will be. So are you just going to be biased toward areas that were created early? Even if you measured the votes in proportion to the time during which the voting was open for each area, it wouldn't be reliable because the wishlist has already been advertised so the number of people who see an area per day (or whatever) is going to be different for each of them, not to mention some who voted for an area might prefer another that hadn't been created yet when they voted. Overall the whole process seems incredibly half-baked and I do not see how it could help prioritization in a remotely fair or objective way. Nardog (talk) 14:30, 29 August 2024 (UTC)

Hey @Nardog - I wanted to clarify a few things. The CommTech team is not the only team responsible for adopting and working on focus areas. We anticipate through 2025-26 annual planning that multiple focus areas will be adopted by teams across the foundation, and volunteer developers can also rally together and adopt a focus area. A vote for one focus area is not a vote against another, but rather a signal of demand. You can vote on any focus area you like, there's no limit to voting.

As far as "votes over time" go, this is a concern, one that we are going to monitor. Number of votes is one mechanism for focus area adoption; for example, we'd expect to see more votes on a focus area regarding citations than for Wikisource, namely because more people interact with Wikipedia and citations at large.

Over the next couple weeks - and over time - we will release even more focus areas for discussion, measuring signals, etc.

While the process is more nuanced than previous years, it is built off a model from WMDE that has seen success. This new process moves away from a popularity contest for individual ideas, and for some that might be seen as less objective or fair.

Thanks for your continued participation and engagement. JWheeler-WMF (talk) 14:45, 29 August 2024 (UTC)

We should be able to choose what we want, not the least bad group. Each focus group has at least one idea that produces little to no benefit and costs a large amount of developer time.

@JWheeler-WMF: It should be clear by now that the whole "focus areas" idea needs to be dropped ASAP. It was just a bad idea. If it is not clear to you why "focus areas" are bad idea then please let me know, I can list many reasons and I'd be happy to explain them in detail. If you are unable to change course, but you already understand that this is a bad idea then please let everyone know so that we don't have to keep telling you why it is a bad idea. Thank you, Polygnotus (talk) 16:58, 29 August 2024 (UTC)

Thanks, that is some important context, but... There aren't an infinite number of teams, or an infinite number of personnel in them. So there can only be so many focus areas to be worked on. If some focus areas aren't going to be picked over—or before—others, what even is the point of them? Is assigning a wish a focus area already a stamp of approval that it's going to be worked on? It doesn't look like it and I sure hope not. So please don't tell us focus areas aren't competing with one another when they clearly are.

I've been thinking about why I felt like voting for wishes in the past years and I don't feel like voting for focus areas now, and I think it all comes down to the lack of transparency. If a vote is just a "signal of demand", there is little reason or motive or incentive to cast one because it's extremely opaque what that means, entails, or does. It feels no different from the situation that has existed on Phabricator, where, if you don't have the skill, resource, and social capital to make a wish a reality, all you can do is pray and wait for (or harass) someone else to do it for you. The arbitrary nature of it makes it feel hopeless, unjust almost. The CWS bridged that gap. You could at least see what difference a vote made. It's empowering when you can foresee a tangible outcome. Now I don't feel empowered to vote on focus areas, and I have the same sense of helplessness I've had on Phabricator.

It's like we've moved from a direct democracy to a representative democracy. You never find a candidate whose policies you endorse 100% in an election, so you have to be really strategic and to research and compromise if you want to see your vote make even a tiny dent in the outcome. So getting rid of voting on individual wishes has made it far less engaging and more onerous. Even in a representative democracy, you can usually at least try to influence policies by engaging in party politics or calling your constituency's representative. I don't know how I can influence the allocation of focus areas. It feels like you've taken power away from us.

I don't know if the new system is a bad idea, I haven't seen it play out. But it has certainly been much more complicated and inaccessible and less engaging or exciting. Nardog (talk) 01:35, 30 August 2024 (UTC)

@Nardog: At this point I do not think that JWheeler-WMF does not understand the downsides of the Focus Areas system. But plans have been made and it is too late to turn back. So if we put more and more effort into explaining why it is a bad idea it is only discouraging and not helpful. I've been in the position before where I had to toe the company line while knowing full well that the criticism was justified. The problem was that there was no way back. The company I worked in at the time had a toxic work culture.

When JWheeler-WMF writes: We anticipate through 2025-26 annual planning that multiple focus areas will be adopted by teams across the foundation I interpret that to mean that this is a long term thing and a WMF-wide decision that JWheeler-WMF did not make and is unable to change.

At least, that is my attempt at reading between the lines.

The extremely careful wording and the fact that criticism of ideas is repeatedly interpreted as an attack, and not as valuable feedback, is a sign that they can't just say: "oh yeah my boss is an idiot lol". I can, but I am self-employed. Polygnotus (talk) 02:25, 30 August 2024 (UTC)

Like I said, I don't know if it's a bad idea. It might be, and it might instead turn out to be a net positive with more wishes I want fulfilled fulfilled. I was just explaining why it feels pointless to participate in the voting right now. Nardog (talk) 03:03, 30 August 2024 (UTC)

I understand. It certainly is a bad idea. Focusing on some quick wins and some technical debt while maximizing scale (amount of people affected) and depth (how much they benefit) would be a good idea. Polygnotus (talk) 03:10, 30 August 2024 (UTC)

You've made your point clear, you can stop bludgeoning now. Nardog (talk) 03:13, 30 August 2024 (UTC)

Friendly fire is a bad strategy. I am just trying to help, and this is a new conversation topic. Polygnotus (talk) 03:15, 30 August 2024 (UTC)

!Voting system is inferior to normal wikicode

The !voting system is inferior to normal wikicode, I can't even edit my !vote (made a typo). It should be scrapped because it offers no advantages over normal !voting in wikicode and it has many downsides.

Editing a vote appears to be impossible (changing your mind after a discussion/further research should be encouraged, not discouraged)

I haven't tested it but it is likely that it is also open to abuse btw (e.g. deliberately inserting malformed code to hide any votes under yours). Polygnotus (talk) 17:02, 29 August 2024 (UTC)

Community Wishlist/Focus areas/Repetitive tasks/Votes --Johannnes89 (talk) 17:53, 29 August 2024 (UTC)

@Johannnes89: Thank you! Point still stands tho. Do you know how to add an edit link to each of these !voting areas? Polygnotus (talk) 18:00, 29 August 2024 (UTC)

Editing of votes via the gadget is something we wanted to implement, but just haven't gotten around to it yet. We'll try to prioritize this. It should perhaps also be paired with a "Remove my vote" button, or something. MusikAnimal (WMF) (talk) 20:28, 29 August 2024 (UTC)

@MusikAnimal (WMF): But since that isn't implemented yet, can you stick a [edit] link in there? @JWheeler-WMF: is not opposed to [edit] links, hence the WMF tag in the username. Polygnotus (talk) 20:42, 29 August 2024 (UTC)

Having a discussion BEFORE !voting would lead to more informed choices

!voting is a last resort.

First we need to have a discussion where people can list the pros and cons of each idea.

We would make more informed choices after a good discussion.

In future iterations of this thing, !voting should commence AFTER a discussion.

I had to boldly add discussion sections myself... This is a very bad look because it shows a fundamental lack of understanding (or interest in) wiki-culture. Polygnotus (talk) 17:13, 29 August 2024 (UTC)

I totally agree that discussion first is essential, some wish discussions have turned my opinion from strong to weak support to nearly oppose.

People do love to summarise their discussion points with !votes though, and voting templates can make it easier for non-English users to contribute (eg the ~20 support template shortcuts in various languages on Commons).

I suggest the possible use of the following templates for prioritisation of wishes, to evaluate their importance:

• Top priority
• Good idea, but lowest priority
• Oppose

I have a problem with the ambiguity and uselessness of a simple {{Support}}.

A user run bot could then count these templates and issue a report. Commander Keane (talk) 20:49, 21 October 2024 (UTC)

It wasn't smart of me to say I like discussion then suggest voting templates, sorry. Perhaps a discussion board where wishes are brainstormed before being submitted. If you have to wait one week or have a second person submit it for you it would reduce the number of wishes with ambiguous titles (even the most thorough wish makers can put a solution in the title by mistake), duplicates and already solved problems.

Users, me included, seem very hesitant to edit wishes. A discussion phase would help eleviate that.

Also I find it difficult to discuss a point when the talkpage section title is "Oppose". Commander Keane (talk) 02:41, 25 October 2024 (UTC)

Adding discussion sections to "Focus areas"

@MusikAnimal (WMF): reverted my addition of discussion sections with the editsummaries: "please ask first" and "please consult first; this is might be breaking automation" and "please discuss first at Talk:Community Wishlist".

The (unofficial) motto is: "Fix it yourself instead of just talking about it.".

And it is incredibly unlikely, basically impossible, that this will negatively affect "automation" in any way. As a software engineer MusikAnimal is aware of that.

So while I do not want to start an editwar the editsummaries do not make sense and it could be interpreted as an attempt to hide negative feedback, which is an impression you surely want to avoid giving, even unintentionally. Polygnotus (talk) 20:12, 29 August 2024 (UTC)

We have a bot that listens for changes to focus areas and this might confuse it. I didn't take the time to confirm. The changes may also conflict with our current machine translation efforts (also unconfirmed). Unexpected changes to otherwise "structured" wikitext pages causing problems is something common to all prior Wishlists as well. It is a caveat of our template/module/bot-driven system. You're not wrong for being bold, things are just fragile and I don't want anything to break :) We also don't want lengthy discussion to distract from the content, for the same reasons the Talk namespace exists. Technical bits aside, transcluding the discussion is a product decision too and thus would need approval from @JWheeler-WMF. Thanks for your understanding, MusikAnimal (WMF) (talk) 20:26, 29 August 2024 (UTC)

@MusikAnimal (WMF): !Voting patterns are (and should be!) influenced by arguments for and against. !Voting without a discussion leads to inferior results. "Hiding" the discussion on a different page will drastically reduce the amount of people who see it and engage with it. You are a hardcore Wikipedia user so I am telling you nothing new.

This is why there are no decisions on Wikipedia that are decided by simple !votecounting without a discussion.

As a software engineer you know that it would require truly terrible coding for a bot or machine translation thingy to get confused by the addition of a section.

Lengthy discussions do not distract from the content, they are the meat and potatoes of any !vote. A lot of things on those pages are actually unimportant and could be removed, but not the discussion section.

@JWheeler-WMF: can i has "approval"?

The WMF desperately needs feedback, both positive or negative (what to do and what not to do). Goodwill from volunteers is not a resource anyone can afford to waste.

If this is a community wishlist the wishes of the community should be front and center. So let them express their points of view.

Polygnotus (talk) 20:40, 29 August 2024 (UTC)

Hi @Polygnotus - thanks for all the discussion today. I'm responding here to a number of the points you've raised on various topics.

We've instituted focus areas, based on WMDE's successful rollout, as a response to the challenges and feedback regarding previous wishlists. Specifically, the Community Tech team cannot respond to enough individual wishes, and the movement needs to chart a new way. We need more involvement from teams across the foundation, and involvement from community.

Focus areas summarize a problem articulated through wishes. Volunteers may vote on focus areas and discuss them - either through their vote, or on the talk page. When a team prioritizes a focus area, they are prioritizing the problem to solve, validated by communities. It's possible the team may fix each wish, but it is more likely that the wishes will inform this work, and that not every wish will be solved 1:1. And, teams may also adopt individual wishes, put them on their backlog, and prioritize accordingly.

I understand your desire to foster more conversation by exposing discussions on an article page; we made a deliberate choice to help people engage with focus areas without being too bogged down. It's possible we adjust this moving forward, and we'll keep listening.

We're in the early days of the new wishlist, I am new to wiki-culture, and I'm still learning. Our wishlist is new, we're still feeling out what's missing and what needs to change, and we are listening. For example, we realize there's a need to signal interest in individual wishes. As we continue to solicit feedback, I'd encourage folks to act with respect, and provide feedback in a constructive manner. JWheeler-WMF (talk) 21:43, 29 August 2024 (UTC)

@JWheeler-WMF: Community Tech team cannot respond to enough individual wishes, and the movement needs to chart a new way Agreed. The WMF should be a software company, and its main focus should be developing and improving software. Most of its budget should be used for that goal. That means the budget for your team should increase drastically.

it is more likely that the wishes will inform this work, and that not every wish will be solved 1:1. It is completely impossible that every wish will be fulfilled 1:1. They are wishes and magic is not real. You cannot read minds. No one expects them to be fulfilled 1:1.

If we have 2 wishes and one receives 51% of the votes and the other 49% of the votes, and they are in 2 different focus areas, then the "focus areas" are not helpful.

I am new to wiki-culture, and I'm still learning. Welcome! We are all still learning. The reason that I am here is to learn. One of the best decisions ever made on Wikipedia is that !votecount is not the deciding factor when decisions have to be made. For example, in the Article for Deletion discussions you'll find that admins are explicitly instructed to value good reasoning and policy based arguments more than simple "per nom" ("I agree with the person who nominated the article") votes. The downside is that a lot of bytes are wasted having pointless discussions. The upside is that the community managed to write 6 million articles, sometimes about very controversial topics, without bashing eachothers head in.

I understand your desire to foster more conversation by exposing discussions on an article page; we made a deliberate choice to help people engage with focus areas without being too bogged down That is a mistake. Allowing people to make an informed decision and weighing the pros and cons does not bog them down. The community wishlist can be a very valuable tool, but community participation is required, and that must include discussion.

provide feedback in a constructive manner Sadly, negative feedback is, for some, hard to hear. Any beginning is difficult, so people might end up in a situation where a lot of the feedback they get tells them not to do something, or to drastically change course. In that case, the worst thing one can do is to shut down and stop listening. I offered to help you avoid harsh criticism because I am very good at listing the downsides of any plan. As a consultant I often have to tell people why their ideas won't work. I also offered to ask a handful of very smart and experienced people what they would like as a wish. The current wishes are, on average, not great and the hope is that, by inviting very smart and experienced people the standard can be elevated.

I highly recommend writing an article. Even a stub. It is a great way to learn and experience Wikipedia. Polygnotus (talk) 22:12, 29 August 2024 (UTC)

Several issues with the Focus areas

• People may largely vote based upon the focus area title or upon its title and description but not (or much less) upon the actual proposals included in it.
• Mere vote-counts may be somewhat misleading or insufficient, e.g. some users who voted aren't really active Wikimedia contributors.
• Some Focus area titles are somewhat unclear or slightly misleading, e.g. "Make it easier for patrollers and other editors to prioritize tasks" (or "Task prioritization") is not only or mainly about prioritization (sth like "Task efficiency" or "Task organization" or "Task consolidation" may fit better) and "Help content reviewers more efficiently manage their repetitive tasks" sounds really great by its title but only upon closer inspection it seems like several tasks I would think of as being included there are actually in the former focus area and checking one's watchlist is not considered a "repetitive task" in the definition/scope of that focus area as one would think.
• Especially for the Template recall and discovery focus area lots of editors were notified and linked to this area which wasn't the case for the other focus areas. I think that's fine but it somewhat skews the results and maybe one should either only link and talk about all focus areas at once at other places like Wikimedia Commons VillagePump or also present the other focus areas which hasn't been done so far.
• Each of the focus areas may (probably) miss some existing proposals (as well as potential ones). Lots of potential Focus areas are currently missing. The proposals per Focus area are also not integrated in any way into the focus area such as by describing how each proposal relates to the topic and to the other included proposals and so on.

Prototyperspective (talk) 16:15, 17 September 2024 (UTC)

Constructive use of AI in Wikimedia as a Focus area?

Is this a potential focus area? I thought it would become a focus area due to all the talk about AI in recent years within the movement (e.g. see all those videos here) which is one of the reasons why I submitted several AI-related proposals. Maybe focus areas created later will not get much attention anymore so I wonder why there's only four focus areas by now. It's also a problem field in the sense "How can we harness AI in constructive ways to stay relevant, increase our presence, and be resilient against AI (e.g. potential competitors using AI) and benefit from the recent and ongoing progress?" – it's not less of a problem than "Template recall and discovery" but maybe it's too broad (what about subfocus areas)? Would this deviate from how Focus areas were intended or is there some related focus area pending? I think it makes sense to bundle AI-related proposals in some way and address and think about them also in combination, for example because several tools could be used for several applications and so on. Prototyperspective (talk) 16:23, 17 September 2024 (UTC)

I think the application of AI is more solution-driven and we want to instead identify the right problems where AI could help. We anticipate the repetitive tasks focus area, for example, may benefit from constructive AI suggestions. JWheeler-WMF (talk) 20:19, 25 November 2024 (UTC)

Increasing the value of content, e.g. by making it more available in different more interesting formats and across languages I think would be the key application since it could roughly double the Wikipedia readership/reads in a short time, if not more. So I'll wait until adding categories becomes possible to add a relevant category to the AI-related wishes. Prototyperspective (talk) 22:36, 25 November 2024 (UTC)

Previous wishlists

Should previous years' wishes be re-submitted? And what about new feature wishes submitted at phab:, do they all get the same treatment? pon_or (talk) 12:03, 1 October 2024 (UTC)

@Ponor - I recommend submitting a new wish for previous wishes. Though some have already been submitted year over year, we will look to this new wishlist moving forward. Similarly, while Phab is one way to submit an idea or request, the Wishlist is also a good place to voice ideas. JWheeler-WMF (talk) 13:23, 4 October 2024 (UTC)

Update?

Can we expect any changes to how the Community Wishlist is run (or consultation thereon) anytime soon? Nardog (talk) 00:53, 11 October 2024 (UTC)

Hey @Nardog thanks for the question. We've made significant changes to the wishlist since July 15, including making it open year-round, introducing focus areas, and gathering community feedback via focus areas.

In the next few weeks, you should see more focus areas published and open for supporting and adoption of a couple focus areas by WMF teams. We hope and anticipate that the Foundation will adopt multiple focus areas as part of our 2025-26 annual plan.

You may be suggesting that there's been a lag in fulfilling wishes. The Community Tech team has been focused on Multiblocks, responding to feedback on Edit Recovery, and our next project - Favoriting Templates. In addition, we've built a gadget for users to translate wishes leveraging machine translation.

We invite technical contributors to identify and adopt wishes, and we're working to identify "smaller" wishes for volunteers and teams to address. At times, even the simplest wish on the surface may be quite complex, given the variations of behaviors and policies across wikis, or a simple wish may not align to a broader product or technical objective.

Of course, we value feedback and are keen to learn how the wishlist can better serve the needs of our communities. JWheeler-WMF (talk) 02:20, 11 October 2024 (UTC)

Thanks for the prompt reply. I was mainly wondering about how the wishlist itself is run.

Can you give us when, however ballpark, we can expect any of the feedback we've given you, mostly on this page, will be acted upon? E.g. bringing back categories, a solution field, voting on individual wishes (which you've said "there's a need to signal interest in"). Or are you saying they've already been declined?

Like, do you not plan to review how the new system has run and how it should be improved on a specific date? (I'd be surprised if you didn't.) Or is it just going to run this way indefinitely and changes to it will be made sporadically/whenever you see fit? I ask because I want to know if we can expect any of our feedback, if found reasonable, will actually be implemented (if not, why bother). Nardog (talk) 07:44, 11 October 2024 (UTC)

@JWheeler-WMF: I gotta say, receiving a reply within two hours and then being ghosted for ten days does not give one good vibes. Inconsistency can be more frustrating than indifference. Nardog (talk) 11:07, 21 October 2024 (UTC)

More or less I share your concerns. However, I don't think the issue is with how the Wishlist is run. Please look at the track-record and historical data of past Wishlists – most of its proposals are still unsolved. The problem is not with the Wishlist but with the lack of technical development or lack of tech dev capacity building. I made several concrete specific readily-adoptable proposals to address that here. If one is interested in seeing proposals get actually implemented then it needs more development-capacity and such doesn't appear magically. More important than expressions of support are contributions to how things can be implemented and so on anyway. A further idea not in that list is that a fund outside of WMF is created where people can donate instead which gets spent exclusively to run tech development campaigns about solving code issues etc. Prototyperspective (talk) 13:43, 21 October 2024 (UTC)

I fail to see the pertinence of your comment to my questions and what "concerns" of mine you claim to share. Nardog (talk) 19:05, 21 October 2024 (UTC)

I share your concerns to some degree that bringing back categories, a solution field, voting on individual wishes are missing. I however added that these things are pretty trivial basically, they would be nice to have but don't have much of an effect in regards to how many or which wishes are being implemented since nearly none get implemented. review how the new system has run how would you do that? What indicators would you use to assess whether it has run badly or well? Pageviews and number of wishes? What would be success there? The success of the wishlist I would argue is defined by how many useful proposals are being implemented and expressions of support are not important for that. It would be good to have but it's not critical or nearly as important as you probably think since even most-supported wishes in past Wishlists don't get implemented either. It's even partly a distraction from working on getting things implemented by letting people vote +1 or -1 instead of pointing out issues and challenges of wishes and technical ways to implement things and/or organization of implementation. I hope that answers your question. Prototyperspective (talk) 19:46, 21 October 2024 (UTC)

The idea of the focus areas is to get more wishes done, as it's easier to focus on the same code base for a while. This does require more similar wishes to be grouped than now I would reckon however. Femke (talk) 20:15, 21 October 2024 (UTC)

1. Focus areas are not about the same code base but about the same problem where this synergy or focus benefit does not exist 2. Instead, when it comes to implementation, focus areas could be useful for addressing the same problem area via different approaches where one can combine them or better see alternatives, implications, etc and focus on the actual problem rather than things that appear nice to have (but e.g. may not be impactful or efficient or best in regards to the problem) 3. Even if they would increase implementation, which they don't and afaik also aren't about, the difference would be negligibly small. Prototyperspective (talk) 20:21, 21 October 2024 (UTC)

The Commtech team has finite resources and is currently focused on Multiblocks. We have scheduled time to discuss categories/tagging and reintroducing some form of "support" mechanism for individual wishes. JWheeler-WMF (talk) 19:36, 21 October 2024 (UTC)

Thanks. Is that a "no comment" for the rest of my questions? Nardog (talk) 20:33, 21 October 2024 (UTC)

We believe the feedback around categories, tagging, and supporting individual wishes is valid, however given the team's focus on Multiblocks, we can't stop what we're doing and implement every change. As such, we need to plan for appropriate solutions and carve out time in our roadmap. I wish I could have an end date in sight, however we must prioritize improvements to the wishlist against CommTech's ability to focus on wishes themselves. If I had a specific date, I'd be happy to provide it. JWheeler-WMF (talk) 20:41, 21 October 2024 (UTC)

I also asked whether you have a specific date to review how the wishlist has run. Nardog (talk) 23:08, 21 October 2024 (UTC)

What about this yes–no question makes it so difficult to answer? Nardog (talk) 15:02, 23 October 2024 (UTC)

Hey Nardog, the CommTech team routinely reviews how the wishlist is running, however we do not have a specific date to publish a review.

Thanks JWheeler-WMF (talk) 15:05, 23 October 2024 (UTC)

Thank you. I was being only half-rhetorical in the last question though. Arbitrarily answering some questions and not others makes it feel like you're deliberately stalling us. Occam's and other razors tell me you're not but the effect is the same. Nardog (talk) 16:02, 23 October 2024 (UTC)

@JWheeler-WMF how did "favoriting templates" get chosen by the Comtech team as a focus team? It also seems like there has been a substantial reduction in editor feedback compared to the old system and I'm unsure how to participate in this new system which is perhaps more widely shared and explains some of the decreased involvement. Like I'm supposed to support focus areas, but one of those has already been chosen (maybe this was chosen because of the voting?) so what am I supporting? Thanks and best, Barkeep49 (talk) 19:41, 23 November 2024 (UTC)

Hello @Barkeep49, before Jack comes in, here is a participation/engagement workflow for your consideration:

After submitting a wish or arriving to support the wish or focus area review process:

• Visit the list of wishes (which are presented in the order of the most recently edited wishes)
• Based on your experience in the wish topic, you can evaluate the wish, and in this process you can comment on the validity or otherwise of the request. Where a feature has already been implemented (unknown to the submitter), you can also mention this. If you have more information (e.g. additional context) to add, please do.

When you approach the list of focus areas please note that:

• Templates area was created based on past voted wishes from previous Wishlist edition to use as a case study on how focus areas can work in real life (we shared this intention in our annual plan). It was one of the easiest examples of a focus area with substantial community support.

And you are right, since this is already in motion, while you can still comment or ask questions, there is no need to support.

• The following focus areas: Help content reviewers more efficiently manage their repetitive tasks, Help newer contributors understand the status and rationale behind a moderation decision, Make it easier for patrollers and other editors to prioritize tasks are focus areas we created for Moderator Tools. It is also one of those we have created to learn more about Wishlist process. It has also been mentioned in the annual plan. This may likely interest you more. I will let @JWheeler-WMF provide more details on how you can engage those, he has the latest updates.
• The rest of the areas we are scoping, e.g. Article Creation Guidance (once again per the 24/25 annual plan), we plan to submit 3+ which have received sufficient signals that they are important to the community to the 25/26 annual plan. From now till we draft the selected areas into 25/26 plans, please feel free to support any of them. We will also keep assisting the community with notifications of new focus areas so they can find them easily. At the end of the day, the support, the discussions, the disapproval, all count.

We recently updated our FAQ about focus areas, you can check it out. –– STei (WMF) (talk) 15:53, 25 November 2024 (UTC)

@Barkeep49 - I'd echo what @STei (WMF) said. When we relaunched the Wishlist, we wanted to honor some "past wishes" that would have made for a good focus area. There were a number of template-related wishes that, collectively, bubbled to the top of the wishlist. We prioritized template improvements holistically and then based on a number of conversations with the editing team, identified that favoriting templates is the most impactful and solvable problem in the focus area.

Regarding editor feedback, this is always welcome, and I'd love to learn how to elicit more responses and feedback.

Regarding wishlist engagement, we're planning to incorporate some focus areas into our next annual plan, and also plan to publish additional focus areas before the end of the year. Are there any focus areas you'd suggest or wish to see? JWheeler-WMF (talk) 20:17, 25 November 2024 (UTC)

In terms of "received sufficient signals that they are important to the community", I either don't understand how you decide this or I do understand and it's misleading to say that something is important to the community. As I understand it, Community Tech looks at wishes and based on something (comments?) groups them into focus areas. Then the community has to vote on focus areas. And then some of those focus areas are put into the annual plan. Except you got more people involved in the discussion about renaming this than in any task prioritization. And there are radically less people involved than under the old format. I don't think anything decided by this kind of elite to be representative of the community. Best, Barkeep49 (talk) 18:56, 30 November 2024 (UTC)

I agree we've seen less engagement through the wishlist than we anticipated. How do you think we could improve engagement? JWheeler-WMF (talk) 14:58, 3 December 2024 (UTC)

Perhaps actually committing to implementing the feedback you've received is a good place to start. You say you welcome feedback, but so far not only have you not acted on any of it, you haven't even made a commitment to acting on any of it. If it keeps going like this, at some point we'll figure it's not even worth suggesting anything to you and engagement will flatline. Nardog (talk) 07:38, 4 December 2024 (UTC)

In terms of engagement I recommend:

1. Encouraging the community to add {{support}} templates to wish discussions if they want. Anecdotally, when a Commons user recently independently came up with the wish iOS Commons App I directed them to visit the wish and express their support but they claimed how exactly can I support it? It does not look like and active process. [1]. The system is obviously broken in its current state.
2. Relying on the community to update the status parameter on wishes through consensus discussions. For example every wish starts out as submitted, once a discussion takes place on Talk:Community Wishlist/Status discussions it can progress to open and attract {{support}} templates, otherwise be marked as archived.

Commander Keane (talk) 08:21, 4 December 2024 (UTC)

I think Nardog refers to bringing back categories, a solution field, voting on individual wishes (which you've said "there's a need to signal interest in") when saying implementing the feedback you've received is a good place to start.

Encouraging the community to add {{support}} templates to wish discussions if they want. Two issues there:

1. I don't think this had much of an effect in the past – to some degree this active/plentiful binary voting distracts from constructive discussion about (potential) problems with the wish and about how it could be implemented technically as well as from that these wishes are not getting implemented with few exceptions. It creates the illusion of progress and activity when there is nearly none.
2. Just "encouraging" community members and signed up users to leave a short yes or no template wouldn't mean that this is actually done.

It's broken because despite of plentiful resources and finances-independent options, there is only a very small to small level of technical development and nearly no technical development capacity building like the readily-adoptable options I suggested here, not because there is little community engagement with the wishes which would be nice to have and may slightly contribute to the former but it's not "broken" because of that. It was already broken earlier and the problem is that this hasn't changed so far.

it can progress to open and attract {{support}} templates, otherwise be marked as archived. Oppose archiving wishes because of that. If anything categorize them under 'so-far little-supported wishes' accordingly. E.g. some of these may be useful to only a small number of editors (or be not so easy to understand) and as some of these may be quick to implement via some gadget some volunteers may implement them. Not a good reason to "archive". Prototyperspective (talk) 11:44, 4 December 2024 (UTC)

Indeed binary voting isn't ideal but it at least gets people to visit the talk page and perhaps read the discussion (ie engagement). Well for me it would, and looking at the multitude of voting in previous wishlists I am probably not the only one. iOS Commons App has zero comments in four months, the Commons discussion has five contributors, with some interesting implementation ideas, in four days. The wish is persistent but the Commons village pump duscussion will be archived soon and never looked at again. I am guessing support templates will draw in participants.

The point of reviewing the status, to open or archived etc is to generate more discussion (ie engagement). I don't like the archiving JWheeler does currently, indeed I suggested no closing or archiving[2] in February. I created a section below (#Archived wishes) and then this wish is archived without discussion, which is a real spit in the face of the Commons community. Allowing the community to manage the status (or topic banning JWheeler, an extreme scenario obviously) would aid engagement - the community can decide to avoid archiving at all costs if desired.

I agree that the carrot approach of actually delivering wishes would drastically aid engagement, the current stick approach of "we are only going deliver the focus areas with the most votes" doesn't seem to be working (and is a bit scary to be honest).

Finally, I am not too concerned with lack of technical resources. I accept it is not great, but the wishlist can still be useful as a discussion place - if engagement is increased. Commander Keane (talk) 14:46, 4 December 2024 (UTC)

Commons Village Pump is watched by many people and the nearly only general central place to discuss project matters so it's not comparable and a reason why I'm seeking to consolidate activity on that page more so that people don't put questions like 'what does this one random image show' on that place. If voting was enabled that doesn't mean this many people would provide constructive comments. The issue about iOS is also in the GitHub repo of the Commons app as an issue. I think the points you made are good but not for doing what you suggested and not refuting my concerns. I think something similar to status could maybe be a good thing like 'Community priority' or preventing archiving / unarchiving if people disagree with good reasons. One further thing to mention is that this Wishlist is not only for WMF development but also volunteer development who could pick up any wish they find important where I think it would be the responsibility of WMF to encourage and facilitate that to at least a minimum extent. the wishlist can still be useful as a discussion place doesn't make sense to me as we're not discussing for the fun of it because we consider wishes important, useful or problematic but if they aren't implemented all of that is just a waste of time and meaningless chatter. Prototyperspective (talk) 16:07, 4 December 2024 (UTC)

Thanks @Commander Keane and @Prototyperspective for the constructive comments. There's a few points here, which I'll try to separate into distinct threads.

RE: Wish status. All submitted wishes are marked as submitted because they need to be manually marked for translation with translation markup. Adjusting a wish's status to "open" applies the translation tags to the wish. One alternative is to show that all wishes are "open" immediately, however that is a burden on translators who may be translating incomplete wishes. I agree this process isn't perfect. As we advance the wishlist, I'd love to start showcasing a dashboard like the "Request Status" that Square shows.

RE: Archiving wishes. We will continue to archive wishes that speak to policy matters, primarily, or when they don't make sense. I don't think wishes should be archived because they are "too big." Rather, wishes should be assessed by the painpoint the wish aims to address, not by the effort required to solve the solution.

I think there's two extremes for archiving wishes. And, I think the way in which we archive probably falls between these two extremes.

- On one extreme, wishes should never be archived. In this context, all wishes are "valid" ideas that should always be up for prioritization. The tradeoff is that as we amass more and more wishes, we will likely incur "decision fatigue" by re-reviewing wishes that might not be relevant.

- On the other extreme, new wishes should be quickly archived if WMF or volunteer developers don't see the wish as strategic, it doesn't have potential solution, or if it is too niche. The tradeoff is that as we get towards planning and prioritization, we'll miss the collective zeitgeist from the community at large.

Regarding the specific wish, we viewed this as a policy matter vs product.

RE: Categories and support /voting templates. Both of these ideas - allowing volunteers to categorize and support wishes individually - are valid, and we want to do this. These are in our backlog, however CommTech has been working hard at delivering Multiblocks for some time. Once we complete it (Jan/Feb), I expect us to prioritize some of these wishlist improvements (Feb/March).

Regarding support, I caution that a support template can be seen as a de facto popularity contest; when we prioritize wishes, we look holistically at the skillset of a team, the movement strategy, feasibility, etc. We cannot always prioritize the most popular wishes or focus areas, and that risks disappointing some volunteers. TLDR; I agree support templates are useful, and I agree that the conversation around wishes is most important. JWheeler-WMF (talk) 16:17, 4 December 2024 (UTC)

@JWheeler-WMF: How difficult is it for the community to start categorizing sooner? Use the new categories as normal categories (such as Category:Community wishlist/Citations etc. That way, your team can focus only on building the improved navigation around it when you have time.

Similarly, I don't quite know how this works with translations, but an AWB job to add a section of Voting shouldn't be that complication for the community to do? Rather than have the Wishlist stuck in beta?

I think it's well understood by the community that prioritization is a matter of more than voting. But it does save us from having unpopular or unfeasible ideas cluttering focus areas, as they do now. Femke (talk) 18:19, 4 December 2024 (UTC)

Bringing back categories and voting for individual wishes was suggested months ago, but you're saying they're months away at the earliest. This lack of flexibility, the inability to improvise or pivot, seems like a larger problem afflicting the wishlist in itself, if I may try to find one (as you seem fond of doing). And flexibility is one of the primary reasons Wikipedia is more successful than Encyclopædia Britannica or Citizendium. Nardog (talk) 08:44, 6 December 2024 (UTC)

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.

Screenshot demonstrating how to turn on Wishlist Translation

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.

–– STei (WMF) (talk) 15:47, 16 October 2024 (UTC)

Maybe similar to the intake problem (or maybe not), zh variants don't get fallback to use WishlistTranslation in zh. I understand MinT doesn't support all Wikimedia languages yet, and fallback isn't exactly for this use. Would it be possible to have a dropdown to choose the destination language? Cookai🍪 _(💬talk) 03:22, 25 October 2024 (UTC)

Great! It's very useful. However, I think if the page has a (fully) translated page available, the tool should fetch the translation from there or redirect to there if enabled, e.g. here it shouldn't machine translate to English. Moreover, I find the quality of translations is substantially below DeepL and Google Translate but hopefully that improves over time. Note that with these kind of dynamics machine translations, the translations cannot be adjusted/corrected. Prototyperspective (talk) 18:24, 12 November 2024 (UTC)

Too many wishes!

I decided to go through the current list of wishes to see if I could contribute. After opening about a dozen that caught my interest based on their titles, I checked to see how many were left. To my surprise, the list just kept going. At that point, I gave up reading altogether. I really think we need to make the list more manageable, as its current form makes it almost impossible to navigate effectively. - Klein Muçi (talk) 10:23, 21 October 2024 (UTC)

So true! There are 315 wishes currently. I would recommend allowing the community to add categories (just the usual system nothing fancy). The previous Wishlist had these I believe:

• Admins and patrollers
• Anti-harassment
• Bots and gadgets
• Citations
• Editing
• Miscellaneous
• Mobile and apps
• Multimedia and Commons
• New contributors
• Notifications
• Watchlists and Talk Pages
• Reading
• Search and Categories
• Translation
• Wikidata
• Wikisource
• Wiktionary

Commander Keane (talk) 10:54, 21 October 2024 (UTC)

Thanks @Klein Muçi and @Commander Keane we're evaluating how to restore categories or tagging in some capacity. Stay tuned! JWheeler-WMF (talk) 20:25, 21 October 2024 (UTC)

@JWheeler-WMF, I believe I read on Phabricator that the category implementation will only allow WMF employees to define categories. Although I would suggest a community editable JSON file instead I understand that it may be faster to develop a closed solution. In that case, may I suggest discussing here the potential categories that will be able to be selected rather than springing a potentially unsuitable set right into production. I am assuming it will be modelled on the list a presented above, with modifications. Commander Keane (talk) 14:56, 4 December 2024 (UTC)

@Commander Keane the categories we've defined for our wish assessment process is:

Abuse, Accounts, Categories, Citations, Codex, Commons + Multimedia, Community Connection, Content moderation, Developer support, Editing, Mobile, Newcomers, Patrolling, Reader, Search and discovery, Sibling projects, Templates, Translations, Wikidata

I'd welcome any suggestions to improving these categories. At this time, we want to keep the bucketing fairly broad. JWheeler-WMF (talk) 15:52, 4 December 2024 (UTC)

Looks good.

In terms of making the categories more understandable, would it be better to rename mw:Codex into MediaWiki? And sibling project could be smaller projects (I assume this is everything non Commons/Wikidata/Wikipedia)? I tried to categorize the 2023 wishes wishes, and mainly managed, only struggled a bit with those listed as misc. For instance, the syntax highlighting. Community connection probably risks attracting out-of-scope wishes, but it's a fun one to experiment including. Femke (talk) 18:17, 4 December 2024 (UTC)

Any Wikimedia project is a sibling project of any other. "Sibling projects" is meaningless (unless you mean all projects besides Meta). If you mean all projects besides a particular one, then that's language that centers it and relegates the others, which is objectionable. Nardog (talk) 11:41, 9 December 2024 (UTC)

Archived wishes

It would be helpful if people could monitor Community Wishlist/Archive for wishes that could benefit from further discussion.

So far I found four (1, 2, 3 and 4) that could do with discussion, development or at least an explanation to the creator as to why they were archived.

If someone goes to the effort of making a wish we should repay that effort with some work on our part. Commander Keane (talk) 01:41, 26 October 2024 (UTC)

Thanks @Commander Keane and sorry for the delayed reply. We try to have a response as to why certain wishes are archived. For the wishes you shared, I reopened one, and the others were either policy issues that we can't fix, or focused on non-Wiki use cases. JWheeler-WMF (talk) 20:14, 25 November 2024 (UTC)

"We will get back to you with further questions if need be"

Some wishes have received this message from STei, but not others. What does it mean for a wish to get this message, and what does it mean for a wish not to? Nardog (talk) 00:38, 30 October 2024 (UTC)

I plan to acknowledge every submission. However some wishes gain ongoing discussions before I arrive and sometimes, @JWheeler-WMF may have even joined or started those discussions.

And so for wishes where submitters and discussants are already busy engaging I don't usually interrupt discussions with my greeting. But that's just my thinking. If you feel this may give a wrong impression, let me know.

I have been second-guessing for a while now. I am happy to get my first feedback. –– STei (WMF) (talk) 14:34, 30 October 2024 (UTC)

But you don't seem to acknowledge every submission even if it hasn't received any discussion, hence my question. E.g. these were submitted in July, but the corresponding talk pages haven't been created.

• ALLE nicht gefunden Links rot markieren
• Add download as EPUB
• Android app: once clicked link its pop-up appears again and again.
• Aplicar IA en las sugerencias de mejoras de artículos en la página de inicio.

If you've deliberately avoided responding to them, why? If you haven't, I suggest you be consistent and respond to all, or to none. Nardog (talk) 04:01, 5 November 2024 (UTC)

@Nardog thanks for following up and finding some omitted wishes. I will make time and drop them a note.–– STei (WMF) (talk) 18:46, 5 November 2024 (UTC)

To be clear, listed above are just the ones that started with "A". Nardog (talk) 22:50, 11 November 2024 (UTC)

I am not sure if it is a good use of time for STei, or any other WMF employee, to be dropping notes on every wish. But maybe they have time to burn. If the community thinks it is a good idea for every wish to get an initial comment (so the wish creator knows at least one person has read it) surely we can take care of it ourselves. I can see the counterpoint that it is exciting to have WMF engagement, but real engagement goes far beyond a simple thanks. Commander Keane (talk) 00:55, 12 November 2024 (UTC)

I'm inclined to agree. Boilerplate response can feel cold if not annoying. Nardog (talk) 02:36, 12 November 2024 (UTC)

Got to say I'm inclined to disagree except if significant resources are burnt for this. Nothing is more frustrating and annoying to not even get some kind of feedback. Thus, a small edit, a thanks, or a simple recognition message are all better than that. At the same time, having talk pages cluttered with unconstructive messages is more problematic than anything else so it should be limited to one of that type. Many users don't know this is a boilerplate message. It's worth more if it's not added to every wish but only to those that e.g. are sufficiently coherent (and readable due to no large language barriers) to be understood by the person but if that's not the criteria then it's not ideal but at the same time kind of unimportant. Consider that leaving a brief note on an existing talk page is done more readily by users than creating a new talk page so overall the Pros and Cons to doing this are kind of even, I don't think it's worth discussing much. Prototyperspective (talk) 18:34, 12 November 2024 (UTC)

Why was task prioritization chosen?

While there aren't enough focus areas yet to properly start voting, it seems like one of the focus areas has already been chosen as a Community Wishlist priority (Wikipedia:Administrators'_noticeboard#Task_prioritization. Why was this one chosen and when can we expect enough focus areas to provide tangible input about community needs? Femke (talk) 21:12, 25 November 2024 (UTC)

Hi @Femke - the Moderator Tools team has a goal to increase user satisfaction of 4 moderation products by 5pp each, and had decided to leverage input from the Community Wishlist to inform prioritization. This focus area aligns to the moderator team's goals, hence their prioritization of this focus area.

I should restate that voting on a focus area is one of many signals that inform prioritization. We welcome community support and feedback on all focus areas.

You did ask about generating enough focus areas to provide tangible input on community needs; what would you think is a reasonable number? JWheeler-WMF (talk) 21:38, 25 November 2024 (UTC)

I plan to start voting when most individual wishes are either archived or in a focus area. I'd like to see where my wishes end up before submitting more. I must say, I kind of dislike the nebulous "one of many signals" here, which feels more subjective than the previous weighting of votes, priority communities and technical feasibility. Femke (talk) 21:46, 25 November 2024 (UTC)

My unspoken question: is this the goal of the team? To have a majority of non-archived wishes in a focus area? Femke (talk) 17:21, 4 December 2024 (UTC)

Wishlist report generated. Voting on individual wishes encouraged.

I have just refreshed my report listing wishes: User:Commander Keane/Wishlist report.

It counts support templates on wish discussion pages. For my own curiosity (and perhaps the community!), I would encourage everyone to to vote on individual wish discussion pages (ie adding {{Support}}).

Benefits of the report:

• You can sort based on the creation date of wishes.
• You can see how many edits to the discussion page of wish, especially important to spot neglect.
• You can spot wishes that have not been translated to English.
• You can see the support votes for individual wishes. I think you will be able to sort by focus area and see most supported wishes within a focus area.
• Archived wishes are not segregated.

The code to generate the report is messy, unstable, poorly tested and time-consuming to run (any assistance appreciated). But it works for now and I am desperate. It is saved here. If you can run a pywikibot script you can run this report (it currently saves a local text file, no editing to a wiki). It may choke when seeing something unexpected, and I am not guaranteeing the accuracy of anything - including vote counting. It took me 22 minutes to run this morning, so not ideal. I am happy to run it periodically if there is community interest (or someone else can run it). It recognises various support templates in multiple languages. Commander Keane (talk) 00:03, 10 March 2025 (UTC)

Hey Commander Keane thanks for sharing this report. This list is really cool to look at, especially the ordering by number of comments and the created-at date.

Our annual plan goal for 2025-26 is to improve the process by which we respond to Wishes, in part because a number of wishes still have the "submitted" status which has generated confusion. I'd love to discuss your thoughts on how we improve the wishes, and invite you (and/or anyone else) to join me in a conversation: https://calendar.app.google/LoJ3H3UGNEJs7TUA7 JWheeler-WMF (talk) 18:42, 10 March 2025 (UTC)

Could bring it down to about 10 minutes. --Matěj Suchánek (talk) 19:54, 10 March 2025 (UTC)

@JWheeler-WMF, I don't think off-wiki discussion is healthy. If you insist on 1:1 discussions then the community could appoint a representative (essentially unionise, which is vital to fight oppression and abuse of workers in real life but I haven't seen it used on a wiki before). Then we can have a community discussion in a section below raising all our concerns (please provide your 1:1 talking points ASAP so we can prepare). Then the representative can speak to you (not recorded I assume, so we have no idea what was conferred and understood). Or we can do it on-wiki. I do wonder if that when you invited me for a 1:1 chat in March 2024 about the WMF early thinking about the new wishlist and I declined if someone from the community did take up your offer and said "we hate being able to vote on wishes, we hate being able to categorise wishes but we love the WMF intervening with the wish process."

On the WMF intervening with the wish process point, which is exemplified in the mysterious "submitted" process that you want to discuss, my view is that should be zero WMF interference in the wish process ("Community Wishlist..." not "WMF Wishlist"). I imagine this is an outlier view and I am not suitable for 1:1 discussion.

Incidentally the things I think are currently crippling the wishlist are participation and prioritisation, you may like to discuss those at some point. I know my comments may seem abrasive, but at the end of the day as a volunteer I just want a functioning wishlist. And I know you do too :-). Commander Keane (talk) 22:23, 10 March 2025 (UTC)

Ability to support individual wishes

There is not currently a mechanism for users to support an individual wish. Although anyone is able to add a {{Support}} to a wish's talk page (see section above, I am personally interested in this) this has been actively discouraged by the WMF in the Community Wishlist instructions, FAQ and talk page comments. Instead, focus areas are the designated place to "vote".

As far as I can tell no task has been submitted on Phabricator for a software implementation. When the new evolution of the wishlist arrived I assumed the WMF had a good reason to discourage individual wish support. I am still waiting for the explanation.

I would like to make a distinction between voting and supporting. w:Voting says "Voting refers to the process of choosing... policies by casting a ballot". There can be no ballot (a set of items to prioritise) in a continual uptake system. Instead, we can support the wishes we like and ignore the ones we do not. I liken it to donating $100 to charity. You "support" the current ones that align with your goals by giving them money and ignore the irrelevant ones.

I would also like to note that we need a mechanism to prioritise individual wishes once they become focus areas anyway. Do you highly value software development into adding user icons for talk pages and native instant chat in MediaWiki? These are currently two out of the five ideas in the focus area Connecting Contributors which has made it in into the WMF annual plan draft and presumably be heavily funded in 2025-2026.

Reasons to promote support of individual wishes

• Supports can indicate priority. I am not saying that they are ideal for prioritisation, but it is something. This can guide focus area selection and point out wishes that are desired and thus need extra discussion.
• Warm fuzzy feeling. It feels to good to come together and agree on something. It feels good to submit a wish and see that others like it. If you cannot support a wish yet you may help develop it into something better. If you see a wish with a concept you really like but a poor technical solution in the title you may submit a new, better wish. All of these things...
• Promote participation (see above bullet point).

Reason to prohibit support of individual wishes

• Culture of "no-vote" in the movement. I explained above why it is not voting. And hypocritically, focus areas promote supports. You could encourage supporters to add a meaningful comment on why they are supporting something, I would love people to take the time to do this. Or you could discourage "Wish supporters" sections on talk pages that quell opposition discussion (and likewise the "Oppose" sections that make me uncomfortable to support a wish). However I do not expect a Commons admin with 10 years experience to explain in their non-native language why a crucial feature that is supported by 40 others needs to be developed.
• A user's support can become stale. A user may change their mind on an issue, or technology can change. A support in 2001 for a workable MediaWiki discussion system may have changed with the introduction of Talk pages, DiscussionTools etc.
• Runaway support. It is possible that hundreds of people support a wish but it cannot be implemented for legal reasons. A single oppose can be more important than 42 supports. However, a wish is not by default implemented by a support count. Users will need to understand this.
• Public relations. The WMF may be embarrassed that they do not have the resources to fulfill a highly supported wish and community members may be frustrated that a wish seemingly gets ignored. Both sides need to grow up if this is the case.
• WMF control. Probably related to public relations. The WMF may want to control wishes that are too difficult to action, wishes that suggest disabling a WMF designed product or wishes of a non-technical nature. With no indication of support it is easy to archive a wish and never speak of it again. If an archived wish is the most supported out of all submitted wishes it is harder to ignore.
• Too much participation can stress the software.[3]

In summary I  Support encouraging support for individual wishes. Both implementing it in the software (just like focus areas) and rewriting the Community Wishlist page and FAQ instructions. Commander Keane (talk) 01:57, 12 March 2025 (UTC)

Technical question: naming of wishes

@JWheeler-WMF, maybe Cparle will know the answer to this one...

Will the url/wikilink naming of wishes using the user-specified MediaWiki page title always persist? Or will a numbered system like Phabricator tasks eventually be adopted?

For example will I always have to link to Community Wishlist/Wishes/Matrix chats && mentor institute by this wikicode even if I modify the content of the wish into "Real-time chat" and fork off the "Mentor institute" part to another wish.

I know there is a translatable title field, I am just referring to the MediaWiki title and its prominent display on the wish page.

I understand that the current gadget is getting ported to an extension and I wondering if that will solve this issue with numbered naming like Community Wishlist/Wishes/W357351.

The problem I am trying to solve is dealing with wishes that have limiting solutions or multiple ideas in the title. Commander Keane (talk) 05:05, 13 March 2025 (UTC)

Can't fully answer it but:

• If the wish is moved (renamed), then I think the page should redirect to the new title instead of being turned into a broken/red-link so the link would still work
• The phab code issues are what have numeric IDs, ideally the wishes should have a phab code issue if they're viable from where the wish could be linked
• One can use the Link Shortener to create a short link with an ID, e.g. https://w.wiki/DQdf for your example

If it's (only) about the two problems you're trying to solve, I think these 3 things solve it. Prototyperspective (talk) 13:44, 13 March 2025 (UTC)

The problem I am trying to solve is when the contents or ideas of a wish are edited and the page title is no longer representative. Commander Keane (talk) 21:28, 13 March 2025 (UTC)

What about moving (renaming) the page – that would be the normal solution
Prototyperspective (talk) 19:21, 16 March 2025 (UTC)

Oh about your first dot point Prototyperspective it seems in my original post I forgot to mention that I wasn't sure if page moving would break Comm Tech bot (the "move" button is there but I assumed it was edit filter restricted) and that page moving would involve moving all translation subpages. Also multiple moves may be necessary over the life of a wish which is messy. Commander Keane (talk) 21:46, 13 March 2025 (UTC)

What is "Comm Tech bot", what is "edit filter restricted", why would "involve moving all translation subpages" be an issue, and why would "multiple moves" be a problem? Prototyperspective (talk) 19:22, 16 March 2025 (UTC)

This is just for @Prototyperspective, I don't expect anyone else to read it. I definitely was lacking in links, I will elaborate. I am explaining the the current system as I understand it and Phab:T366194 exists to port (with no new features I believe) the current system to an extension/Special page so much of this will be moot. I wasn't too sure on how much detail you wanted so I will be thorough.

• User:Community Tech bot is a user account (bot flagged) that does things to keep the wishlist operational. For example it adds a template to wish talk pages after the first comment (example history). From memory, it does other wishlist things you can read about on its user page. I don't know if moving a page will impact its work.
• The mw:Abuse filter (I still call it by its old name "Edit filter") will stop an edit/action from being saved. For example a cross-wiki upload using the "Insert file" button on a Wikipedia article, if I am reading it correctly, will fail for new users if the user doesn't have 50 edits or (auto)confirmed, the filesize is really small or the file isn't larger than 2 Mpix. By restricted I meant that a filter would simply not let a move of a wish to take place, but I haven't tested it. I just tested random category addition to a wish and that worked, so there may be no Abuse filters set. Editors can traditionally categorise wishes if they like, I assumed it wasn't possible - learn something new everyday I guess.
• Currently wishes exist at a base page in the original editor's detected language (note they sometimes write the wish in English regardless) and a subpage is created for each translation. For example Bedre støtte til skjemaer has /en, /ko and /sv pages for it. To move a title I assume all these associated pages should be moved. That is four moves in this case. Before moving do I ask a Norwegian speaker to translate my new title suggestion from EN to NO for me so can I fill out the move form correctly? If I make a typo that is eight moves, and if a better title is desired twelve moves.

Unlike Wikipedia with its strict naming conventions I expect multiple changes in a title of a wish.

The meaning of the base title shouldn't matter as editors can define a "title" template parameter in the edit box (I think this is what shows up in the list of wishes and focus areas), but it is strange to wikilink to a wish (and see the original page title at the top of the page) like Migliore accessibilità (en: "Improve accessibility") when this title inappropriate (in this case generic). Or really long links are needed like ビジュアルエディターでの出典追加時の「再利用」で、特にGoogle BooksなどのURLから再利用の参照をできるようにしてほしい.

Surely the base title should be numeric, like Phabricator (where title changes are commonplace, and that is a monolingual environment...). There must be some technical impediment, but really the focus should be on getting categories up and running. This page name issue can be dealt with later. Commander Keane (talk) 21:51, 16 March 2025 (UTC)

Thanks for your explanations. It's nevertheless still unclear whether page moves are possible or not. I haven't seen you ask about it and I think they're possible. On Commons moving pages that have translations is also possible. I think wish page title moves should be possible. Prototyperspective (talk) 10:14, 17 March 2025 (UTC)

I think you need have translationadmin rights to move translatable pages. We can assist you with that, if needed. You are otherwise free to move wish pages as you deem appropriate. There are no AbuseFilters preventing this. I haven't tested it either but I don't think the bot will care. The upcoming extension will continue to use wiki pages just as it does now, but there will no longer be a bot powering the Wishlist. Note also translatable pages with over 500 translations cannot be moved at all without sysadmin intervention – which my team can also assist with, but it's not something I think we would want to do regularly. We haven't considered using numerical autoincrementing page titles, but I think it's fine solution to address this problem. MusikAnimal (WMF) (talk) 22:33, 17 March 2025 (UTC)

Thanks for clarifying!
I think wish title moves are relatively rare and would prefer wishes with titles since these can be descriptive when linking the wish somewhere. However, I think page titles should also be translated if possible so instead of linking Community Wishlist/Wishes/إفراغ الملعب/en one could link the wish with English title. If and/or as long as that's not possible I'd still think wishes with descriptive titles are better than numeric / IDs even if some are in a language one doesn't understand (and there could be numeric redirects in addition). It wouldn't be an issue if a page preview popup showed the wish title for links with numeric titles. Prototyperspective (talk) 23:04, 17 March 2025 (UTC)

@MusikAnimal (WMF) if wish pages are going to exist as usual then could {{Community Wishlist/Wish}} be modified right now to add a "Category" parameter so that we can add, for example, "category = Commons + Multimedia" to wish pages? I understand they won't show up on wish pages yet and typos will fail later but with 300+ wishes it will easier to start to chip away at the task now rather than wait. Also, my report could incorporate them ;-). And while I have you, could {{Community Wishlist/Support}} be modified to display support/comment/signature? Signatures always come after a comment in my experience, which is not the behaviour seen at votes pages, example. Commander Keane (talk) 21:55, 18 March 2025 (UTC)

On that note it would probably be good to make the set projects under "Related projects" also set a category for every project included there somehow (ideally that cat is editable so the page subcategorizable). Regarding signatures, there also is some rationale to put the username first since the comment length varies and this shows the user-links neatly beneath each other (possibly solvable with a linebreak but would look weird and I don't see a need for that change). Prototyperspective (talk) 00:01, 19 March 2025 (UTC)

Categories for wishes has been spec'd out at phab:T377980, but with the requirement that a wish only belong to a single category. This questions the use of MediaWiki categories to serve this purpose, since those are intended to have a one-to-many relationship. We haven't revisited this task but I suspect we will when we tackle the extension.

I believe we have the vote comments formatted as you see it to prevent conflicts with mw:DiscussionTools. MusikAnimal (WMF) (talk) 00:27, 19 March 2025 (UTC)

@MusikAnimal (WMF) there is some confusion with the terms "categories" and "tags". phab:T377980 seems to be about a new tag system for wishes, unlike mw:Categories. Would it be possible to rename the phab task to "Wish tags" not "Wish categories" if you agree? And then my question above becomes: can you modify {{Community Wishlist/Wish}} right now to add a "Tags" parameter so that we can add, for example, "tags = Commons + Multimedia" to wish pages? Commander Keane (talk) 01:36, 19 March 2025 (UTC)

This questions the use of MediaWiki categories to serve this purpose Why? Couldn't you just code the template/bot/extension/whatever to add any wish page to only one of the wish categories? And even prevent manual adding of them via a bot or edit filter? (Which isn't to say that a tag system wouldn't be better than a one-to-one category system.) Nardog (talk) 12:24, 19 March 2025 (UTC)

Brainstorming subpage

Would it be ok to create a brainstorming subpage for wish ideas, at Community Wishlist/Brainstorming?

I would like to submit some wishes but I think discussing the ideas first and formulating a better version before submission would be more productive.

This is important because wish titles can't easily be changed and there is a culture of ownership of wishes where editors are scared to edit a wish once submitted.

I think every wish should go through peer-review/brainstorming before submission, but language differences may make this uncomfortable for some. Commander Keane (talk) 21:37, 13 March 2025 (UTC)

Sure, or maybe create a sandbox page and then link to drafts as a new topic on the talk page? Either way, go for it! JWheeler-WMF (talk) 21:40, 13 March 2025 (UTC)

Adding a traditional category (not tag) system for wishes

Prototyperspective suggested above a complex category/tag implemenation based on related projects listed on a wish eg (Wikimedia Commons, Wikipedia, etc).

As an alternative may I suggest setting up a regular category tree for wishes. This would allow multiple categories per wish, subcategories and different options than the single tag system (discussed above) that it can coexist alongside of.

This would take no technical development and could be started now (as far as I can see).

Examples could include:

• Category:Wiktionary wishes
• Category:File format wishes
• Category:Cross-wiki productivity wishes

The naming and schema needs thought. Commander Keane (talk) 01:25, 19 March 2025 (UTC)

I don't know why you think I suggested a a complex category/tag implemenation. I was simply suggesting adding categories based on the selected projects for a Wish which users can then subcategorize. This is a regular category tree for wishes and I also think it should allow multiple categories per wish.

I think the naming of the subcategories would be thought out like any other Wikimedia category that is by the contributors who create these subcategories. One would only have to think in advance about how to name the initial categories that are for the projects like Category:Wiktionary wishes vs Category:Wishes relating to Wiktionary and what to do about wishes that have "All projects" set (add the categories for all projects or just one Category:Wishes relating to all Wikimedia projects). Prototyperspective (talk) 13:21, 19 March 2025 (UTC)

phab:tag/Community-Wishlist-Wishes

Hey :) Just to check, is this Phabricator project intended to be a tag for tasks that represent a wish made on the Community Wishlist? If so, would you/CommTech have any objections if its appearance is changed to a yellow tag, to make clearer at a glance that the Phabricator project is for tracking & doesn't represent its own software component?

cc @KSiebert (WMF) as project creator. Best, ‍—‍a smart kitten_[meow] 12:57, 14 May 2025 (UTC)

Done (Karolin was out of office this week) MusikAnimal (WMF) (talk) 23:02, 16 May 2025 (UTC)

Re latest update

Improved the modules of the Wikimedia Dashboard ([…] The wish this links to doesn't have anything to do with the changes implemented or does it? I also could not find a link explaining what those changes were as with the other points where there's some phab link. Please fix this, e.g. by removing the wikilink to that wish or by specifying which part(s) of that wish have been implemented (or simply a link that explains all the changes). Btw, here is another wish about modules of the Wikimedia Dashboard. Prototyperspective (talk) 23:17, 21 June 2025 (UTC)

I've been given this link for the Dashboard improvements, but it's true that probably it's not the correct one. I'll just remove it. Thanks for the feedback. Sannita (WMF) (talk) 09:18, 23 June 2025 (UTC)

Impossible to edit a wish marked for translation

You can't edit a wish using the gadget if the wish title is longer than 100 characters including ‎<translate>...‎</translate>. Nardog (talk) 09:42, 23 August 2024 (UTC)

@Nardog, well noted, problem has been raised with the team. –– STei (WMF) (talk) 16:27, 23 August 2024 (UTC)

Unarchived since it has not been resolved. Nardog (talk) 14:14, 1 July 2025 (UTC)

I raised again the problem with the team. Can you please open a bug on Phabricator, detailing as much as possible the problem you're encountering? This will help us understand how to solve it. Thank you in advance. Sannita (WMF) (talk) 15:20, 1 July 2025 (UTC)

Sorry, I didn't realize it was fixed in the meantime. A heads-up or a link to the Phab task would have been nice. Nardog (talk) 00:52, 2 July 2025 (UTC)

Can't edit a wish

I tried to add a Phab task to this wish using the wish editor, only to be rejected with the message "Only Wikimedia Foundation staff can change the status, proposer, and creation timestamp of wishes and focus areas. Please change the fields back to their original values." I don't even see "the fields". Nardog (talk) 07:39, 23 October 2024 (UTC)

It looks like Special:AbuseFilter/355 was triggered because the proposer field contained a trailing space, which the editor trimmed. One wonders how the space got there in the first place. Nardog (talk) 07:43, 23 October 2024 (UTC)

https://meta.wikimedia.org/w/index.php?title=Community_Wishlist/Wishes/Make_the_visual_editor_a_real-time_editor&diff=next&oldid=27648614 seems to have fixed it. * Pppery * _{it has begun} 22:16, 24 October 2024 (UTC)

That's not a fix. Either the intake form needs to be fixed not to insert trailing spaces or the filter be fixed to ignore them. Nardog (talk) 00:09, 25 October 2024 (UTC)

I think it inserts the user's signature, and that specific user's signature has a trailing space. This is an edge case not worth fixing IMO unless they start producing tons of wishes. * Pppery * _{it has begun} 00:42, 25 October 2024 (UTC)

Ah, then I'd submit that the intake form shouldn't use the signature and generate the links directly from the username (or let the template generate them) instead. Nardog (talk) 00:48, 25 October 2024 (UTC)

Unarchived since it has not been resolved. Nardog (talk) 14:14, 1 July 2025 (UTC)

I'd submit that the intake form shouldn't use the signature and generate the links directly from the username – That is precisely what is to come with the upcoming MediaWiki extension that is to replace the gadget, slated to be deployed late July or in August. So this won't be a problem anymore. We also won't be relying on AbuseFilter at all. In the meantime, we will have to deal with this edge case manually should it pop up again. MusikAnimal (WMF) (talk) 16:44, 1 July 2025 (UTC)

Wish erroneously marked as closed

The status of Community Wishlist/Wishes/I don't need all the special characters, but it can be hard to find the ones I want has been changed to "closed", which is not recognized by the interface. Please change it to open or in progress, as it has not been delivered to WikiEditor users, i.e. the majority. Nardog (talk) 06:42, 1 January 2025 (UTC)

I'm at a loss as to why it took more than a month and a volunteer to fix this. Nardog (talk) 06:44, 9 February 2025 (UTC)

Resolved. Wish has now been marked as Delivered –– STei (WMF) (talk) 13:45, 12 February 2025 (UTC)

@STei (WMF): Can you comment on why anyone on your team did not bother to do it? It would have taken less than a minute, and you clearly read this page. Slapping the resolved tag after weeks of ignoring is adding insult to injury. Nardog (talk) 03:02, 13 February 2025 (UTC)

Unarchived since it has not been resolved. Nardog (talk) 14:14, 1 July 2025 (UTC)

Wishlist in the annual plan

Hey folks - I'm really excited that we successfully integrated 3 focus areas into the upcoming WMF annual plan, and that the wishlist at large was a key input in shaping the plan at large. Here are the focus areas that were prioritized:

• WE1.2: Connecting Like-Minded Contributors
• WE1.3: Task Prioritization
• WE3.1: New Consumer Experiences

In addition, the Community Tech team is already working on Template Recall and Discovery, by building Favoriting Templates. Focus Areas are prioritized against long term goals, team speciality, and community interest. Beyond these 3, WMF will continue to evaluate additional focus areas in 2025-6.

And, we'll continue to evolve how the Foundation processes and communicates the status of wishes. If you're interested in discussing either with us, please drop a line here! JWheeler-WMF (talk) 15:38, 7 March 2025 (UTC)

These focus areas have a total of 17 supporters. The first one has zero. Why where they selected?

And do you have an update on when we can vote on individual wishes to bring back community input? —Femke 🐦 (talk) 09:31, 8 March 2025 (UTC)

You said you were going to work on bringing back categories and voting for individual wishes "Feb/March". Are you? Nardog (talk) 11:11, 8 March 2025 (UTC)

Just for your info, I have posted about the Wishlist at Annual Plan talk page. Commander Keane (talk) 22:58, 8 March 2025 (UTC)

@Femke @Nardog thanks for sharing your feedback on the Wishlist and continued frustrations.

During Annual Planning, we evaluated every focus area. The Foundation will continue to re-evaluate focus areas as we develop quarterly hypotheses and new key results over the fiscal year.

Regarding the selected Focus Areas, we are actively working on Template recall and discovery, the top-voted focus area.

We prioritized Connecting Like-Minded Contributors as the wishes in this focus area neatly align to the KR defined in WE1.2. We've seen signals that when contributors connect with each other, they are more likely to have longterm success on their respective Wikis.

Similarly, the Foundation sees new consumer experiences as a strategic investment, and the included wishes are topical and representative of possible experiments.

Task Prioritization was prioritized over repetitive tasks as the wishes were more actionable and would directly impact the lives of administrators sooner.

Lastly, there's been questions about voting on individual wishes and categories. Though I mentioned we'd bring these back in February or March, this effort is being put on pause, so we can do more discovery around evolving the Wishlist. At large, we want to prioritize as many wishes as possible, process them efficiently, and increase participation. We've experienced inefficiencies at how WMF processes wishes, which has impacted participation and prioritization. As such, we'd like to brainstorm with communities and the foundation how to improve this: https://calendar.app.google/LoJ3H3UGNEJs7TUA7. JWheeler-WMF (talk) 18:57, 10 March 2025 (UTC)

I'm done with this hemming and hawing. As I've said on this page and to you personally, I was excited for the new wishlist. But your constant sidelining and outright ignoring our voices drained all benefit of the doubt I was willing to give you. Nardog (talk) 13:42, 11 March 2025 (UTC)

Thanks for explaining the rationales behind these selections a bit. I still think the main issue, also or especially inefficiencies at how WMF processes wishes, is that there is too little tech development. Here if you work mostly on just these three focus areas that leaves a lot of other wishes remaining unaddressed, not even considering the many existing feasible phab issues and proposals in prior Wishlists that haven't been included in this Wishlist but are still important and/or heavily-supported.
I don't see why template discovery is such a top-priority one for example – if I'm writing or editing an article, I just go to a popular similar one and check which template is included in that article and on the occasion that I don't find such (or for new users) it's not a huge problem if the infobox is missing and likely some editor will later add it; I don't see why slightly improving the use of templates is particularly urgent or would have a major impact in specific (it's useful nevertheless). There can't be any somewhat satisfying result with so little capacity. Too little work on implementing wishes & issues can be solved by increasing funding for development (/more devs) and/or increasing participation/number of volunteer devs. If there are barriers like too few mentors for MediaWiki devs if you make that a requirement, then work on addressing that effectively please. If you'd also "prioritize" individual wishes & issues "against long-term goals", you'd see how in total tech development is having a far too low priority. For example, if you really think despite the many millions WMF has, it doesn't have enough for substantial development beyond some experiments and occasional solving of some many years-old code issue, then please at least do the many possible things that WMF could do to help others implement things. Would have donated to a separate fund or organization that rewards open source devs with some relatively small weighted 'bounty' reward for implemented issues or some coding challenge with prizes. Prototyperspective (talk) 14:55, 11 March 2025 (UTC)

"the top-voted focus area" means 30 people. This is an incredibly small number of editors. Best, Barkeep49 (talk) 15:55, 11 March 2025 (UTC)

During Annual Planning, we evaluated every focus area.

I didn't realise that focus areas would impact Annual Planning. I must have missed the memo. I would understand if the WMF hired exclusively software developers, but I heard there are staff whose role it is to comunicate or manage. STei_(WMF) mentioned it in a discussion with Femke in August 2024. Ironically Femke is/was waiting for more focus areas before voting (and I was holding off submitting new wishes until categories/individual voting was introduced and there weren't any focus areas I was interested in supporting). Nothing would scare the community into mass participation (ie sitewide banners) in the Wishlist more than the threat of "we are going to direct software development and influence the Annual Plan by looking at focus area voting on [this date]." Not an empty threat, that is what happened. Out of curiosity at what date was this (I can work out the state of focus areas if you give me the cutoff date).

we are actively working on Template recall and discovery, the top-voted focus area. - it was top-voted at an unknown cutoff date when more appropriate focus areas didn't exist, by an extremely small number of editors.

I do not find Prototyperspective's concern about development funding relevant to the Wishlist. It is a given that community wants better software. I think the JWheeler-WMF comment inefficiencies at how WMF processes wishes is about the fact that the WMF looks at every wish and decides what what to do them (status submitted/open). The simple solution is for the WMF not do this work. What do they think it is achieving? Take this wish. I interpreted it (volunteer), then Product Manager, Editing (WMF staff) filed a Phabricator bug on my interpretation, then Senior Software Engineer (WMF staff) investigated the bug and found it is probably invalid, and the bug still sits in Phabricator as open (and actually on the Wishlist Phabricator workboard for some reason). Similar story on this wish, WMF software developer doing tech support for a functioning product that can be handled by volunteers at Village Pump Technical on enwiki. Maybe don't encourage WMF software developers to look at the Wishlist (thay make software...), but I apologise to any WMF staff that peruse the Wishlist in their personal time, that is commendable.

I do like connecting WMF communucation staff with with 10 year old tasks on Phabricator that have been forgotten (example, see talk). But the cost of this sort of WMF attention is too great for the WMF. Maybe WMF could pay attention to wishes with at least two supports to cut out the noise. Commander Keane (talk) 05:30, 12 March 2025 (UTC)

Nothing would scare the community into mass participation (ie sitewide banners) in the Wishlist more than the threat of "we are going to direct software development and influence the Annual Plan by looking at focus area voting on [this date]" is a great point that further proves WMF is either actively trying to reduce wishlist participation contrary to what Jack has said, or accidentally marvelous at it. Nardog (talk) 01:25, 15 March 2025 (UTC)

Maybe this page should be renamed the "WMF Wishlist" then? Ita140188 (talk) 14:40, 23 June 2025 (UTC)

Why this page? What you wrote makes no sense. Or did you mean "annual plan" should be renamed to "WMF Wishlist"? Prototyperspective (talk) 13:24, 27 June 2025 (UTC)

I meant this page, the Community Wishlist, in reference to the fact that the choice of wishes seems entirely up up the WMF rather than the editors at this point Ita140188 (talk) 17:22, 29 June 2025 (UTC)

Old revisions not visible

With {{Community Wishlist/Wish}} deleted, revisions before the migration are useless. Please restore the template so we can see how a wish has evolved. Nardog (talk) 04:35, 4 October 2025 (UTC)

I have implemented a bare-bones implementation using the new interface messages. MusikAnimal (WMF) (talk) 07:52, 5 October 2025 (UTC)

Thank you so much! Nardog (talk) 13:50, 5 October 2025 (UTC)

This section was archived on a request by: Prototyperspective (talk) 15:57, 7 October 2025 (UTC)

Increase max number of wishes displayed

With voting being rolled out, I'd like to be able to quickly scan through many wishes. Would it be possible to display 50 at once when people click display more? 10 at a time would make voting slow. Thanks! —Femke 🐦 (talk) 17:07, 8 October 2025 (UTC)

Yes, I was wondering about this too. The standard Codex table component is supposed to allow you choose your own page size, but we had to disable that due to various complications. I agree that in lieu of that we should at least have a longer list of results. I have increased it to 50. MusikAnimal (WMF) (talk) 17:45, 8 October 2025 (UTC)

Wow, that was fast! Thanks :). —Femke 🐦 (talk) 19:29, 8 October 2025 (UTC)

This section was archived on a request by: Prototyperspective (talk) 16:54, 10 October 2025 (UTC)

Community Wishlist/W328

This was marked as "archived" per-migration, but is now back to "under review". Is this intentional, and if so could the archival note be removed? * Pppery * _{it has begun} 20:13, 18 October 2025 (UTC)

I have re-declined the wish. Thanks, MusikAnimal (WMF) (talk) 18:13, 19 October 2025 (UTC)

This section was archived on a request by: Prototyperspective (talk) 00:27, 22 October 2025 (UTC)

Cleanup wanted

• ✔ Add a subtitling tool for easy subtitling and translating and Bedre system for å legge til og oversette undertekster ask for the same thing.
• ✔ Reverse (inverse) partial blocks and Reverse partial blocks ask for the same thing.
• ✔ Quickly add favorite and related templates and Quickly Add Infobox 2 are duplicates. (They claim to be imported from the same wish in an earlier edition.)
• ✔ Character insertion tool in discussion pages asks for a feature that had already existed (this has been acknowledged by the proposer).

Matěj Suchánek (talk) 18:34, 11 August 2025 (UTC)

@Matěj Suchánek Thanks for your message. We'll look into this as soon as possible. :) Sannita (WMF) (talk) 10:32, 12 August 2025 (UTC)

@Sannita (WMF) There's also quite a few things labeled as 'in progress', while some of these have clearly been delivered, like IP reputation variables for Abusefilter.. Can the wishlist team and the disbanded trust and safety dev team give an update on the state of those wishes as well ? —TheDJ (talk • contribs) 14:55, 27 August 2025 (UTC)

Is this done? If not, I'd suggest creating a new thread and specifying which wishes are remaining. I could not spot a wish about IP reputation filters when filtering the wishes for in-progress wishes so it seems like that one was changed. Prototyperspective (talk) 09:50, 6 November 2025 (UTC)

#1 is now Community Wishlist/W111 and Community Wishlist/W32.

#1 and #2 are still pending.

#3 and #4 are done. --Matěj Suchánek (talk) 07:30, 6 October 2025 (UTC)

I think there's still many issues that are outside the scope of the Wishlist, entirely unclear, duplicates as well as some still having the Submitted/Under review instead of Open status. If the WMF won't manage, will volunteers be able to organize the wishes with these status etc? And is there a better way to search for wishes where e.g. archiving has been suggested on its talk page other than this search such as for example only searching talk pages of wishes that have the status Open? In any case, there are many more wishes in the Wishlist that need changes and I doubt the best approach would be to list them here but if so, I think this should be made clear so that users list more such wishes in this section.
Lastly, I don't think wish Add support for Wikimedia Commons in the open source NewPipe media player app should stay archived as volunteers could make a pull-request there and then NewPipe can check whether they want to add the media support for the site like for FramaTube & the CCC media server or not – it's certainly in the interest of Wikimedians and it would become a tool/technology in the Wikimedia ecosystem if that open source player, unlike the Commons app which is much less popular anyway, can play videos and audios on Commons. If say an open source package that MediaWiki is using gets a needed functionality broken by an update, it would also be within scope to request to fix this [either via patch to the software (most efficient) or via replacing it (may require from-scratch development & more resources for maintenance) or via forking it (why do that if it's not needed) even if that technology has not been originally developed by WMF themselves]. Prototyperspective (talk) 17:29, 6 October 2025 (UTC)

So routine maintenance of the Wishlist is an obvious problem and one we intend to fix! For starters, we want to formalize how wishes are merged, since that process is very manual and unstructured right now. You can follow phab:T401638 for updates on that effort.

Secondly, I don't think it should be only staff that can perform this kind of routine cleanup. On Phabricator, the wikis, and pretty much everywhere else in the wikiverse, anyone can do these things. The same should apply here in the Wishlist :)

With the advent of our new extension, we now have a dedicated user group that is currently used to restrict status changes and focus area assignments to users in that group. This was previously enforced via AbuseFilter (yuck!). Anyway, it is intentional that this user group is not technically restricted to WMF staff. We just haven't yet devised a system or established criteria for volunteers to become a Community Wishlist manager. We need to figure out a few things before we can do this, namely T406674 – Add a new vote-able status that is above "Under review" but before a triaged status. This would be the status Community Wishlist managers are encouraged to use if a wish is valid, but they don't want to make a product call on the long-term WMF involvement of the wish (which only some staff would do).

Hopefully that makes sense. If you have any thoughts or concerns, please share! Best, MusikAnimal (WMF) (talk) 18:57, 8 October 2025 (UTC)

On that matter, Meta admins currently have all of the technical rights that Comunity Wishlist managers have. Is that in case they run into some technical issue, or was it your intent that Meta sysops be automatically approved to act as wishlist managers in addition to their many other tasks. * Pppery * _{it has begun} 16:36, 11 October 2025 (UTC)

It was intentional as an out-of-the-box configuration for the extension. The plan was to remove manage-wishlist from sysop, but I figured we didn't really need to worry about it. These aren't sensitive rights, after all. Just like on Phabricator, triaging a task as high-priority isn't going to make it so to the responsible team, and likewise with the statuses here. We trust you all not to abuse the system :)

Over the next week, we'll try to come up with a guideline on how to address wishes from the perspective of a Community Wishlist manager (or users with manage-wishlist rights), along with any other duties. We can include this in the documentation at Meta:Community Wishlist managers. Wish inclusion criteria would be more or less the same we've always used, I imagine, but nonetheless I need to run it by the team first. So for now, I'd hold off on status changes and editing focus areas.

Once phab:T406674 goes live (probably sometime Monday), you should feel free to move any wish from "Under review" to "Accepted", using your judgement. MusikAnimal (WMF) (talk) 18:56, 11 October 2025 (UTC)

Answers to the other questions asked:

• is there a better way to search for wishes where e.g. archiving has been suggested on its talk page – I don't think we'll want to formalize a "suggest for declining" system. The talk page seems like the right place for that. The criteria under which a wish should be declined isn't very clear at the moment, so we'll want to improve that first. We have been discussing this and hope to have something to share soon.
• I don't think wish Add support for Wikimedia Commons in the open source NewPipe media player app should stay archived – this was intentionally unarchived by the migration script :)

MusikAnimal (WMF) (talk) 19:07, 8 October 2025 (UTC)

Thanks for the explanations! Regarding suggesting wishes for declining, I also don't think a formalized method is needed – it just seems like there is no followup when editors ask(/agree) for a wish to be archived and nobody making/having a list of these wishes to revisit when there is stronger consensus to archive or at least still no explanation/wishedit/countervoice for the wish not to be archived. Prototyperspective (talk) 23:35, 10 October 2025 (UTC)

Community Wishlist/W215 and Community Wishlist/W99 are probably duplicates. --Matěj Suchánek (talk) 09:09, 11 October 2025 (UTC)

All Done, thank you! I'm going to get to work on phab:T401638 soon… Too much manual labor here! MusikAnimal (WMF) (talk) 06:12, 12 October 2025 (UTC)

Could you please also merge the content like you did for another wish you merged at Special:Diff/29436249 (W32). I would do it myself but then I think it wouldn't be marked for translation and it could take long until it actually shows. Moreover, I think the best merging would be having the wish get the best from both wishes for both title and description instead of just copying the wish description (in the prior example neither was done). Currently, merging seems to consist of linking the wish that was created later to the one created earlier, regardless which is more concise or which has more details etc. In the prior case for example, only one of the wishes had an illustrating image and I think the title of the wish merged to is much less clear (actually pretty ambiguous/undescriptive and unclear) and it has less description of why and what is the problem.

Lastly, now looking again at the wish merged to, I start to doubt whether these should be merged to begin with: the target wish has I would like to see either a link directly to the Commons page in the drop-down menu of the full screen image (Media Viewer?); or an option in the preferences to go directly from an image in Wikipedia to its Commons page but the other wish is about always opening the Commons page directly when opening a Commons file. Instead of having the intermediate page without the Commons categories, always open the Commons file page directly when opening a media file (in a new tab or with the button highlighted in the other wish). So if the latter wish isn't about this, it needs to be unmerged and also I'm considering to remove my vote there because just some preference for registered logged-in users is not what I think would suffice. Prototyperspective (talk) 22:49, 12 October 2025 (UTC)

I went by your own words that it was "probably a duplicate". Please feel free to copy over whatever content you feel is necessary. Community Wishlist/W99 is not set up for translation, but even if it was, you should still be bold and make the changes as you see fit. This is a wiki, after all :) Discuss with the other proposer on the talk page if you think you have conflicting ideas. To me they looked like the same problem (as wishes are meant to be problem-based), and I took your vote on W99 as confirmation that you were okay with merging them.

Generally speaking, the process of merging wishes will be just like it is on Phabricator. The duplicate wish is still there fully intact for all to read. We do need the original wish to mention duplicates, though. I'll add something for that to phab:T401638. As for merging wish contents, that's not something we can automate. We will need to work together to make sure all relevant details are not lost. I'm hoping the backlink I just described will help with that. MusikAnimal (WMF) (talk) 21:22, 13 October 2025 (UTC)

Are we still doing the "problem-based" thing? If so you better deliver on your promise and show evidence for its superiority, or stop giving that instruction which has caused a great deal of extraneous back-and-forth between confused parties that never happened when we had the proposed solution field. Nardog (talk) 12:58, 14 October 2025 (UTC)

The guidelines on how to write wishes are overdue for a revamp. We do prefer them to be written based on a problem, not a solution. What can happen is everyone gets their hopes up for a particular solution and if for whatever reason, we are unable to deliver, then many users are left unhappy, even if we did deliver on an alternative solution. If the wish is left more open-ended, then that gives us room to find a viable solution that balances engineering costs and user satisfaction. Say, if the proposed solution takes 5 years, but we can do something different that helps most users within say 1 month, we'll almost always opt for the latter.

Of course, the "problem-based" approach is merely a guideline, not a requirement! We are only human; Many of us, especially the technically-inclined, will instinctively want to spell out exactly what we want. That does not make a wish invalid, and in many cases it may be the only way to convey your wish. MusikAnimal (WMF) (talk) 19:12, 23 October 2025 (UTC)

I just hope you're not devaluing or de-prioritizing solution-oriented wishes, which I know your previous boss did. Sometimes the problem any Wikimedian can agree is the problem is that something lacks a certain feature, period. You could pry at what truly is driving the demand for it, but to the people who want it, it feels like being told when you just need a screwdriver they're going to investigate whether you really need the desk you're assembling and whether they can build a better one. Nardog (talk) 17:14, 24 October 2025 (UTC)

Yes, I was wrong about that and it's understandable that it's been interpreted that way given that I said it probably was and another user here did too.

I thought wishes are problem-based but only the focus areas are structured as discrete problem fields instead of solutions-oriented. Both of these wishes are problem-based.

• The target wish is about personal disliking of how files on Wikipedia can be opened in the sense of what a registered individual user can do, while in contrast my wish is essentially about the public awareness and use of Commons where just having a setting hidden somewhere in the preferences of registered logged-in users (<1% of readers) is fundamentally different and insufficient compared to changing the isolation of Wikipedia users from Commons so they not unlikely never ever get to see Wikimedia Commons as if that's some competitor site the community wished to keep small and unknown.
  To make it even clearer one wish is like 'I'd like to be able to get to Commons directly from Wikipedia' and the other like 'I'd like the Wikipedia readers – including those who don't already know of Commons or of its differences to Wikipedia like Commons categories and its millions of unused files – to directly land on Commons to benefit both millions of readers and the Commons project'

I didn't see this key difference because I was focused on the high relatedness of the two wishes and did not read the part I would like to see either a link directly to the Commons page in the drop-down menu of the full screen image (Media Viewer?); or an option in the preferences to go directly from an image in Wikipedia to its Commons page carefully enough. Made a mistake there and also didn't think it would get merged this quickly. Now I'd be open to try to merge the contents but I hope from the above explanation it's clear just how different those two wishes ultimately are even when initially they seem almost the same. Actually, even the problem definition differs in its core. So ultimately, I think unmerging these two would really be best and may be necessary. Prototyperspective (talk) 21:32, 14 October 2025 (UTC)

Unmerge request

W215: Open the Wikimedia Commons file page directly was merged into W99 : Shortcut for images from Wikipedia to Wikimedia Commons (well currently only redirecting to it) because here Matěj Suchánek wrote they are probably duplicates and I as the author of the former wish also wrote this is probably a duplicate of [the former wish] in the latter wish.

However, upon reinspection the two wishes are fundamentally different. The full explanation is here and in the comment above.

Briefly, the latter wish has I would like to see either a link directly to the Commons page in the drop-down menu of the full screen image (Media Viewer?); or an option in the preferences to go directly from an image in Wikipedia to its Commons page (for the registered logged-in <1% of Wikipedia readers) but the former wish that has been closed is about always opening the Commons page directly when opening a Commons file (default functionality for 100% of Wikipedia readers). Advantages of always opening the Commons file page directly is that there are the Commons categories, Commons link will not be redlinks, and it will make people learn about the Commons project. Details are in the two wishes. Please unmerge them. Prototyperspective (talk) 14:09, 22 October 2025 (UTC)

Note that these two wishes are fundamentally different also in their problem description, not just the solution. Prototyperspective (talk) 21:36, 23 October 2025 (UTC)

Done MusikAnimal (WMF) (talk) 20:54, 24 October 2025 (UTC)

This section was archived on a request by: Prototyperspective (talk) 09:47, 6 November 2025 (UTC)

Translation subpages in Category:Community Wishlist/Wishes

There are translation subpages in Category:Community Wishlist/Wishes (and Category:Community Wishlist/Wishes/All is now empty), which I don't remember being the case pre-migration. Is this intentional? Nardog (talk) 11:44, 7 October 2025 (UTC)

The Wishes category will go back to normal starting tomorrow with this week's deployment train. I invented the Wishes/All category solely for the purpose of being able to plug it into Massviews. We can bring it back if there's a need for it, but as it was for a personal one-off analysis, I didn't bother. I've gone ahead and deleted the category page. MusikAnimal (WMF) (talk) 15:43, 7 October 2025 (UTC)

This section was archived on a request by: Prototyperspective (talk) 09:43, 6 November 2025 (UTC)