コミュニティ要望リスト/有効な要望の書き方
有効な要望を書くには
We would like to hear about suggestions for improvements to Wikimedia projects. As Commtech, we want to be able to split our work into smaller bits, wishes should be bigger than a bug, but take less than a year in terms of engineering work. As we are aware of the fact that sunsetting a tool can be a considerable amount of work, we do also take in wishes that suggest removing technology to understand the interest. In any case, we will try to triage work collectively as a Foundation and forward it to the relevant internal stakeholders to raise awareness about community needs.
優先順位付け
To be able to prioritise incoming wishes, we cross-check them with strategic goals targeted through the Annual Plan. It’s not a prerequisite to read the Annual Plan before making a wish, but you can do so if you want to further understand the triage process. Moreover, we also take a look at three main factors to determine whether to scope and try to implement a wish:
- Wishes that have a clear and measurable impact on the community, such as increasing engagement (editing, search, discovery, etc), versus wishes where it may be harder to measure impact of the work (if at all);
- Wishes that don’t have a workaround at all to ease the underlying problem versus those that do have a workaround (intuitive or not);
- Wishes that have a wide scope for a critical set of features or users versus wishes that may just be relevant for a limited set of users (e.g. nascent feature, power users).
More specific criteria:
| Priority | Impact | Severity | Community scope |
|---|---|---|---|
| Highest | Measurable impact to OKR metrics | No workaround and may further deteriorate | Widespread and reproducible for a core feature or set of users |
| High | Non-core metrics are trackable or likely correlated | Complex workaround degrades UX or creates technical debt | Reproducible for sure, but not widespread enough for most users |
| Medium | Unclear whether wish would have any measurable impact | Intuitive workaround exists for users to circumvent issue | Not consistently reproducible - might be a niche use case |
| Low | No measurable impact | No severity - just a way to better polish a feature | Scope is unknown or may be unique use case |
This is not an exhaustive list, but just to give you transparency about what goes through our triage process. Regardless of how many votes a wish receives, we do triage everything and you can help us by providing more context with the tips above.
範囲外の要望
It’s unlikely we will work on technical edits or work that requires policy changes. In many cases, creating a whole new application or algorithm might be out of scope. The WMF will not create gadgets or bots, but you're welcome to add wishes for gadgets/bots for consideration by members of the community.
Focus on a problem, not a specific solution
「有効な要望」には正式の定型はありませんが、提案者の皆さんには直面する単一の課題に対して、明確な解決策を提示するのではなく、できるかぎり明確に課題内容をご説明いただき、ボランティアと（財団）職員が共に問題を解決する余地を設けていただくようにお勧めします。
要望は、利用者の課題と目標を示し、他の人の同意が得られることを明らかにするものが良いです。ニッチすぎたり具体的すぎて、他の利用者が解決法のあら探ししたくなる要望は避けましょう。
以下の要望の例では、課題主導型と解決策主導型の両方で「新規編集者」の経験改善を示唆しています。
課題主導の例は、解決策を（回答に制約を設けない）オープンエンドにすることで、協業を促しますが、解決策主導の例は、「利用者サンドボックス」の名前を変更することに抵抗する利用者から否定的な意見が寄せられるかもしれません。
したがって、課題主導の要望の方が、特定の重点領域に割り当てられる可能性が高いかもしれません。
| 課題主導型の要望（推奨） | 解決策主導型の要望（非推奨） | |
|---|---|---|
| 「要望」名 | 新規利用者がはじめての記事を作成しやすくしてほしい | 「サンドボックス」を「下書きエディター」に改名してほしい |
| 説明 | 特に新規利用者にとっては、サンドボックスを見つけるのは難しいことです。一旦サンドボックスを見つけると、新規利用者は多くの免責事項を目にし、良質な記事を書く自信を無くしてしまいます。これは新人がウィキペディアに参加し、寄稿者としての自信に影響を与えます。これは一部にデザイン設計の問題だと思います。私たちはパトローラーの作業フローに配慮する必要がありますが、このような経験は、新規利用者のウィキペディアへの参加の妨げとなっています。 | 「サンドボックス」という用語は新規利用者を混乱させます。記事の下書きを開きやすくするために、「下書きエディター」に改名しましょう。 |
| 分類 | システム変更のご要望 | 機能についてのご要望 |
| プロジェクト | ウィキペディア | ウィキペディア |
| 影響を受けている利用者 | 新規利用者、そして新規利用者による編集をレビューする巡回者 | 寄稿者 |
| Phabricatorタスク | 省略可能 | T123456 |
Wishes that combine multiple problems should also be avoided. It may be that voters agree with some problems and ideas, but disagree on others. Likewise, the Foundation and stakeholders may find multifaceted wishes challenging to tackle if they involve multiple software components.