Badanie Listy Życzeń/Przyszłość Listy Życzeń/Rozmowy

This page is a translated version of the page Community Wishlist Survey/Future Of The Wishlist/Redesigning the Wishlist and the translation is 8% complete.

Outdated translations are marked like this.

Overview: As we redesign the Wishlist, this page documents the conversations we are having with the community to inform the direction of the new Wishlist Survey. We invite you to read the topics discussed and the learnings so far.

Hey y’all, I’m Jack

I’m excited to introduce myself as Wikimedia Foundation’s Lead Community Tech Manager. My primary responsibility is the Community Tech Team’s product and roadmap and to roll out the Future of the Wishlist.

I’ve learned a lot about the Community Wishlist Survey in my few weeks with the Foundation, which I’ve attempted to summarize below:

Please note, given my limited tenure, I will probably get a few things wrong, or generalize some bullets, and I’ll definitely miss things.

What I am learning

The Wikimedia Movement’s greatest asset are its communities. Communities generate and curate content that compel people to seek knowledge, and the Foundation needs to advance its products to support the communities.
The Wishlist represents a diverse audience; voters from 227 communities have participated in the Wishlist, and 41% of participants have had no user rights. As we evolve the wishlist, it should still serve the needs of different groups.
Submitting a wish is arduous, time consuming, and frustrating for both volunteers and staff. We need to make it easier for anyone to submit a wish, 365 days a year, and let volunteers have a voice on what’s most important.
The Community Tech team has delivered on some really impactful wishes since 2015, but many of you have shared that we haven’t done enough to address some of your biggest challenges or opportunities. To make even more impact, we need both WMF engineering teams and volunteer developers to be more involved in addressing wishes.
The Foundation focuses holistically on problems and balances tradeoffs among communities and the projects we serve. We’ve seen success when wishes align or are incorporated in the Foundation’s annual plan. Still, the Foundation needs to better explain why certain wishes aren’t prioritized, and provide ways for community members and volunteer developers to fill some of these gaps.

Community Tech’s goal is to pilot the new Wishlist in July 2024. Until then, we will focus on existing Wishes such as Edit Recovery, Multiblocks, Quickly Add Infobox, and Quickly Add Favourite Templates, and potentially more. In addition, I plan to partner with communities to inform the shape of the Wishlist.

The one thing I ask from you is patience and empathy. We’ve recognized the Wishlist needs to evolve, and the truth is we’ll never get everything perfect on day 1. There will be bugs, we’ll identify gaps in our new process, we’ll make mistakes, and we won’t be able to please everyone all the time. But day by day, I’ll try to make progress towards a healthier and stronger relationship between the Foundation and the Movement’s communities.

I’d love to design the new Wishlist with your input, so I’m kicking off a round of conversations. I won’t be able to speak with everyone 1 on 1, so after each round of conversations, I’ll share my takeaways as I’ve done above.

If you’d like to discuss in a 1:1 conversation, please to schedule a call. If you’d prefer to join the conversation async, please join the conversation on the talkpage.

Thanks so much, I’m excited to meet you and design a better, more inclusive Wishlist together.

Best, Jack

Ps. This is my favorite wikipedia article, to which I’ve contributed.

–– Jack Wheeler

Defining a wish

Historically, wishes have come in all shapes and sizes. They come from communities big and small, and range from bug fixes to specific solutions, from poems to problem statements. We want to embrace the diversity of wishes in our next Wishlist, and help the Community write wishes in a way that helps the Foundation and volunteer developers clearly understand a user’s problem.

Community Tech would like to use this information to inform how we redesign the Wish intake form so the proposer has a higher chance of success when they submit 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?

Discuss

How should volunteers collaborate on Wishes?

I've had a lot of great conversations with Volunteers and people at the Foundation about the Wishlist, and plan to share some early insights and plans for the new Wishlist in the next week or so.

In these conversations, a few Volunteers have surfaced that they've "refined" each other's wishes before submission, so that wishes are polished enough for voting. This has me thinking about our new Wishlist, which will be open 365 days a year: should we allow for Wishes to be editable?

Rozmowa 2:
Czy wolontariusze powinni mieć możliwość edytowania życzeń, własnych lub cudzych? Jeśli tak, to w jaki sposób?

