Talk:Community Wishlist Survey/Future Of The Wishlist/Archive 1

Not another list of stale wishes/patches

I recently got an email communicating about the changes that the Wishlist is expected to go through in the future. Read all there was about that and I can say I am personally excited. The only thing I would like to put emphasis on is on actually having a non-stale dynamic process, whatever form the process might decide to take. During my decade long involvement with the Wikimedia foundation something that has kind of disappointed me was how much the "backlog" concept is actually normalized in many of its areas. Phabricator is full of tasks waiting for decades to be acted upon, Gerrit has patches waiting the same amount of time to be reviewed, small wiki-projects have edits waiting for review, etc. And unfortunately all that is considered a normal aspect of the environment. "This has been requested in task XXXX for more than 10 years now." "Global templates have been discussed for more than 15 years now." "There has been an unreviewed patch for this for 5 years now." These are all phrases we continuously use in different discussions with each other and no one really does much about that.

This was the difference the TechWishlist brought in that aspect: One could assume a wish voted in it had a higher chance to be implemented compared to having the same person open e Phab-Task about the same wish. (Even though sometimes even the voting process wasn't enough to stop the delays.) Therefore I highly hope this property of it gets preserved and improved: Whatever system we choose to implement for the future Wishlist, it should have a dynamic nature. The wishes presented on it should be acted upon rather fast and the background job to implement them should be made transparent to show that actual efforts are being done to make them come to life. This shouldn't mean that we must refuse immediately every wish that is considered a bit "big" (like we sort of did in the old Wishlists) for the sake of preserving the highly active status of the process itself. Or that we should tend to throw "unpopular" wishes (not voted much) under the rug. Rather it should mean that the process should have a strong backbone enough to support such an infrastructure before it begins. We should be aware that once we give the community the ability to freely expresses wishes the whole time, they will do so and we should be able to have the capacity of acting on such work volumes. If we can't guarantee that, we will just end up creating another Phabricator and we don't really want that. - Klein Muçi (talk) 17:49, 4 January 2024 (UTC)

Therein lies the rub. This would be a new ongoing process with its own backlog, and frankly, I believe most serious editors will ignore it, and stick to the usual processes for moving ideas forward in their projects. StefenTower (talk) 18:33, 5 January 2024 (UTC)

Getting rid of community indicating importance

I'm generally positive on the changes described in the diff blog, but only because the WMF has really been walking the walk on this topic. One thing I'm concerned about is "Instead, the new intake system is intended to provide a clearer and more direct way for community members to submit requests. It will also reduce the time burden volunteers spend on proposals and voting in an annual survey." This suggests to me that all wishes are going to be treated equally and foundation will at its discretion get to rank them. I think having no way for the community to provide any sense of which wishes it find important is a real negative. I'm fine with community tech saying "We have to think about projects other than Wikipedias" and "We have to think about the needs of small (and medium) projects not just large ones)" in appropriate ways. But having no way at all for community input would be, for me, a huge step back over the current system which has been (from my vantage point at least) producing real and meaningful results. Best, Barkeep49 (talk) 16:13, 5 January 2024 (UTC)

Hi @Barkeep49! There's no intention of removing the concept of voting, rather your votes will stay indefinitely, as opposed to having to renew them (as well as the proposals themselves) every year. This is what is meant by "reduce the time burden [spent] on proposals and voting." Community Tech will still utilize the prioritization framework to get a general sense of what we can accomplish, with the added benefit that the survey itself will influence annual planning and thus (hopefully) those trickier, higher-ranked wishes get more attention, particularly by other teams. MusikAnimal (WMF) (talk) 22:04, 5 January 2024 (UTC)

I should clarify, the process isn't predetermined and that is why we've made the announcement - to ask what you all think and work on it together! :) MusikAnimal (WMF) (talk) 23:05, 5 January 2024 (UTC)

I think StefenTower's comments about the community building aspect of the wishlist need consideration. I also think at some point "votes" get stale. Editors move on. Or their priorities change. And so something building up cumulative votes over 4 years means something different than something which has support over 4 weeks. Best, Barkeep49 (talk) 23:26, 5 January 2024 (UTC)

Currently, the system was so broken, that even voting wasn't binding. They decided if the voters were right or wrong in another process. So, any improvement would be for better... at least, if it doesn't ask users to trust on a system that wasn't intended to be effective. Theklan (talk) 16:57, 6 January 2024 (UTC)

