Talk:Community Wishlist Survey/Future Of The Wishlist

Archives Archive 1

Discussions on designing a new Wishlist

Conversation 1: Defining a wish

Conversation 1:
What is a “wish”? Is a “wish” a description of a problem, a design for a solution, or something in between?

More on this topic

Hello all! I'd like to introduce to you Jack Wheeler, who has recently joined the Foundation as its Lead Community Tech Manager, responsible for the Future of the Wishlist. Jack would like to kick off conversations to get your input for the design of the new Wishlist, starting with how to define a "Wish". Please check out Jack's message and let's have a discussion. Hoping to hear from you, ––– STei (WMF) (talk) 21:33, 26 February 2024 (UTC)

Thanks @STei (WMF) for the introduction. I'm so excited to meet you all, and invite you to a conversation on the Future of the Wishlist. As @STei (WMF)mentioned, I have a few initial thoughts and even more questions about the Wishlist, and would love to hear from you. jack (talk) 22:08, 26 February 2024 (UTC)

JWheeler-WMF, hello, and thank you for your engagement! The question of "what is a wish" caught my interest, especially since some of my past wishes have fallen into the grey area of non-typical requests. As you rightly pointed out, a wish can take the form of a feature request, a bug report, or exist somewhere in between. It can also serve as a revival of an older, perhaps overlooked or stalled Phabricator task, functioning as a plea for renewed attention. I believe that any structure we develop should strongly integrate with Phabricator, given the common practice of linking open Phabricator tasks to related wishes.
Furthermore, wishes can extend beyond the technical nature; for instance, the aforementioned 1% wish. They might also be inherently complex or challenging to implement, such as a past personal wish for more buttons instead of links in Wikipedia's interface. In my situation, I was advised to discuss it with the individuals creating the new Vector theme, but this made it difficult to follow up on my request. Expressing wishes within ongoing projects can be daunting, especially for newer users, unlike the straightforward process of a traditional wishlist.
Ideally, all these cases are valid wishes. However, as I mentioned in my initial discussion, the crucial aspect is developing something that can lead to concrete products rather than stalled projects. Therefore, the question of what constitutes a wish becomes more about what wishes we have the capacity to fulfill in a rather timely manner. This depends on many "background factors" making it a bit challenging to extrapolate. — Klein Muçi (talk) 12:41, 29 February 2024 (UTC)

Thanks @Klein Muçi

Regarding your perspective on a Phabricator integration, could you tell me a bit more about this? How would a Phabricator integration make for a stronger wishlist? How would you imagine this to work?

RE: your comment on Wishes leading to concrete products, there's a lot to unpack here. In principle I agree that wishes should lead to concrete products. I think it's also important to recognize that not every wish should be worked on, and it's the our job to express when and why a wish isn't a priority, and work with y'all to focus on the most pertinent problem areas that crop up. jack (talk) 22:56, 29 February 2024 (UTC)

JWheeler-WMF, a Phab-integrated interface, let's refer to it as such, would enable real-time tracking of a wish, its progression, and all associated elements, including related side tasks. This integration could enhance the correlation between WMF and volunteer efforts, as Phabricator has usually served as a meeting point for such collaboration. Ultimately, it could contribute to a more unified work environment, streamlining the management of tasks by consolidating them into a single, comprehensive list, bridging the gap between traditional wishes and Phabricator tasks, which, in the broader sense, can be considered as wishes too.
I can imagine such an interface allowing you to quickly link and comment on related Phab-tasks without needing to leave the original window. It could be filled with various progress bars, providing transparency on how the wish is being worked on and indicating how close it is to being fulfilled, perhaps accompanied with an approximate deadline of some sort. — Klein Muçi (talk) 03:41, 1 March 2024 (UTC)

Hi @STei (WMF), before thinking about new features, please have the graphs fixed (task T334940). They've been broken for nearly two years on all Wikimedia wikis. Ayack (talk) 13:23, 29 February 2024 (UTC)

"What is a wish?" A wish is not just in English. Also, no closing or archiving. A big problem with the annual Wishlist survey was that WMF staff would close Wishes because they were out of scope. But if a Wish doesn't require engineering resources it is still a valid Wish - simply mark it as "no eng. resources needed" and let it live in the Wish system. If it garners enough votes it indicates that some action should be taken by the community. For example the Wish "Videos for creation assistance" may not seem to need engineering resources but it still indicates a valid request. Commander Keane (talk) 22:38, 29 February 2024 (UTC)

@Commander Keane

I agree a wish is not just in English. We intend to make wish submission more equitable.

I also believe a wish is a person's valid idea or problem, not too big or too small, and that it shouldn't be "closed or archived," unless perhaps the wish is fulfilled :)

When you say "If it garners enough votes it indicates that some action should be taken by the community," what sort of community response would you expect? jack (talk) 23:01, 29 February 2024 (UTC)

The community response would be independent of a WMF response, just let the community do its own thing. In the "Videos" example it is up to the Wikipedia community to make the videos. Commander Keane (talk) 23:39, 29 February 2024 (UTC)

Thanks Jack for taking on this project :). "What is a wish": to me, the previous system defined it well (i.e. a problem and a first stab at a solution). By only specifying the problem, you risk the solution not quite working as there is risk of miscommunication.

One element I did not like about the system is that bugs were excluded. A bug can be more annoying that the absence of a new feature or tool. For instance, people using Firefox can't copy citations at the end of a paragraph (phab:T314228). A problem that makes editing more error-prone, for instance citations stay behind when you move a paragraph elsewhere in the article. After raising this on phab, the road stops. There are many other bugs that have been open, and that simply linger on phab, without a clear method of community prioritisation. Femke (talk) 08:26, 5 March 2024 (UTC)