Below, I've laid out a few ideas for how we might approach editing wishes, and I'm curious which concepts resonate with you. If none of these speak to you, please share your thoughts in the talk page.

	Volunteers may not edit each other's wishes	Volunteers may workshop submitted wishes in a “draft" state	Volunteers may edit each other's wishes after submission
In practice	Volunteer submits a wish A Wish page is created that is not editable.	Volunteer submits a wish A Wish page is created in a “draft” state until it is flagged as “ready” for community review.	Volunteer submits a wish A Wish page is created in a "published" state and open for editing and discussion
Comment on wish	Yes
Potential pros	Respects wishes as submitted Conceptually easier to understand	More collaborative, but with an end point where a clear concept is advanced. Refinement of original wish to suit broader needs and functionalities	Volunteers collaborate on wishes with one another and with Foundation Wishes are open for interpretation Concepts continue to evolve as problem space and solution options are discovered
Potential cons	Limits collaboration to comments Potentially misses opportunities to surface great ideas	Wishes may evolve from original intent Wishes may become “too big” to be actionable	Wishes may evolve from original intent Wishes may become “too big” to be actionable

Discuss

Conversations with Wikimedia Foundation's Product and Technology staff

To ensure that Foundation product teams participate in the Wishlist process seamlessly, I also listened to Product Managers about their needs and challenges. Product Managers are staff members on the various Product and Technology teams who are responsible for prioritization and setting direction for the work of engineers and designers who build and maintain products.

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

Discuss

Jack Wheeler's Learnings from Conversations 1, 2, 3

From volunteers

Volunteers want to feel heard via the Wishlist. They want the Foundation to pay attention to wishes, address more tech debt, issues, and opportunities. Volunteers spend a lot of time and effort to draft wishes, and the current process flags certain wishes as too big or too small, which adds to frustration.

Some volunteers view the Wishlist as a “service desk,” where the Community Tech team should build wishes 1:1 from volunteer requests to respond to tech debt. Other volunteers feel the Wishlist is a platform for providing product/tech input to the Foundation as a whole.

Most volunteers believe anything should be a wish, and that wishes should never be closed. Good news: We won’t label certain wishes as “too large,” we will incorporate bugs and feature requests, and we’ll eventually explore an integration with Phabricator.

Volunteers on smaller projects observe that wishes via English Wikipedia often capture the most votes, which risks drowning out their voices. In the future, we need a more equitable way to prioritize wishes.

To improve the quality of a wish, volunteers should have the opportunity to workshop Wishes.

The Wishlist should surface actionable wishes (bug fixes and feature improvements) that can be fulfilled by volunteer developers, individuals, and teams, and surface strategic problem spaces or opportunities that influence our product direction.

From staff

Historically, some Product Managers (PMs) only engage with the Wishlist once a year, and instead leverage their project pages for feedback on planned work and use Phabricator for bugs. To help PMs get visibility on new ideas and impactful improvements, we plan to keep the Wishlist open year-round. We will also experiment with ways to highlight new and popular wishes to further increase visibility and dialogue.

Product teams define objectives and key results (OKRs), a framework used to measure team performance and allocate time and resources, as well as to ensure they contribute to a broader strategy. Historically, these strategies have been defined from roughly March-May, and only once a team’s strategy has taken shape, Product Managers think about how much they are able to contribute toward Wishlist efforts. In a few instances, however, community needs surfaced through the Wishlist have informed a team’s strategy; Edit check is a good example. Moving forward, we think the Wishlist should concretely inform a team’s OKRs, with Product Managers commenting on wishes throughout the year and reaching out to participants for clarity during planning periods.

Product teams want to work with volunteers, and specifically to engage at the problem level and co-create solutions. One Product Manager said, “Maybe the wishlist’s true value is that it’s a place to learn about the needs that people have - and also a space where we can practice - together with volunteers - how to talk (and approach) problems instead of solutions.” Product Managers also want to tackle some of the “smaller wishes” that are actionable, especially when there are short periods between longer feature development cycles.

Phabricator is where engineering teams work, but it’s hard to direct community-created Phabricator tickets to the right team. Too often, Phabricator tickets get lost, and it’s hard to discern volunteer impact (ie, # of complaints, supporters) from a Phabricator ticket. We think the new Wishlist can help with this.

Looking at where we have come from and where we are, how do we fulfill more wishes and make more impact for the Movement? Which changes can we start with?

See potential Wishlist modifications we would like to implement and explore.

See earlier Wishlist decisions we have made progress with.