커뮤니티 위시리스트 설문조사/위시리스트의 미래/위시리스트 재설계

커뮤니티 위시리스트 설문조사의 미래

• 소개
• 대화 재설계
• 잠재적인 수정
• 이름 바꾸기

개요: 위시리스트를 새롭게 디자인하면서, 이 페이지는 새로운 위시리스트 설문조사의 방향을 정하기 위해 커뮤니티와 나누는 대화 내용을 담고 있습니다. 지금까지 논의된 주제와 얻은 내용을 읽어보시기 바랍니다.

안녕하세요 여러분, 저는 잭이에요

위키미디어 재단의 수석 커뮤니티 기술 매니저로 소개하게 되어 기쁩니다. 제 주요 업무는 커뮤니티 기술팀의 제품과 로드맵을 관리하고 위시리스트의 미래를 구현하는 것입니다.

저는 재단에서 근무한 몇 주 동안 커뮤니티 위시리스트 설문 조사에 대해 많은 것을 배웠습니다. 아래에 요약해 보았습니다.

제 임기가 짧기 때문에 몇 가지를 틀리게 쓸 수도 있고, 몇 가지 요점을 일반화할 수도 있으며, 확실히 놓칠 것도 있을 것입니다.

제가 배우고 있는 것

• 위키미디어 운동의 가장 큰 자산은 바로 커뮤니티입니다. 커뮤니티는 사람들이 지식을 추구하도록 유도하는 콘텐츠를 제작하고 큐레이션하며, 재단은 커뮤니티를 지원하기 위해 콘텐츠를 개발해야 합니다.
• 위시리스트는 다양한 사용자층을 대표합니다. 227개 커뮤니티의 투표자들이 위시리스트에 참여했으며, 참여자의 41%는 사용자 권한이 없었습니다. 위시리스트는 계속해서 발전해 나가면서 다양한 그룹의 요구를 충족할 것입니다.
• 희망 사항을 제출하는 것은 자원봉사자와 직원 모두에게 힘들고, 시간이 많이 걸리고, 답답한 일입니다. 우리는 누구나 365일, 언제든 희망 사항을 제출할 수 있도록 해야 하며, 자원봉사자들이 가장 중요한 것에 대해 목소리를 낼 수 있도록 해야 합니다.
• 커뮤니티 기술 팀은 2015년 이후 정말 의미 있는 희망 사항들을 이루어 왔지만, 많은 분들이 가장 큰 어려움과 기회 중 일부를 해결하기 위해 "충분히" 노력하지 못했다는 의견을 주셨습니다. 더 큰 효과를 거두기 위해서는 WMF 엔지니어링 팀과 자원봉사 개발자들이 모두 소원을 이루는 데 더욱 적극적으로 참여해야 합니다.
• 재단은 문제에 총체적으로 집중하고, 커뮤니티와 우리가 지원하는 프로젝트 간의 균형을 유지합니다. 재단의 연간 계획에 희망 사항이 일치하거나 반영되었을 때 성공을 거두었습니다. 하지만 재단은 특정 희망 사항이 '우선순위에 포함되지 않는' 이유를 더 명확하게 설명하고, 커뮤니티 구성원과 자원봉사 개발자들이 이러한 공백을 메울 수 있는 방법을 제공해야 합니다.

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?

대화 2:
자원봉사자들이 자신의 희망 사항이나 다른 사람의 희망 사항을 수정할 수 있어야 할까요? 그렇다면 어떻게 해야 할까요?

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.