@Theklan I dunno. I've seen a lot more wishes completed in recent years so something seems to be working better. The foundation provided stats about this too. Barkeep49 (talk) 18:51, 6 January 2024 (UTC)

Well, we have different impressions about this. For me, doing 0/10 top priority wishes in 2022 doesn't seem like "more wishes completed", but as a total failure. If the idea that more wishes have been done was true, there wouldn't be any discussion about closing this, as they would be delivering what the community asks for. Theklan (talk) 13:49, 7 January 2024 (UTC)

Huh? I see multiple top ten wishes done done from 2022 including the top two vote getters and several others partially done. This compares to years where three wishes total would be done or partially done in the late 2010s. Barkeep49 (talk) 16:15, 7 January 2024 (UTC)

The top two were Better diff handling of paragraph splits and 1%. The third one was Notifications for user page edits. None of the three were done by the end of 2022. There was only one from the Top10 partially done in 2022, which was Generate Audio for IPA, which didn't generate audio for IPA. It made other great things, but not audio for IPA. Theklan (talk) 18:30, 8 January 2024 (UTC)

If I recall correctly (but community tech, please correct), the implementation of wishes usually doesn't start directly, as planning is required, and the implementation period is more like mid-2022 to mid-2023 for the 2022 wishlist. That may explain why wishes are often delivered "late". I think this shows quite impressive results: Community Wishlist Survey 2023/Results. Femke (talk) 17:37, 12 January 2024 (UTC)

Three of the top 10 done is impressive? Well, if 30% of work done is impressive, then yes, it is impressive. I would say that is a total failure, but we have different ways of measuring success, I think. Theklan (talk) 10:05, 15 January 2024 (UTC)

Three is impressively better than zero. And when we take into account all the work done by various parties on contest entries whether in the Top 10 or not, I'd say this has been a very impressive venture. StefenTower (talk) 21:12, 15 January 2024 (UTC)

New direction misses positives about wishlist surveys

While I understand these changes are a response to the backlash due to "top 10" items not being fully completed, there were positives to the annual survey that I can't see being replicated in the new process:

1. They were fun. It was like an annual party of ideas.
2. Collective brainstorming happened, with ideas feeding off others in usually very productive ways, leading to work done all around the various projects in response.
3. Holding of editors' interest - the survey attracts attention and excitement but a continuous process at a Wikimedia site few of us rarely tread (Meta) very likely would not. I can only speak for myself, but I'd rather pursue my proposals in more direct manners (e.g. Phabricator issues, bugging/begging script makers, etc.) than post them in a continuous process at Meta.
4. Ranking, per Barkeep49. A burst of community prioritization when all the latest ideas are accumulated in one spot should not be sneezed at.
5. Having a Top 10, even if not fully completed, at least creates an accountability mechanism that everyone understands. Everyone gets it. But also, the Community Tech Team, sometimes lacking necessary resources, should not be made to feel rotten that they can't do it all.

Per the above, I as a longtime editor of the English Wikipedia, would like to formally request that this decision be reversed and we hold the 2024 survey. It hads great value. StefenTower (talk) 18:13, 5 January 2024 (UTC)

I'd second StefenTower's summary above, and also add that another positive feature of the "annual party of ideas" relates to wishes that don't actually need to go forward: person A saying "I wish I could do this" and person B responding "Have you tried functions X and Y, or gadget Z?" I have learned a lot from these exchanges, changing my ways of doing things. Like any Festival, the Wishlist Survey has been a focal point for crowdsourcing new ideas. AllyD (talk) 09:30, 6 January 2024 (UTC)

I second the above summary. Wishlist survey is a chance for global community members (especially people who are not always participate metawiki discussion) to brainstorm. I agree there should be a continuous intake system in future (perhaps replace part of phab?), but the annual wishlist survey should be kept. Thanks. SCP-2000 13:39, 18 January 2024 (UTC)

On community input

