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)Reply
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)Reply
@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)Reply
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)Reply
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)Reply
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!
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 begun00:37, 17 July 2024 (UTC)Reply
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)Reply
Latest comment: 4 months ago2 comments2 people in discussion
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.
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)Reply
Thanks for the reply! So, the button in translations does link to the wrong page.
@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)Reply
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)Reply
@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)Reply
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)Reply
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)Reply
Latest comment: 3 months ago5 comments3 people in discussion
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)Reply
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)Reply
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)Reply
@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)Reply
"Discussion" link goes to section=new even if the talk page exists
Latest comment: 1 month ago12 comments4 people in discussion
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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.
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)Reply
Not just Meta but all multilingual wikis that use the Translate extension.
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)Reply
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)Reply
Latest comment: 3 months ago4 comments2 people in discussion
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?
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)Reply
Latest comment: 3 months ago1 comment1 person in discussion
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)Reply
@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)Reply
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)Reply
Latest comment: 25 days ago4 comments3 people in discussion
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. 😅
@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)Reply
Latest comment: 3 months ago3 comments2 people in discussion
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.
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.
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)Reply
Latest comment: 2 months ago9 comments4 people in discussion
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)Reply
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)Reply
@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.
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)Reply
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.
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)Reply
Latest comment: 2 months ago2 comments2 people in discussion
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)Reply
Latest comment: 2 months ago6 comments3 people in discussion
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.
😀 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)Reply
@Femke. @Novem Linguae the WMDE wishlist also uses tiles for focus areas. Are you asking for a list?
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)Reply
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)Reply
Latest comment: 2 months ago9 comments3 people in discussion
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)Reply
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.
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)Reply
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)Reply
@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)Reply
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)Reply
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)Reply
Latest comment: 2 months ago5 comments3 people in discussion
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)Reply
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)Reply
Latest comment: 25 days ago3 comments2 people in discussion
!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)Reply
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}}.
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.
Latest comment: 2 months ago5 comments3 people in discussion
@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)Reply
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)Reply
@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.
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.
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)Reply
@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.
Latest comment: 2 months ago1 comment1 person in discussion
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.
Latest comment: 2 months ago1 comment1 person in discussion
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)Reply
@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)Reply
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.
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)Reply
@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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
Conversations Made Easier: Machine-Translated Wishes Are Here!
Latest comment: 6 days ago3 comments3 people in discussion
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.
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)Reply
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)Reply
Latest comment: 28 days ago3 comments3 people in discussion
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)Reply
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:
Latest comment: 25 days ago6 comments2 people in discussion
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)Reply
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)Reply
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 begun00:42, 25 October 2024 (UTC)Reply
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)Reply
Latest comment: 6 days ago8 comments4 people in discussion
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)Reply
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.
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.
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)Reply
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)Reply
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)Reply
Thanks! I have added my first wish.
Fixed with Special:Diff/27192724. I see now for example Community Wishlist/Wishes/Wiktionary mobile app/ja shows 
