コミュニティ要望リスト調査/要望リストの未来/要望リストの再設計

コミュニティ要望調査の将来像

• はじめに
• 設計変更の対話
• 可能性のある変更箇所
• 新規！名称変更

概要：要望リストの再設計に際して、このページではコミュニティの皆さんと進めている対話を記録し、新しい要望リスト調査の方向性をお知らせします。協議された主題、これまでの学びをご一読ください。

どうも皆さん、こんにちは、私はジャックと申します。

この場をお借りして、ウィキメディア財団のコミュニティ技術チーム主任部長として自己紹介いたします。当職の職責の第一はコミュニティ技術チームの製品とロードマップであり、要望リストの将来像を示すことです。（Lead Community Tech Manager。）

財団着任から数週間で、コミュニティ要望リスト調査に関して多くを学びましたので、以下にその概要をまとめたいと考えます。

私は任期が短いせいで、何かを誤解していたり、あるいは項目のどれかを一般化しすぎているかもしれませんし、もちろん見落としもあるかと思いますので、その点をお伝えしておきます。

私自身が得た学び

• ウィキメディア運動の最大の資産とは、そのコミュニティです。人々が知識を求めるコンテンツを生成し査定するのはコミュニティであり、財団はそのコミュニティを支えるように製品改善を進める必要があります。
• 要望リストとは、実に多様な監修を代表します。世界のコミュニティ227件が要望リストに参加し、参加者の 41% は実は利用者権限のない人々でした。要望リストを進化させるとしても、多様なグループのニーズを汲み取る必要があります。
• 要望の提出は、ボランティアにも職員にも面倒で時間を取られるし、イライラするものです。いっそ、誰でも365日、簡単に要望を出せるようにして、ボランティアの皆さんが最も重要と考えることを発言できるようにしなければなりません。
• コミュニティ技術チームでは2015年以降の実績として、非常に波及効果の大きな複数の要望に取り組んできましたが、多くの皆さんから、実際の最大の問題やチャンスに関して、私たちの仕事はまだまだ十分では ないとのご意見をいただいています。ではもっと波及効果を発揮するには、ボランティア開発者の皆さんにも財団の技術系チームにも、要望提出にもっと深く関与してもらう必要があります。
• 財団は問題に総合的に焦点を当て、私たちがサービスを提供するコミュニティとプロジェクト間のトレードオフをバランスさせます。私たちは要望が財団の年次計画と一致したり、それに組み込まれたりした場合、成功を収めてきました。これまではそうであっても、財団はなぜ特定の要望が「優先されない」か理由をより詳しく説明するべきであり、コミュニティ参加者やボランティア開発者がこれらの格差を一部でも埋める方法を提供しなければなりません。

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.