The annual wishlist process was important, as it helped to surface problems that were recurring and that affected large numbers of community members. New problems, future problems, and problems affecting smaller numbers of editors (such as specialized anti-abuse, CU/OS tools, and cross-wiki tools) were consistently devalued. The Wishlist being outside of the Annual Plan was also important to its functioning, as it allowed the WMF to continue supporting editors when the larger organization was moving in a different direction. I share the concerns that moving this to a rolling system will have the effect of moving tasks to another backlog where they can be more efficiently ignored by WMF project managers. AntiCompositeNumber (talk) 19:33, 5 January 2024 (UTC)

In the right direction

I'm happy that after a very complex process, that even involved harassing those who proposed to make this move, the WMF finally took a step that I think goes in the right direction. I hope that the new system proposed is better, and not a gatekeeping only created to justify that "the community is heard" when this wasn't actually happening.

I'm only disappointed by one thing. I read on the diff post that the process was now even better than before (Wishathons and lots of things being done) which doesn't make any sense. If this was true, the reason for closing the Wishlist is not justified, as it would be moving in the right direction. I think that it is better to tell the awful truth, than trying to hide it behind a false sensation of wishes being accomplished.

I hope to hear more about the new ways to close the huge tech debt that is making our system more obsolete every day. Sincerely. Theklan (talk) 17:04, 6 January 2024 (UTC)

Reflections on your thoughts/questions about our post

Hi all, thanks to each of you who wrote in with your comments, questions, and concerns over the weekend. If I can attempt to summarize, I’m hearing from a lot of you about what you want in a process, including that it is:

• Well resourced, so there is more technical capacity to make progress on wishes (or whatever we decide to call them) big and small.
• Responsive to expressed community prioritization/ranking.
• Transparent so that it's easier to see what wishes are being worked on and the status of that work.

This list echoes a lot of what I’ve heard in talking to community members about the future of the Wishlist over the past year - and please keep the ideas coming, my team and I monitor this page regularly. Several of you also shared concerns about the next iteration of the wishlist, including that the process will have its own frustratingly long backlog, that there will be no or insufficient community input into prioritization, and that the work won’t or can’t be fun or collaborative.

To these concerns, I can say that there isn’t a design for the new process yet, and in making one, we want to talk to all of you, both here and through broad outreach across Wikimedia communities. I hope that together we can come up with something that is fun, collaborative, responsive, flexible to the expressed needs of different groups, and most importantly, effective at tackling important wishes. This is a process my team and I will start focusing on more heavily in the coming months. That said, I don’t think the new intake process will ever resolve all technical requests - as we have seen in the past some requests we receive are not viable for the way our projects function, or aren’t sufficiently valuable to enough of our users to merit the investment. The key issue is how we can do the best with what we’ve got, both inside the Foundation and within the broader Wikimedia community.

As I wrote in my Diff post, we have some early ideas about how we can do that on the Foundation side. While we already involve multiple teams beyond Community Tech (our recent metrics report since 2021, Comm-Tech completed 10 wishes, other WMF teams completed 30 wishes, and volunteer developers completed 15), there are ways to do this better. This includes better integrating community wishes into our annual plan, which will make sure that larger and more urgent community wishes receive more dedicated time across our engineering teams, rather than being taken on as side projects outside of their regular workflows.

In addition, just like last year, we will be sharing annual plan priorities, ideas and potential areas of work early for feedback from volunteers. This would be a good place to share with us what outstanding technical issues, including which existing wishes should be looked at for next year’s planning. We use your feedback to shape what the final plan looks like. Your ideas for how to improve on that for the coming year is welcome now via Talking 2024. Just like last year, we’ll start sharing and iterating on early ideas for our next plan in February, and continue to iterate on the full plan through May.

Another important step is making wish fulfillment more of a shared endeavor between Foundation staff and volunteers. One idea already in the works is our first ever Community Wishathon, which is scheduled for March of this year. Beyond Wishathons, what else can we do to better bring technical volunteers into this work? How do we create that sense of shared ownership around community technical needs?

Thanks again to everyone reading and following this discussion. We’ll be back with other, more targeted questions about the new process design in the next couple of months. Runa Bhattacharjee (WMF) (talk) 15:35, 8 January 2024 (UTC)

Hello, thanks for your explanation! Furthermore, I would like to ask if there are any plans to post an announcement regarding this Wishlist update on local Village Pump and other community discussion pages (e.g. Wikimedia Forum)? Thanks. SCP-2000 16:47, 9 January 2024 (UTC)

