Talk:Community Wishlist

This page is for discussions related to the Community Wishlist page.   Please remember to: Sign posts using the four tildes (~~~~) Remain civil and polite during discussions. Place new text under old text (start a new post).

Recent activity on other Community Wishlist talk pages

This list recent changes to talk pages of Community Wishlist wishes and focus areas.

List of abbreviations:

D

Wikidata edit

N

This edit created a new page (also see list of new pages)

m

This is a minor edit

b

This edit was performed by a bot

(±123)

The page size changed by this number of bytes

21 December 2024

			03:28		Talk:Community Wishlist/Wishes/I don't need all the special characters, but it can be hard to find the ones I want 3 changes history +322 [PPelberg (WMF); Nardog (2×)]
					03:28 (cur | prev) +33 Nardog talk contribs (misleading)
					03:28 (cur | prev) +206 Nardog talk contribs (→Wish complete ✨: Reply) Tag: Reply
					03:16 (cur | prev) +83 PPelberg (WMF) talk contribs (→Wish complete ✨: Forgot to close out this comment!) Tag: 2017 source edit

20 December 2024

22:17

Talk:Community Wishlist/Wishes/I don't need all the special characters, but it can be hard to find the ones I want diffhist +782 PPelberg (WMF) talk contribs (→Wish complete ✨: new section) Tag: New topic

08:45

Talk:Community Wishlist/Wishes/Automatically create videos based on media in Wikipedia articles diffhist +664 Strainu talk contribs (→Relevant experiment & insights: Reply) Tag: Reply

19 December 2024

N    21:16

Talk:Community Wishlist/Wishes/Automatically create videos based on media in Wikipedia articles diffhist +1,059 MPinchuk (WMF) talk contribs (→Relevant experiment & insights: new section) Tag: New topic

18 December 2024

N    15:22

Talk:Community Wishlist/Wishes/SVG анимация diffhist +421 TheDJ talk contribs (→one animation is not the other animation: new section) Tag: New topic

11:21

Talk:Community Wishlist/Wishes/Help editors plan their work more easily diffhist +583 Hakimi97 talk contribs (→Thank you for submitting a wish!: Reply) Tag: Reply

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)

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)

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

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)

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)