社群願望清單調查/願望清單的未來意向/重新設計願望清單
 |
嘿大家，我是Jack
我很高興能成為維基媒體基金會的社群技術團隊首席經理。我的主要職責是負責社群技術團隊的產品和規劃，以及推出願望清單的未來意向。
在基金會工作的這幾週，關於社群願望清單調查我學到了很多，我試圖將其總結如下：
請注意，由於我的任期有限，我可能會犯一些錯誤，或者攏統概括一些要點，而且我肯定會遺漏一些東西。
我的學習成果
- 社群是維基媒體運動最珍貴的資產。社群生成和策劃內容，激起人們尋求知識，而基金會需要改進其產品來支持社群。
- 願望清單代表了多樣的受眾；來自227個社群的選民參與了願望清單調查，其中41%的參與者沒有使用者權限。當我們發展願望清單時，它應該持續滿足不同群體的需求。
- 對於志願者和職員來說，提交願望是一項費時費力且令人沮喪的工作。我們需要讓任何人能在任何時日更輕鬆地提交願望，並讓志願者對更重要的事情發表意見。
- 自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?
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 |
|
|
|
| Comment on wish | Yes | ||
| Potential pros |
|
|
|
| Potential cons |
|
|
|
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?
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.