@SCP-2000, yes, we plan to send this announcement to various platforms. For now, when translations are ready, we will post on the German, Hausa, Kiswahili, Spanish, French, Portuguese, Arabic, and Japanese local announcement pages. This should be soon.

We have also contacted individual contributors from various wikis who, over time, have been heavily involved in the Wishlist. –– STei (WMF) (talk) 08:34, 12 January 2024 (UTC)

Runab WMF, thank you for the insightful comment. The transparency in your post is greatly appreciated. I would like to underscore a specific aspect:
That said, I don’t think the new intake process will ever resolve all technical requests. As we have seen in the past, some requests we receive are not viable for the way our projects function or aren’t sufficiently valuable to enough of our users to merit the investment.
I believe we all agree that we shouldn't expect addressing all technical requests. However, it's crucial to recognize the diverse "ecosystems" within the Wikimedia community, where users participate for varied reasons. An individual's interest, even if considered a "niche interest" by the broader community, might be the primary motivation for their involvement.
Some "niche" wishes hold significant importance for entire wikis, so-called "smallwikis." These wishes, though perceived as "niche" in a broader context, can be a crucial point for specific communities. Similarly, considerations for accessibility wishes follow a similar logic. In all these cases, the fulfillment or neglect of such wishes can directly impact the retention of individuals or communities within the Wikimedia fold.
Unfortunately, addressing these nuances is challenging with only a vote-prioritization process as they're generally expected to be, by virtue, "unpopular/not-so-voted wishes" and thus easily overlooked, so I believe we should be careful about such considerations when utilizing it. — Klein Muçi (talk) 11:40, 26 January 2024 (UTC)

Hello @Klein Muçi, I'm so glad you raised these points, and they align very much with our thinking. Wikimedia does indeed have diverse and often disparate sub-communities that often have different needs and priorities. Systems driven by votes can often challenge us as we seekthe balance that can guide us to make sure that we are serving everyone fairly. They especially make it tricky to account for things like what wishes might help a community to grow, what might be more beneficial to newcomers, or what might help users from communities that have been underserved. We will very much appreciate it if you have any thoughts to share with us about how we can balance these concerns while also being responsive to the wishes that generate significant interest. Thank you! Runa Bhattacharjee (WMF) (talk) 15:24, 30 January 2024 (UTC)

Thanks for considering small wikis and sister projects. The existing wishlist structure leans heavily in favour of large wikis (Wikipedia, Wikidata, Commons). Even when the 2020 wishlist intentionally excludes proposals that mainly benefit Wikipedia, the results still ended up being a popularity contest (top 4 out of 5, and top 6 out of 9, being Wikisource). Current structure is also not sustainable when new projects are added to WMF portfolio (Wikifunctions launched in 2023; WikiJournal and Wikispore are the next up-and-coming projects). OhanaUnited^{Talk page} 18:35, 1 February 2024 (UTC)

How to get engagement in continuous process?

One of the cool things of the Festival of the annual wishlist is that it generates a lot of community buzz. It's an opportunity to get together, drawn by big watchlist notices spread around many communities. I'd be sad to lose this, especially with how well last years wishlist went. I'm not sure how a continuous process can replicate this.

I sympathise with people above that the wishlist process also has an accountability aspect to it, that I don't see a continuous wishlist have. Accountability is a two-sided sword, with some in the wider community taking it too far, and making work unpleasant for WMF's coolest team. If this haggling is one of the reasons for moving away from a yearly wishlist, can we examine other options to reduce this around community clerking? Femke (talk) 20:08, 11 January 2024 (UTC)

Agreed that no matter how excellent the new process is made, it will settle into an easily ignorable hum, at a site few Wikipedians regularly tread, when what really works for idea generation is a splash. It's not called a brainstorm for nothing. StefenTower (talk) 20:28, 13 January 2024 (UTC)

Yeah, I fail to see how a continuous wishlist is any different from Phabricator. -- Ahecht (TALK
PAGE) 19:18, 5 March 2024 (UTC)

I guess it will be important to still have a period of banners etc every year to create a festival atmosphere. I understand that depriving the community all year of a way to submit wishes does create a storm of activity though. Commander Keane (talk) 00:20, 6 March 2024 (UTC)

How long until this is implemented?

Dear MPourzaki (WMF), Runab WMF, SDeckelmann-WMF and anyone else who may be able to answer,