Hey @Femke thanks for bringing this to my attention. I've been speaking with some WMF stakeholders as well, and we agree there's a desire to incorporate bugs as part of our new system. I hear you that bugs can linger on phab, and there could be a better way for the community to signal the most problematic bugs.

Would you anticipate that *all* bugs on Phab appear in the wishlist, or only bugs created via the wishlist appear? jack (talk) 20:55, 5 March 2024 (UTC)

They're different but related -- let someone create a wish from an existing set of Phab tickets; or link a wish to Phab tickets later on. No automatic prefilling in general, but Phab tickets with lots of tokens probably make good wishes and those with 5+ tokens could constructively be autopopulated (or clustered in with others). –SJ talk  20:26, 6 June 2024 (UTC)

Since STei asked, before chipping in, I'll explain my reticence to do so: This is such a bizarre way to start a conversation. "Well, wikt:wish is thataway" was my first reaction; it's so vague and broad it paralyzes one's willingness to engage. What are the kinds of answers you're looking for? If you're asking how a "wish" should be defined as pertains to the forthcoming wishlist or, put more bluntly, what the scope of the wishlist should be, say so. Please be more specific in your queries in the future. Nardog (talk) 08:38, 6 March 2024 (UTC)

@Nardog thanks for letting us know. Jack and I will see how best we can provide more clarity. I, will also find a better way restructure the talk page. I will check in with you later to see if I did a better job this time. –– STei (WMF) (talk) 15:48, 6 March 2024 (UTC)

I'd say that plainly removing past discussion threads from the talk page may prove to be a bit problematic, especially when involved users get notified about such actions. Even swift archiving might raise suspicions, while the absence of an archive link may lean too heavily towards censorship. All in all, I'd say that it's better to leave the discussions happen in the organic, original flow. If a more closely-knitted discussion is required which requires a stricter form, a new page may be needed to be created. - Klein Muçi (talk) 19:47, 6 March 2024 (UTC)

@Klein Muçi thanks for the feedback. Actually I didn't want to archive the past conversations because I felt strongly that there other community members who may be still processing the early decisions we shared about redesigning the Wishlist. To me, archiving meant closing the conversation, or censoring any more views on CommTech's early post in January. I decided to use the quite restrictive {{collapse}} template as a trade off to collapse the earlier conversations, which nonetheless, still keep them visible on the talkpage, but neatly tucked away, so we can continue new conversations below. The talk page was getting too long. However there have been other user opinions with justification why I should not be collapsing talk pages. Finally, I decided to archive. Indeed archiving requires a link to the archive. But after several tries to embed the box, I noticed the links were leading to Community Tech's other pages. I decided to raise the issue with colleagues who could help figure out why the template was behaving that way. Thankfully, @Nardog fixed it.

Please let me know if this explanation helps. Our aim is to keep earlier feedback visible, but also highlight this new conversation Jack is leading, while preventing the page from getting too long. STei (WMF) (talk) 14:10, 13 March 2024 (UTC)

@STei (WMF): If you want a talk page focused on Community Wishlist Survey/Future Of The Wishlist/Conversations, then why not move this section to its talk page? Community Wishlist Survey/Future Of The Wishlist/Conversations is still not linked from Community Wishlist Survey/Future Of The Wishlist btw. Nardog (talk) 00:29, 7 March 2024 (UTC)

@Nardog it's linked. And thank you for the template fix and everything else. –– STei (WMF) (talk) 15:09, 13 March 2024 (UTC)

When it comes to update to wishes, it would be good to have a system where people can vote on whether or not they prefer the update. ChristianKl ❪✉❫ 14:45, 21 March 2024 (UTC)

Hey @ChristianKl yes we will have a system like this in place to track volunteer support jack (talk) 15:33, 21 March 2024 (UTC)

I meant not only tracking support of wishes but also support of updates given that there was an open question about whether or not to allow updates of wishes. "should wishes be editable?" was one of the questions. ChristianKl ❪✉❫ 02:48, 22 March 2024 (UTC)

Ah - thanks. If I understand your point correctly... I fear that if we allow voting on wishes (and then updates to wishes), we could overcomplicate the voting and support process. jack (talk) 01:06, 27 March 2024 (UTC)

Hi jack thanks for taking this on. A dashboard, editable / refactorable wishes, and persistent wishes (capturing those from past rounds and very popular existing phab tickets, and not "expiring" wishes every year) seems like a good direction.

We might also want to help active contributors be effective wish-curators: for instance by flagging collectively-expressed priority, which may change over time. E.g. something that was very popular 10y ago may be much less relevant now, so the simple approach of "tokens increase over time" on Phab isn't quite right. Likewise some issues get more important with time (better handling of video uploads, as that becomes a dominant way of capturing and sharing knowledge) even though people stop commenting on them because it's considered a dud idea. –SJ talk  20:26, 6 June 2024 (UTC)

Love this! JWheeler-WMF (talk) 20:55, 6 June 2024 (UTC)

Conversation 2: How should volunteers collaborate on Wishes?

Conversation 2:
Should volunteers be able to edit wishes, either their own or someone else’s? If so, how?

More on this topic

Editable wishes and duplicates

Regarding the proposed options in the question about editable wishes, personally I'd resonate the most with the draft option. Maybe have a easier-to-edit draft page and a harder-to-edit post-draft page so edit is always possible theoretically for those rare cases where this might be needed. (The post-draft edit possibility may be removed later if it starts getting abused or if it never gets used.) But I believe editable pages are a good thing to have in general. I remember in old Wishlists having some wishes which benefited from multi-user edits for different reasons like the original user not being enough tech-savy to clearly express their wish, not being proficient enough in English, etc. In these cases, the original user thanked the other users later on.

