社群愿望清单调查/愿望清单的未来意向/重新设计愿望清单
 |
嘿大家，我是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.