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)

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)

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)

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)

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

Preview of New Wishlist

As the conversations are ongoing, a list of features and explorations for the new Wishlist has now been published. Please have a look and give feedback.
–– STei (WMF) (talk) 13:39, 27 March 2024 (UTC)

Preview New Wishlist