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)

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)

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)