Another reason to allow edits would be because of duplicates. I expect such a system to have A LOT of duplicates eventually so a good way should be devised to handle them. Many ideas may appear to be duplicates or slight variations of existing ones and might do better merged with other bigger ones (while respecting the original users' intentions) so having dynamic pages instead of static ones would be better I think.

PS: Is there a plan to have some sort of multi-language support? As mentioned, some wishes may be started in non-English languages and provide a cooperation hurdle with the language barrier. - Klein Muçi (talk) 09:25, 22 March 2024 (UTC)

@Klein Muçi thanks for asking these great questions. I agree, and think we're trending towards editable / draft wishes. The rationale is 1) we should embrace the collaborative nature of Wikipedians, and 2) it feels more like our platform. Lastly, edits also allow us to associate duplicates or "bundle" wishes together. For example, last year we had 2 wishes relating to finding and inserting templates. Instead of voting on each wish, we may have seen more impact by associating the two with each other.

RE: Language support, it depends on what you're looking for. I'm hoping in our V1 that every submitted wish would be marked for translation, which of course would rely on Wikipedians to go and translate the submission. Hope this helps, and happy to discuss more. jack (talk) 01:16, 27 March 2024 (UTC)

JWheeler-WMF, that option looks good. Ideally I believe it would be nice to have a machine translated text automatically appear below in a user-chosen language but I don't see that thing being used anywhere in Mediawiki currently (even though Content Translation Tool already provides a lot of auto-translation possibilities when needed). I strongly believe that we should consider using machine translation more widely because there are languages that receive little to no support in many venues. Global collaboration requires dynamic multi-language conversations and manual translations struggle to meet these needs effectively. — Klein Muçi (talk) 03:54, 27 March 2024 (UTC)

Admittedly off-topic, but the first time I saw this subheading, I thought it read "Edible wishes and duplicates". This surrealism puzzled me for a moment. -- Llywrch (talk) 17:26, 19 May 2024 (UTC)

Conversation 3 with Product and Technology staff

Conversation 3 (Product and Tech staff):
What are the needs and challenges of Product Managers with regards to the Wishlist?

More on this topic

–– STei (WMF) (talk) 13:30, 27 March 2024 (UTC)

Preview of New Wishlist

As the conversations are ongoing, a proposal of features and explorations for the new Wishlist has now been published. Please have a look and give feedback.

Preview New Wishlist

–– STei (WMF) (talk) 13:39, 27 March 2024 (UTC)

About bugs

Hello JWheeler-WMF. Thanks for the conversation we had today. I would like to point out the problem that is still present in the new perspective: bugs are not wishes. Solving a bug shouldn't be a wish, as we have Phabricator for reporting them. There are thousands of them open, so proposing to solve things that are broken shouldn't be taken as a wish, or we will end up with another thousand open discussions here of bugs which will end without a solution the same way they are now unsolved at Phabricator. I think that this difference should be clear from the start. If there is a form, it should be clear that you are not asking for a bug to be fixed, that should be done in Phabricator and pointed there in an easy way. Then, the WMF should try to solve those bugs (this is something we can do now). The wishes would be, in this way, easier to find and discuss, and not lost in a wide ocean of bugs. Thanks. Theklan (talk) 18:12, 21 March 2024 (UTC)

It should be added that Phabricator does also include feature requests so if we're going on that slope, one might easily ask "what is left for wishes then". - Klein Muçi (talk) 18:27, 21 March 2024 (UTC)

That only works if there's support elsewhere in the Foundation for getting bugs that impact community workflows fixed, even in un/under-maintained components. Though things have improved on that front, it still isn't the case, especially when CommTech's mandate also includes tools and bots. CommTech has repeatedly fixed bugs as part of wishes, including 1 2 3 4. Other bugs have been rated highly multiple years, such as fixing the problems with VisualEditor reference names. Bug vs Feature Request is often just a matter of perspective. AntiCompositeNumber (talk) 21:47, 21 March 2024 (UTC)

@Klein Muçi@Theklan@AntiCompositeNumber y'all raise fair points. Yes, Phabricator is a venue for reporting bugs and feature requests. And still, it can be a challenge to identify bugs and feature requests via Phabricator. The Wishlist can be leveraged as a platform to call attention to such feature requests and bugs, and can also be a platform for folks who aren't familiar or comfortable with Phabricator.

This is to say - I don't see Phabricator and Wishlist as mutually exclusive, nor do I see them as the same. Rather, Phabricator is a mechanism for engineers to organize, prioritize, and catalogue work, and the Wishlist is a mechanism to discuss and prioritize problems (which often have associated phab tickets). jack (talk) 01:12, 27 March 2024 (UTC)

The problem I (fore)see with this approach is that we will end with hundreds of open bugs and tens of interesting-but-not-developed features in the new Wishlist and, at the same time, hundreds of open bugs and tens of interesting-but-not-developed features in Phabricator. It doesn't matter a lot where we report bugs and/or propose features: what matters is who is going to work on those. We can have the same problem in the near future: making the wishlist a place to call attention for bugs that are yet open in Phabricator and should be solved. This affair is not about technology (where and how we report) but about organization (who is going to solve those and when). Theklan (talk) 07:32, 27 March 2024 (UTC)

4. Participants will vote on “Focus Areas”

What do talk page watchers and the community think about 4. Participants will vote on “Focus Areas”? I have some concerns about this one removing the community's ability to lobby for specific wishes, but would like to hear other people's opinions in case I am way off base. Thanks. –Novem Linguae (talk) 05:43, 10 May 2024 (UTC)

Voting on focus areas instead of specific wishes is the same method WMDE Technical Wishes has been using since 2019 (previously our community voted on specific wishes as well). By focussing on specific areas the developers can tackle more complex issues, because it apparently can take some time to get accustomed to the code of different mediawiki extensions. And once they are already working in an area it takes less time to fix other problems within the same focus areas. The tradeoff is of course, that wishes outside the most voted focus areas don't get any attention. Johannnes89 (talk) 05:55, 10 May 2024 (UTC)

Are the focus areas very precise bundles of "these 3 wishes will for sure get worked on if you vote for this bundle"? If so that could potentially work. Or if the focus areas are more like an entire category that contains 20 wishes or something, I think that would definitely be a challenge since a wishlist participant could spend a lot of time and effort getting a bunch of people to vote for focus area A containing wish X, then focus area A is picked but they work on wish Y instead. –Novem Linguae (talk) 06:09, 10 May 2024 (UTC)

The most recent WMDE technical wishes survey de:WP:Umfragen/Technische Wünsche 2022 Themenschwerpunkte had 16 focus areas to be voted on. Each focus area mentioned a couple of potential problems which could be fixed, but there is always additional user research about issues to be fixed once a focus area has been chosen (see e.g. WMDE Technical Wishes/Geoinformation#History). Johannnes89 (talk) 06:35, 10 May 2024 (UTC)

@Johannnes89@Novem Linguae Yes, part of our structure is inspired by WMDE. In their focus area work, they bundle wishes into broad categories such as "improve templates" and then include examples of wishes they may address through their work. But, WMDE's wishlist team always conducts research to inform a 2-year roadmap.

Our focus areas should be more specific than WMDE's. Focus Areas will not be "categories" such as "Bots & Gadgets" or "Editing," and they likely won't have 20 wishes. For example, "template picker improvements" will address a shared issue across 4 wishes: it is cumbersome for new and experienced editors to select the right template for a page. Yet, if you read each of of these 4 wishes, they propose a slightly different solution. We're using these wishes to inform our work, and our solution should address the underlying problem. That said, it does mean that we won't build every wish in a focus area as specified, but even today, not every wish can or should be built to spec. JWheeler-WMF (talk) 14:49, 10 May 2024 (UTC)

I am concerned about the focus area may be too broad and complicated for community, as the community normally want to discuss the specific problem rather than a broad plan. Nevertheless, it depends on how the ComTech will define and create the focus areas imo. Thanks. SCP-2000 07:01, 10 May 2024 (UTC)

RE: "lobbying for specific wishes," voting is only one mechanism of lobbying. One can still discuss wishes in a Talk Page, articulate a broad and impactful problem, etc. And, with Focus Areas, users will still be able to lobby for improvements. JWheeler-WMF (talk) 14:52, 10 May 2024 (UTC)

My biggest concern with this is that it will yet again incentivize building new things instead of fixing many, but small, bugs and maintaining old things, which is a perennial problem even WMF's CEO and CPTO have acknowledged. We're already seeing Edit Recovery, which they just built, being neglected with glaring issues like T354186 and complaints on the project talk page not being tended to. Nardog (talk) 07:35, 11 May 2024 (UTC)

Thanks for the feedback, @Nardog. One benefit of Focus Areas could be to combine multiple small, related bugs and optimizations into a Focus Area, from which a relevant team can prioritize. Regarding Edit Recovery, this is still a relatively new feature from which we're gathering feedback. https://phabricator.wikimedia.org/T354186 is something we plan to improve, but right now our primary focus is to reopen the Wishlist. JWheeler-WMF (talk) 13:53, 13 May 2024 (UTC)

What will you be doing to make sure the "small, related bugs and optimizations" will be worked on? Nardog (talk) 15:24, 15 May 2024 (UTC)

This risks sounding like a wishy-washy answer, but the best I can say is this comes down to prioritization and distillation of user problems.

1. How well are we understanding a user's struggle, or struggles relating to a topic?
2. How many other users have felt this pain?
3. What is the impact of solving this problem vs another?
4. With our limited resources, where can we make the most impact with the least effort?

What I can say is that through CommTech's work, we'll try to strike a balance of new functionality and "fixing/improving" things that seem broken.

Impact is hard to measure; are we introducing something that touches billions of people (dark mode), or hundreds of admins (multiblocks)? With CommTech, I think of impact as the number of wishes or focus areas we can address (and what solving each unlocks). JWheeler-WMF (talk) 18:16, 15 May 2024 (UTC)

That sounds like you won't—unless the bug affects either the larger work you're doing or a large number of users. And that's fine... provided other teams are tasked with reducing the technical debt. Small bugs typically don't readily affect end users but accumulate over years and make developers' life difficult; maybe that's not for Community Tech to solve. Nardog (talk) 06:06, 17 May 2024 (UTC)

Agreed that bugs can impact the quality of life for developers. The scale of MediaWiki, bots, gadgets, extensions, etc means that for every bug that CommTech touches, we spend a lot of time context switching, ramping up and down on projects. This impedes velocity and the impact we can make. That's why we think it'd be more strategic for Community Tech to focus on bundles of related bugs that we tackle at once. Meanwhile, we can use the Wishlist as a means of highlighting bugs for the foundation, and getting the right teams to engage. JWheeler-WMF (talk) 15:15, 17 May 2024 (UTC)

We already have Phabricator for that. I don't get the point, sorry. Theklan (talk) 15:59, 22 May 2024 (UTC)

I'm reluctant to say something that has worked well for WMDE can't scale up here. However, I'm curious how these "focus" areas would have worked for popular areas from the last couple of years. For instance, Dark Mode was a lot more popular than anything else in 2023 (35% more supports than the #2) but I don't see other related wishes. So this very popular wish would have just been shunted aside (which I guess it already was since it doesn't look like the web team is making much progress) in favor of other things that could more easily be grouped into a focus area (like I could see rank 2, 5, 6 from 2023 being a focus area)? I see a large benefit from getting to a place where projects like WikiSource, WikiBooks, WikiNews have an easier time getting much needed improvements so that's a good thing for me but I worry about "coalitions" being even more important than they already are for successful wishing (e.g. when enwiki New Page Patrol got a bunch of phab tasks completed as a clear example of a previous Wishlist focus). Barkeep49 (talk) 15:07, 15 May 2024 (UTC)

Hey @Barkeep49 regarding Dark Mode, I'd encourage you to look at what the Web team just shared. It's easy to say that since Dark Mode was a single wish, it would not have been prioritized in the new wishlist. But we knew this was a popular request over many years, and could have framed it as improvements to the reader experience, or relating to accessibility. JWheeler-WMF (talk) 01:50, 20 May 2024 (UTC)

I was personally very happy to read about the concept of Focus Areas. For as long as there aren't any limits to the numbers or kinds of wishes we can express, I can't really find much to worry about in such a concept. Trying to solve problems while addressing multiple wishes together looks like the most logical thing to do. If the found solution doesn't seem to make everybody happy, one can always start a new wish for the variation they want and the cycle continues. In that aspect I'd suggest that Focus Areas maybe should have a small section dedicated to discussing variations of the wishes or at least emphasize such concepts in its discussions. In virtuality we don't have the constrains of the physical world so if we can make the same thing be in 3 colors instead of 1 because it would make more people happy, we should try to do so. This would also reduce the amount of user scripts that circulate, making standardization easier in the global sense. Klein Muçi (talk) 00:43, 18 May 2024 (UTC)

The process changes, but the huge problem beneath may remain: our main problem wasn't how to send ideas, but the WMF not working on them. Is the "focus group" system going to solve a lack of vision, organization and planning problem? I don't think so. Neverthless, I stand to be corrected. -Theklan (talk) 08:16, 18 May 2024 (UTC)

Comments about mockups

Some very general comments about mockups:

The Wishlist mockup has a very technical feel overall UI-wise which maybe won't be that new-user friendly. The overall polished but strict looks usually scare new users away by putting them on pressure to select "the right option". Compare that with the general feel of the old wishlist and the Homepage tab and Growth features. One might say that you don't generally expect new users to go on such platforms and they might be right but then again, if we can afford to help even one more user, why not do so?

The Focus Area mockup has a very static feel. At first glance it looks like a Mediawiki documentation page while we should be trying to emphasize the dynamic nature of the work being done in it. Maybe we should better link active discussions or parts of/information about them in the main page and also put more focus on the wish statuses instead of the explanation texts. One should get the feel that what they're seeing is a work in progress and they are welcome to participate with their opinions or contributions. Compare that page with the pages we get here to notify us about what is new to discuss about the Wishlist. Maybe the page look can change progressively with the state of solving the problem, eventually turning in what we currently see in the mockup when the problem is solved. - Klein Muçi (talk) 01:05, 18 May 2024 (UTC)

PS: Both those points seem to agree with this comment that was given in a discussion above by @JWheeler-WMF:
The Wishlist can be leveraged as a platform to call attention to such feature requests and bugs, and can also be a platform for folks who aren't familiar or comfortable with Phabricator.
This is to say - I don't see Phabricator and Wishlist as mutually exclusive, nor do I see them as the same. Rather, Phabricator is a mechanism for engineers to organize, prioritize, and catalogue work, and the Wishlist is a mechanism to discuss and prioritize problems (which often have associated phab tickets). — Klein Muçi (talk) 01:13, 18 May 2024 (UTC)

I think the mockup is much more new-user friendly, bearing in mind that many newbies don't feel comfortable using wikitext. Johannnes89 (talk) 07:06, 19 May 2024 (UTC)

That is true. But I was referring mostly to interface components. - Klein Muçi (talk) 08:09, 19 May 2024 (UTC)

I don't know why I'm getting a ping about the mockup now, ten days after it was posted, but since I'm being asked: Whatever it will be, support source editing! The mockup looks as if it only supports visual editing, which would suck. Nardog (talk) 08:15, 18 May 2024 (UTC)

@Nardog, apologies your ping took longer.

I began announcements on 9 May, starting from English Village pump but had to pause due to a restructuring of the Future of the Wishlist pages where the announcements had been published (bad timing I know).

To have a back up for such delays and also be able to reach stakeholders who want to receive updates, the team is looking at re-opening the Community Tech Newsletter. Please subscribe, and as always if you have feedback on the newsletter, or comms in general, don't hesitate to share it with me.

@JWheeler-WMF will be in touch regarding the choice of editors for the intake form. Enjoy the rest of your weekend Nardog. –– STei (WMF) (talk) 19:44, 19 May 2024 (UTC)

Yes, the new form will support source editing and a WYSIWYG type editor, to make newcomers feel more welcome in the process. JWheeler-WMF (talk) 01:53, 20 May 2024 (UTC)

Renaming the Wishlist

We’re renaming the Wishlist, and we want to rename it with you. Please read the announcement and propose names if you have any below.

Learn more

–– STei (WMF) (talk) 20:47, 21 May 2024 (UTC)

Come on. Please do not abuse our time any more. Theklan (talk) 06:24, 22 May 2024 (UTC)

Feature Forge –Novem Linguae (talk) 17:38, 22 May 2024 (UTC)

Hey @Novem Linguae this is an interesting name, and we thought of something similar especially because "forge" signals building which is our ultimate goal. Still, it might lead to some confusion with ToolForge, and we don't only want to work on new things. What other ideas might hold onto these principles? JWheeler-WMF (talk) 19:00, 23 May 2024 (UTC)

Community Wishlist Survey –Novem Linguae (talk) 17:38, 22 May 2024 (UTC)

+1 I don't see what's wrong with the current name. Sohom (talk) 07:25, 2 June 2024 (UTC)

Community Kaizen – wikt:kaizen is Japanese for "continuous improvement" and "change for the better". It's a word most would have to learn, but I think it's meaning says a lot about how we strive to be diverse. It's also just fun to say! :) — MusikAnimal ^talk 19:30, 22 May 2024 (UTC)

−1, lame orientalism. Nardog (talk) 10:33, 23 May 2024 (UTC)

+1, sounds fun. Hakimi97 (talk) 17:40, 27 May 2024 (UTC)

It's just a generic word for "improvement". I cringe every time it's used in a way that pays lip service to the same culture that spawned karoshi. Nardog (talk) 19:40, 27 May 2024 (UTC)

If this happens I quit forever. I deal with enough continuous improvement lean six sigma in my work life. Please don't import it to my hobbies too. Now pardon me as I take a gemba walk to figure out some poka yoke. Let's not use a bunch of Japanese words just because Toyoda is Japanese and it feels cool to say we have green belts. ScottishFinnishRadish (talk) 02:44, 1 June 2024 (UTC)

Thanks for your update. I understand the reason why renaming, but it is unnecessary as "Community Wishlist Survey" this name has been is use for several years and it is a familiar name to the broad community. --SCP-2000 04:52, 23 May 2024 (UTC)

Alternative: Community Tech Needs survey or Technical needs survey (which was used on Commons before), if you really don't want "wishlist" this term. SCP-2000 04:47, 26 May 2024 (UTC)

@JWheeler-WMF: What was #Conversation 1: Defining a wish all for if you're ditching "wishlist" anyway? What will what used to be called a wish be called going forward? (If that also depends on the new name for CWS, maybe shouldn't you start with deciding what to replace "wish" with first?) Nardog (talk) 12:05, 23 May 2024 (UTC)

I should have been more clear. The term "Wish" leads to false hopes, confusion, and frustration. Especially as the Community Tech team has historically been the "granter" of wishes, and we cannot respond to all wishes.

As for the replacement term, we think "ideas" are more representative and have a more positive light than "wish." JWheeler-WMF (talk) 19:05, 23 May 2024 (UTC)

I think Community Wishlist Survey is good enough. If the name is too long and needs it to be short and simple, then something like Wishhub probably will do. Hakimi97 (talk) 12:54, 23 May 2024 (UTC)

"Hub" this term should not be used as it means organizational units in the movement. SCP-2000 16:19, 23 May 2024 (UTC)

Community Requests — TheresNoTime (talk • they/them) 13:50, 24 May 2024 (UTC)

Community Ideas --Matěj Suchánek (talk) 13:15, 25 May 2024 (UTC)

Technical Requests (although I do also like Kaizen above) — Sam Wilson 14:59, 25 May 2024 (UTC)

The name is such an institution. A wish is a great positive word, denoting hope that people have when participating. And usually community tech has been able to fulfil this hope. The word ideas is more non-commital. Femke (talk) 13:15, 26 May 2024 (UTC)

Tech Wishes. Or, if you feel wish does not cover Focus Area concept: Tech Needs or Tech Solutions. I would keep it short, “Wikimedia Opportunities registry” looks too long in my opinion. -- Pols12 (talk) 14:48, 29 May 2024 (UTC)

I like your "Tech Needs" idea, @Pols12, and since you've suggested it, I assume that it will be very easy to translate. Perhaps "Community Technical Needs", to differentiate it from developer needs, third-party needs, my own favorite request, etc.? WhatamIdoing (talk) 22:11, 29 May 2024 (UTC)

I'm quite a techie but I feel that including 'Tech' in the name will be off-putting to some folks whose participation we need. We have to remember there's a user-oriented, non-techie side to many an idea. StefenTower (talk) 22:25, 29 May 2024 (UTC)

I agree with this in principle. The current process leans heavily towards a technical audience, and to build the best user experiences, we also need to accommodate the needs of less technical people. JWheeler-WMF (talk) 01:33, 30 May 2024 (UTC)

But if we don't specify that this is a technical project, then we can expect people to think that all requests are fair game. I need my account unblocked, I need a policy changed, I need someone to help me at this article where everyone else has the wrong answer... WhatamIdoing (talk) 04:27, 2 June 2024 (UTC)

I support maintaining the existing name as it is both descriptive and familiar. Dramatically changing the underlying process already makes the process significantly difficult for folks to adjust to. Changing the name makes it more obscure and harder for people to find. I'd suggest using this time to make the new process as thrilling and synergistic as the old process was. StefenTower (talk) 22:20, 29 May 2024 (UTC)

And if we ever entertained changing the name, that can take place after the new process has gelled. I'd hate for us to make everything new and unfamiliar right from the start. Bridge the gap, even if superficially. StefenTower (talk) 22:28, 29 May 2024 (UTC)

Thanks for this. I'm curious what about the old process was thrilling and synergistic, so we can hold onto some of these qualities in the newer system. JWheeler-WMF (talk) 01:34, 30 May 2024 (UTC)

Just seeing this now. I believe I explained that part in a previous discussion regarding the end of the old process, but I don't know where to find it right away. StefenTower (talk) 08:23, 7 July 2024 (UTC)

OK, here it is. StefenTower (talk) 08:29, 7 July 2024 (UTC)

Community feature requests - says what they are and where they come from. Tag everything in phab with that and put it on a board. — xaosflux ^Talk 22:21, 29 May 2024 (UTC)

+1. Surprising a process looking for a title that valued "Participation" and "Collaboration" came up with 3 ways to remove the Community. This proposal is clear and understandable. CMD (talk) 01:27, 30 May 2024 (UTC)

Small concern: feature requests is only one type of software work, and is at risk of unintentionally excluding software maintenance like bug fixes and refactoring. Community software requests might get around this, although suffers from being a very plain title. –Novem Linguae (talk) 02:03, 30 May 2024 (UTC)

Keep the same name, or my second choice is 'Community feature requests - but wishlist really does capture what it is, and keeping community in the name is important.Newystats (talk) 10:28, 30 May 2024 (UTC)

I have attempted to draft a more useful reply to this multiple times but have come up empty. "Community Wishlist" is already well understood, and arguing/voting about changing the name is not a good use of time. AntiCompositeNumber (talk) 03:12, 1 June 2024 (UTC)

+1 to "Community Wishlist". It doesn't need completely renaming. Renaming things can create more confusion, because lots of things will still refer to the old name and there's no continuity. The suggestions on Community Wishlist Survey/Future Of The Wishlist/Renaming all sound like marketing nonsense. The most I would do is drop "Survey" from the end. - Nikki (talk) 08:14, 5 June 2024 (UTC)

This is called Feature Requests pretty much everywhere else in the world and I don't see the need to go all marketing-speak on it. Don't waste time reinventing the wheel. Levivich (talk) 04:53, 1 June 2024 (UTC)

The current name, Community Wishlist Survey, is perfect. If the name must be changed, choose something short – “registry” is terrifying and bureaucratic. TNT’s “Community Requests” is good too, as is “Feature Requests”, but I seriously question the decision-making process that determined this needs to be renamed. Toadspike (talk) 07:30, 2 June 2024 (UTC)

My name suggestion: Phishlist. A fun play on words on "wish" and Wikimedia's Phabricator with it's "ph" prefix (https://phabricator.wikimedia.org/). There's no negative connotation or even an entry on Urban Dictionary https://www.urbandictionary.com/define.php?term=phishlist. The only concern might be a confusion with the social engineering term "phishing". But otherwise, many "fish"-related logos or play on words can be used with a "phishlist", creating nets for wishes on the "phishlist", setting "fishing lures" for wishes (like a call for proposals name), etc. Erictleung (talk) 23:07, 2 June 2024 (UTC)

• Wish McWishlist 12.75.41.67 04:43, 4 June 2024 (UTC)

  Knuckles the Echidna would name it "Wish McWishlist". -- Sleyece (talk) 19:52, 6 June 2024 (UTC)

• Bugs & suggestions or Bugs and suggestions, etc... which comprises of the Fifth Point of the so far reached consensus and would allow to harmonize with the Wikipedia:Wikipedia:Bug reports and feature requests /overwrite it. Respublik (talk) 13:47, 5 June 2024 (UTC)

Without a doubt ""Community Wishlist"--Der.Traeumer (talk) 15:43, 6 June 2024 (UTC)

• Technical ideas, proposed above, would be ok, if the objective is to remove the word "wish". The three initial proposals are completely inadequate because they're way too broad, unless the team also wants to handle opportunities and collaboration extending beyond technical work (e.g. proposals for the annual plan, proposals of WMF bylaws changes, collaboration ideas for chapters, opportunities for outreach by affiliates). I don't really believe that dropping the name "wish" helps in any way with the stated purpose, however. Nemo 16:49, 6 June 2024 (UTC)
• Perhaps there are two pieces: –SJ talk  20:13, 6 June 2024 (UTC)
  1. A Community Priority Queue (or "priority development queue"🏎️💨) which captures aggregate community priorities over time, and isn't done from a blank slate each year.
  2. A Community Wishlist / Community Tech Survey (I still prefer the original name, also used by smaller parallel initiatives in individual communities, which could federate in) which highlights current needs, new ideas, and is used to update to the PDQ.

Context and scope needed

There isn't enough information on the substance of the change and intent of the wishlist for me to vote. It seems you're renaming due to changes in scope or structure, but I don't know what those changes are.

Scope

You say you've outgrown the name "Community Wishlist Survey". What kinds of items might be presented in the survey that don't fit in that name? That would help me consider whether they fit well in the new name. How about better text editor/IDE support for Wikitext markup? The lede of Community Wishlist Survey indicates this is about curation and moderation tools, but Community Wishlist Survey#Current selected projects shows (by my reckoning) that of 9 items, only 5 are about curation and moderation, 3 are for readers, and 1 is for editors. It seems this discrepancy derives from the Community Tech team's mission of curation and moderation, but the 2023 survey defined its scope as "tools and platform improvements." I can't pick a name without understanding the scope.

Structure

"Community Suggestions Portal" seems to describe a permanent place/page for community suggestions, whereas "Community Wishlist Survey" describes an event and a process. Is the intent to always keep suggestions open, even if review of these suggestions may be periodic?

Admittedly, I haven't gone through the related pages to search for this information, but I recommend providing this in the proposal itself, at least by linking to relevant content. This is a really trivial naming decision and we shouldn't expect or encourage editors to put much work into it. Daask (talk) 15:08, 12 June 2024 (UTC)

Pinging discussants about ongoing vote

Thank you to everyone who has provided feedback on renaming the Community Wishlist Survey so far. Notifying you all that we now have 3 names for you to choose from:

1. Community Ideas Exchange

2. Community Feature Requests

3. Community Suggestions Portal

Please visit the voting page to select a name which resonates with you. In case you missed the previous announcement on why we are renaming and the rationale behind the names, please see the Renaming page. –– STei (WMF) (talk) 18:37, 12 June 2024 (UTC)

Community Wishlist Survey is now Community Wishlist

Just in case you missed the renaming vote and discussions, please note that based on your feedback, we will keep the 'Community Wishlist' and remove 'Survey'.

Please read more about the renaming, check out the vote results and learn more about the re-opening of the Community Wishlist on July 15, 2024, in our latest update. –– STei (WMF) (talk) 20:31, 3 July 2024 (UTC)

The Community Wishlist is re-opening July 15, 2024

Here’s what to expect, and how to prepare.

Hello everyone, the new Community Wishlist (formerly Community Wishlist Survey) opens on 15 July for piloting. I will jump straight into an FAQ to help resolve questions you may have:

Q: How long do I have to submit wishes?

A: As part of the changes, Wishlist will remain open. There is no deadline for wish submission.

Q: What is this ‘Focus Area’ thing?

A: The Foundation will identify patterns with Wishes that share a collective problem and group them into areas known as ‘Focus Areas’. The grouping of wishes will begin in August.

Q: At what point do we vote? Are we even still voting?

A: Contributors are encouraged to discuss and vote on Focus Areas to highlight the areas

Q: How will this new system move wishes forward for addressing?

A: The Foundation, affiliates, and volunteer developers can adopt Focus Areas. The Wikimedia Foundation is committed to integrating Focus Areas into our Annual Planning for 2025-26.

Focus Areas align to hypotheses (specific projects, typically taking up to one quarter) and/or Key Results (broader projects taking up to one year).

Q: How do I submit a wish? Has anything changed about submissions?

A: Yes there are some changes. Please have a look at the guide.

I hope the FAQ helped.

You are encouraged to start drafting your wishes at your pace. Please consult the guide as you do so. Also if you have an earlier unfulfilled wish that you want to re-submit, we are happy to assist you draft.

Start your draft (see an example I have), don't hesitate to ask for support. Send me a link to your draft/sandbox via Meta email to help/review it. Alternatively you can leave the link in the Drafts List below.

More on this topic

Drafts List

• User:STei (WMF)/Sample Wish Make it easier for newcomers to create their first article (Sample) –– STei (WMF) (talk) 10:58, 4 July 2024 (UTC)

This comment is to add a signature so the subscribe button works for this heading. –Novem Linguae (talk) 21:55, 3 July 2024 (UTC)

Sorry, I don't know if I'm getting this right. If we propose a wish, have enough votes and momentum, and the Foundation agrees that we are right somehow (because there's no deadline for voting)... it will be added to be done in... at least one year, but maybe two? Am I right? Theklan (talk) 15:05, 5 July 2024 (UTC)

Hey @Theklan - Once you propose a wish, it will be made public to the technical community and WMF for comments. The Foundation will look for patterns between wishes - typically a shared problem - and propose Focus Areas. Volunteers can vote on Focus Areas to signal interest and inform prioritization, and then the Foundation, an Affiliate, or volunteer developers can adopt this Focus Area.

There isn't a set "timeline" for a Wish, in part because wishes come in all shapes and sizes, and some wishes may better articulate a user need than others.

Happy to chat further about this if there's additional confusion. Our goal, for the Wishlist in 2024-5, is to: By the end of December 2024, the new Wishlist better connects movement ideas and requests to Foundation P+T activities: items from the Wishlist backlog are addressed via a 2024-5 KR, the Foundation has completed 10 smaller Wishes, and the Foundation has partnered with volunteers to identify 3+ areas of opportunity for the 2025-26 FY. JWheeler-WMF (talk) 16:57, 9 July 2024 (UTC)

What does KR mean here? Femke (talk) 18:09, 11 July 2024 (UTC)

Key result in the annual plan JWheeler-WMF (talk) 18:09, 11 July 2024 (UTC)

Reopening discussion

Something that doesn't seem clear to me is editing of a wish. I would prefer to accept comments but do the editing on my wish myself (outside of strict technical fixes), unless, of course I have agreed for specified others to help with it. Idea integrity could become an issue with freewheeling editing access. I'd like to be able to say "Comments welcome, but I would like to maintain editorial control". Thoughts? StefenTower (talk) 08:52, 7 July 2024 (UTC)

Hey @StefenTower thanks for the comment. This is a tough call, as some people in the communities prefer to collaborate whereas others seek to write a wish and have it be "done."

Your suggestion of "comments welcome" sounds like a great disclaimer that you can add when you write your wish. For future versions of the Wishlist, we're evaluating a "draft mode" of Wishes for collaboration, and then a submit mechanism which would more or less only allow commenting. JWheeler-WMF (talk) 16:58, 9 July 2024 (UTC)

Thanks. I'm all for collaboration, but at the same time, like in community discussions, I don't want others directly editing my words, potentially changing their meaning to something I did not intend. Collaboration still happens with folks leaving comments and me taking them into consideration to make edits to the idea. Frankly, if someone edits my idea even one time without my agreement, that will sour me on participation. StefenTower (talk) 03:27, 16 July 2024 (UTC)

Past wishes

A number of popular ideas have been proposed in the past, and remain valid today, but have not been reposted every year. Given the value in having a surge of collective energy around ideas w/ active advocates, is there an expected way to help contributors see popular perennial requests as a source of inspiration for this process? –SJ talk  00:27, 12 July 2024 (UTC)

@Sj all previous wishes are still accessible, and moving forward, new wishes will appear in our list. I agree that reviewing other's wishes are a source of ideation and collaboration, and hope we'll continue to keep this momentum. JWheeler-WMF (talk) 00:50, 12 July 2024 (UTC)

Are you only asking about 'inspiration in the process of submitting new proposals in the Community Wishlist' in particular?

I think it would be best if one had a campaign to attract volunteer developers and/or facilitate closing of wishes/issues (such as via badges and/or bounties and/or a leaderboard according to e.g. issue story points × impact/support and generally actively calling for volunteer devs to join) where no year's wishes are prioritized/emphasized over any other's – e.g. a good thing to link is this and maybe these lists could be combined somehow (possibly transclusion). Moreover, one could put greater consideration of the years a much-needed feature has remained open (such as adding sortability to table columns in the app open since 2017 or cats on mobile since 2010) which could also balance out the larger visibility and/or greater energy behind recently proposed ideas. Prototyperspective (talk) 12:07, 24 July 2024 (UTC)

New wishlist notice box wording

As of a few days ago, {{Community Wishlist Survey/Future of the Wishlist Box}} reads,

..."For piloting"? That I have to ask what that means feels like a bad sign for the goal of improving communication with the community, but: What does that mean? Nothing I've seen in any of the other discussions indicated that this was a pilot program (if that's what the term is even referencing), the other communication indicated that it's all hands on deck, full speed ahead. FeRDNYC (talk) 05:12, 12 July 2024 (UTC)