How long will it be until the continuous intake system is implemented?

I ask because using current Mediawiki technology we could start the process today. Simply by allowing the community to create Wishes at places like Community Wishlist/en/Dark mode, having people vote at the bottom just like the annual survey (example) and putting in the status of the Wish. Additionally I could probably get someone to write a Toolforge report that is run everyday listing the Wishes by number of support votes (a bit like the "Current leaderboard" here). Frankly, I have potentially hundreds of Wishes ready to add.

Are there any good reasons not to go ahead with this right now? If not I will start a discussion here on meta and see what the consensus is.

Regards, --Commander Keane (talk) 19:38, 22 January 2024 (UTC)

It can work technically doesn't mean it works effectively. Also, the continuous system which is same as previous wishlist cannot solve existing problems (e.g. "it has not been able to keep up with the needs of volunteers, both in terms of the number of wishes shared and the technical complexities of addressing them."). Thanks. SCP-2000 04:52, 23 January 2024 (UTC)

I think something is better than nothing (with no Wishlist this year...) and I am really interested in giving my proposal a go. Not sure what you mean by "cannot solve existing problems". Are you saying we give up? Or that we wait for the pilot in the second half of 2024, hoping it gets deployed, hoping that it can keep up with our needs? Again, I really think the system we can create now has merit.--Commander Keane (talk) 07:00, 23 January 2024 (UTC)

No, I don't mean we give up. I disagree that just changing the annual wishlist survey to continuous without sufficient change, which will not solve existing problems. As I mentioned before, there should be a continuous intake system in future, but the annual wishlist survey should be kept.

Since the community discussion is ongoing, I don't see there is any reasons why the Wishlist survey should be run immediately. I would like to see a better system created based on community input rather than continuing to use the old system. Thanks. SCP-2000 14:43, 23 January 2024 (UTC)

Thanks @Commander Keane for your question - we hope to be able to implement the new system some time later this calendar year. The reason why we're not ready to open something new yet is because there are several parts within the wish intake process that needs to be redesigned to prepare for the new system. This also includes the tools we use for submission and voting on wishes. For this we will be reaching out very soon (estimated mid-Feburary ) on this page to talk more and get the conversation started. Meanwhile the team will continue working on the wishes which you can follow in our updates section. We also recently completed the hiring of our new Lead Community Tech Manager - Jack Wheeler. We are currently onboarding him to join this work, and he will be introducing himself here in a couple of weeks. Thanks. Runa Bhattacharjee (WMF) (talk) 01:19, 25 January 2024 (UTC)

Discussions on Shaping the future of the Community Wishlist Survey

If you have any feedback on the January 4, 2024 update on the future of the wishlist, please leave it in the collapsed section below. –– STei (WMF) (talk) 21:33, 26 February 2024 (UTC)

@STei (WMF) Please do not collapse sections on talk pages, it's not accessible, makes the table of contents confusing, and breaks DiscussionTools. Either archive previous conversations or don't. AntiCompositeNumber (talk) 23:56, 26 February 2024 (UTC)

Agreed. I've undone the collapsing and made it chronological. What STei tried to do is simply not how MediaWiki talk pages work. Even if you try to force a structure, people are going to use New topic and break it. Nardog (talk) 00:21, 27 February 2024 (UTC)

@Nardog, @AntiCompositeNumber, thanks for the formatting feedback. However, I'm checking in case you missed it, would you like to participate in the conversation about designing the intake form for the new Wishlist? We would really appreciate it.

Find below the request we have been circulating:

Hello community, I want to introduce Jack Wheeler, who has recently joined the Wikimedia Foundation as the Lead Community Tech Manager and is responsible for the Future of the Wishlist.

Jack would like to have a conversation with the community, to get input for the design of the new Wishlist Survey, starting with how to define a "Wish."

Community Tech would appreciate you chatting with him; your input will be invaluable.

You can check out Jack's first message to the community, where you can find a link to proceed to book time to talk to him, or share your ideas.

I hope you are able to make time to comment. –– STei (WMF) (talk) 15:58, 5 March 2024 (UTC)

Of course I saw that. It's when you deviate from the oldest-first order that experienced users are more likely to miss new messages. Nardog (talk) 12:15, 6 March 2024 (UTC)