コミュニティ要望調査/優先課題
この記事は読者対象としてボランティアの皆さん、コミュニティ要望調査に強い関心のある人、高度な貢献者を想定しています。文責はコミュニティ技術チーム（Community Tech）にあり、投票〆切後の作業手順について計画を説明します。担当チームとしてソフトウェア開発の手順を述べたいと考えます。この文書のわかりやすさに関して、フィードバックをお待ちしています。
コミュニティ要望調査を実施するたびに新しく提案の一覧ができ、得票順に並べます。過去の体験から、その上位10件を作業対象にしても最適の解ではないとわかってきました。
私たちはむしろ、提案内容を優先する方法を作り上げました。システムに従って透明性のある評価方法を採用します。優先順位をつけると、可能な限りたくさんの提案を完成させる助けになるからです。この点には以下の複数の仮定を立てました。
- どの提案に着手するか選ぶとき、注目度は確かに非常に重要な要素であることに変わりはありませんが、唯一の要素でもないのです。
- 作業する提案は戦略的な順序で取り組むこと、可能な限り多くの件数を実現することが もっとも重要です。
- 技術者とデザイナーは互いの邪魔をせず、相互に協力できる体制が必要。一例として、提案を精査したデザイナーが提案を図などで視覚化すると、技術者は 純粋に技術で対応できる提案に集中できます。
- コミュニティとの意思疎通は、詳細を隠す代わりに透明性を重んじることが最善手法です。可視化は信頼が生まれ対話を築きます。
基準の要約
優先順位の決定に際して、まず得票率上位30件を精査します。その圏外の提案は、年間に実現可能な要望は30件以内と見込んでおり、対象外になります。順位を決めるには得票数、技術面と製品面とデザイン面の複雑さ、さらにコミュニティに及ぼす波及効果を勘案します。検討基準は以下にまとめました。
全ての提案について投票の集計を終えると、順位づけをして作業はそれに従って進めます。その段階で対応できることは次の各点に限定されます。
- 与えられた資源に照らして対象の提案数を最大限にする。
- メンテナンスと複雑さに配慮しつつ、波及効果が最大の提案を選ぶ。
私たちはまた財団の他部署にも相談し、すでに同一の提案に関連したプロジェクトに取り組んでいるかどうか調べます。
技術的な複雑さ
基準
Our engineers estimate how much effort they would need to put into granting a wish. They prioritize less complex (more workable) projects. Whenever something is not clear, they try to overestimate rather than underestimate.
- Technical dependency – we check if the work requires interactions with other Wikimedia Foundation teams. It could be that part of the work needs to be on other teams' roadmap or that we need other teams' input or feedback before we can complete the wish. Examples of these are schema changes, security reviews, adding a new extension, and upgrading third-party libraries.
- Technical research – we ask ourselves if we know how to approach a particular problem. Sometimes we need to evaluate and consider our options before we can start thinking about a solution. Sometimes we need to confirm that what needs to be done can be done or is within what the platform we are working on can handle.
- Technical effort – we ask ourselves how familiar we are with the underlying code and how big or complex the task can be. A high-effort score could also mean that the code we'll be working with is old, brittle, or has some degree of technical debt that will have to be dealt with before we can start working on our actual task.
尺度
以下のそれぞれを1から6の尺度に落とし込みました。
| 1 - 最も複雑性が小さい |
|
|---|---|
| 2 - 中間より低めの複雑さ |
|
| 3 - 複雑さは中間 |
|
| 4 - 複雑さが中間より多め |
|
| 5 - 複雑性が大がかりなとき |
|
| 6 - 複雑性が非常に大がかり |
|
プロダクトと設計の複雑さ
基準
Similarly to the assessments above, our designer estimates what effort should be made to complete a project. They prioritize less complex (more workable) projects. Whenever something is not clear, they tries to overestimate rather than underestimate.
- Design research effort – we seek to understand the level of research needed for each proposal. In this case, the research involves understanding the problem, either at the very beginning through initial discovery work (the scope and details of the project, surveys or interviews with community members), or later in the process through community discussions and usability testing (e.g. how do users contribute with and without this new feature).
- Visual design effort – a significant number of proposals require changes in the user interface of Wikimedia projects. Therefore, we check to estimate the change of the user interface, how many elements need to be designed and their complexity. For instance, using existing components from our design system or creating new ones, keeping in mind how many states or warnings need to be conceived to help guide users, including newcomers.
- Workflow complexity – we ask ourselves how does this particular problem interfere with the current workflows or steps in the user experience of editors. For example, a high score here would mean that there are a lot of different scenarios or places in the user interface where contributors might interact with a new feature. It can also mean that we might have to design for different user groups, advanced and newcomers alike.
尺度
以下のそれぞれを1から6の尺度に落とし込みました。
| 1 - 最も複雑性が小さい |
|
|---|---|
| 2 - 中間より低めの複雑さ |
|
| 3 - 複雑さは中間 |
|
| 4 - 複雑さが中間より多め |
|
| 5 - 複雑性が大がかりなとき |
|
| 6 - 複雑性が非常に大がかり |
|
コミュニティの受ける影響
In contrast to the two perspectives described above, this part is about equity. Practically, it's about ensuring that the majorities aren't the only ones whose needs we work on.
Depending on this score, proposals with similar numbers of votes and similar degrees of complexity are more or less likely to be prioritized. If a given criterion is met, the proposal gets +1. The more intersections, the higher the score. This assessment was added by our Community Relations Specialist.
- Not only for Wikipedia – proposals related to various projects and project-neutral proposals, are ranked higher than projects dedicated only to Wikipedia. [[Community Wishlist Survey 2022/Editing/Autosave edited or new unpublished article|Autosave edited or new unpublished article]] is an example of a prioritized proposal.
- Sister projects and smaller wikis – we additionally prioritize proposals about the undersupported projects (like Wikisource or Wiktionary). We counted Wikimedia Commons as one of these. [[Community Wishlist Survey 2022/Bots and gadgets/Tool that reviews new uploads for potential copyright violations|Tool that reviews new uploads for potential copyright violations]] is an example of a prioritized proposal.
- Critical supporting groups – we prioritize proposals dedicated to stewards, CheckUsers, admins, and similar groups serving and technically supporting the broader community. [[Community Wishlist Survey 2022/Admins and patrollers/Show recent block history for IPs and ranges|Show recent block history for IPs and ranges]] is an example of a prioritized proposal.
- Reading experience – we prioritize proposals improving the experience of the largest group of users – the readers. [[Community Wishlist Survey 2022/Editing/Select preview image|Select preview image]] is an example of a prioritized proposal.
- Non-textual content and structured data – we prioritize proposals related to multimedia, graphs, etc. [[Community Wishlist Survey 2022/Multimedia and Commons/Mass uploader|Mass uploader]] is an example of a prioritized proposal.
- Urgency – we prioritize perennial bugs, recurring proposals, and changes which would make contributing significantly smoother. [[Community Wishlist Survey 2022/Wikisource/Fix search and replace in the Page namespace editor|Fix search and replace in the Page namespace editor]] is an example of a prioritized proposal.
- Barrier for entry – we prioritize proposals about communication and those which would help to make the first contributions. [[Community Wishlist Survey 2022/Mobile and apps/Show editnotices on mobile|Show editnotices on mobile]] is an example of a prioritized proposal.
2022年の投票結果を優先度スコア順に並べた
These scores may change when we start working on the proposals. As we explained above, we have tried to overestimate rather than underestimate. Check out the proposals, in order of prioritization:
| 要望 | 人気の順位 | 集票 | 技術の値 | プロダクトと設計の値 | コミュニティの受ける影響度 | 優先順位の数値 |
|---|---|---|---|---|---|---|
| [[Community Wishlist Survey 2022/Editing/Autosave edited or new unpublished article|Autosave edited or new unpublished article]] | 29 | 69 | 1.0 | 0.3 | 2 | 2.66 |
| [[Community Wishlist Survey 2022/Miscellaneous/Get WhatLinksHere's lists in alphabetical order|Get WhatLinksHere's lists in alphabetical order]] | 22 | 74 | 1.3 | 0.3 | 2 | 2.63 |
| [[Community Wishlist Survey 2022/Search/Enable negation for tag filters|Enable negation for tag filters]] | 26 | 71 | 2.0 | 0.3 | 2 | 2.47 |
| [[Community Wishlist Survey 2022/Wikisource/Fix search and replace in the Page namespace editor|Fix search and replace in the Page namespace editor]] | 11 | 93 | 2.3 | 0.7 | 2 | 2.47 |
| [[Community Wishlist Survey 2022/Multimedia and Commons/Improve SVG rendering|Improve SVG rendering]] | 5 | 108 | 4.0 | 0.8 | 3 | 2.44 |
| [[Community Wishlist Survey 2022/Anti-harassment/Notifications for user page edits|Notifications for user page edits]] | 2 | 123 | 1.3 | 1.7 | 1 | 2.38 |
| [[Community Wishlist Survey 2022/Miscellaneous/Check if a page exists without populating WhatLinksHere|Check if a page exists without populating WhatLinksHere]] | 14 | 89 | 2.7 | 0.7 | 2 | 2.38 |
| [[Community Wishlist Survey 2022/Bots and gadgets/Tool that reviews new uploads for potential copyright violations|Tool that reviews new uploads for potential copyright violations]] | 4 | 109 | 4.3 | 2.7 | 4 | 2.21 |
| [[Community Wishlist Survey 2022/Reading/IPA audio renderer|IPA audio renderer]] | 9 | 97 | 3.0 | 2.7 | 3 | 2.15 |
| [[Community Wishlist Survey 2022/Reading/floating table headers|floating table headers]] | 24 | 73 | 1.0 | 2.7 | 2 | 2.14 |
| [[Community Wishlist Survey 2022/Admins and patrollers/Mass-delete to offer drop-down of standard reasons, or templated reasons.|Mass-delete to offer drop-down of standard reasons, or templated reasons.]] | 25 | 72 | 1.0 | 2.7 | 2 | 2.14 |
| [[Community Wishlist Survey 2022/Editing/Formatting columns in table|Formatting columns in table]] | 19 | 77 | 4.0 | 0.3 | 2 | 2.11 |
| [[Community Wishlist Survey 2022/Editing/Select preview image|Select preview image]] | 8 | 100 | 3.0 | 2.0 | 2 | 2.07 |
| [[Community Wishlist Survey 2022/Translation/Add DeepL as a machine translation option in ContentTranslation|Add DeepL as a machine translation option in ContentTranslation]] | 20 | 75 | 3.3 | 0.0 | 1 | 2.06 |
| [[Community Wishlist Survey 2022/Search/Change default number of search results displayed|Change default number of search results displayed]] | 12 | 92 | 2.0 | 1.7 | 1 | 2.05 |
| [[Community Wishlist Survey 2022/Editing/Better diff handling of paragraph splits|Better diff handling of paragraph splits]] | 1 | 157 | 3.3 | 2.3 | 1 | 2.04 |
| [[Community Wishlist Survey 2022/Mobile and apps/Table sorting on mobile|Table sorting on mobile]] | 17 | 83 | 2.3 | 1.7 | 1 | 1.92 |
| [[Community Wishlist Survey 2022/Miscellaneous/Enhanced Move Logs|Enhanced Move Logs]] | 10 | 96 | 2.7 | 2.3 | 1 | 1.79 |
| [[Community Wishlist Survey 2022/Bots and gadgets/Gadget: Who is active|Gadget: Who is active]] | 26 | 71 | 1.3 | 4.0 | 2 | 1.76 |
| [[Community Wishlist Survey 2022/Admins and patrollers/Show recent block history for IPs and ranges|Show recent block history for IPs and ranges]] | 3 | 120 | 4.0 | 3.7 | 2 | 1.61 |
| [[Community Wishlist Survey 2022/Admins and patrollers/Reminders or edit notifications after block expiration|Reminders or edit notifications after block expiration]] | 20 | 75 | 3.3 | 3.2 | 2 | 1.57 |
| [[Community Wishlist Survey 2022/Wikidata/Autosuggest linking Wikidata item after creating an article|Autosuggest linking Wikidata item after creating an article]] | 12 | 92 | 3.3 | 3.8 | 2 | 1.53 |
| [[Community Wishlist Survey 2022/Mobile and apps/Full page editing|Full page editing]] | 30 | 67 | 2.0 | 3.7 | 1 | 1.42 |
| [[Community Wishlist Survey 2022/Miscellaneous/Allow filtering of WhatLinksHere to remove links from templates|Allow filtering of WhatLinksHere to remove links from templates]] | 6 | 106 | 5.0 | 3.3 | 2 | 1.40 |
| [[Community Wishlist Survey 2022/Citations/Automatic duplicate citation finder|Automatic duplicate citation finder]] | 6 | 106 | 3.0 | 4.2 | 1 | 1.36 |
| [[Community Wishlist Survey 2022/Editing/VisualEditor should use human-like names for references|VisualEditor should use human-like names for references]] | 22 | 74 | 3.3 | 4.0 | 1 | 1.12 |
In addition, if you are interested in viewing a more granular version of the sub-components that make the prioritization scores, we've made the individual sub-components public:
These are proposals which we found will be worked on by other teams at the WMF or third-party open source when we went through the process of estimating their complexities:
| 要望 | 人気の順位 |
|---|---|
| [[Community Wishlist Survey 2022/Anti-harassment/Deal with Google Chrome User-Agent deprecation|Deal with Google Chrome User-Agent deprecation]] | 15 |
| [[Community Wishlist Survey 2022/Mobile and apps/Show editnotices on mobile|Show editnotices on mobile]] | 15 |
| [[Community Wishlist Survey 2022/Mobile and apps/Categories in mobile app|Categories in mobile app]] | 18 |
| [[Community Wishlist Survey 2022/Multimedia and Commons/Mass uploader|Mass uploader]] | 28 |
用語
自発型の利用者調査
ツールとして UserTesting.com などを採用して設計変更案の「試作版」を走らせるなど、果たして要望の正しい解決策に取り組んでいるか理解する -- こちらから説明はしないので「自発的な」テストと呼び（unmoderated）、利用者には設計案が役に立つかどうか、自由意志であちこちクリックして確かめてもらう
定量性のデータ収集
要望の問題点を理解するプロセスとは、利用者が現在の UI をどう操作しているかデータを収集して理解すること -- クリック、訪問、ダウンロード、セッションなどに関するデータが対象。特定の提案に取り組む当初はしばしばデータ不足であり、原因は提案の選定以前にデータの追跡をしていないか、もしくは個人情報保護上の理由が原因でデータが存在しないせい
定質性のデータ収集
要望の問題空間を理解するには、利用者に要望調査の初期段階でインタビューする、あるいはアンケートなどの方法で直接の対話を試み、どこに問題があるのか、解決策の明確な取り組みは何か理解すること
利用者を〈ソース〉する
チームが必要とする情報を提供できる人を探すプロセスとして、私たちの利用者テスト実施に必要な知識を備え、設計や製品の意思決定が正しい方向にあるかどうか判断できる利用者。UserTesting.com などのツールのように、要望によっては技能の高い利用者を求められ、なかなか見つかりません。
コードのリファクタリング（ソースコードの改変）
このプロセスでは既存のコードをもっと保守しやすくすることで、他者もコードに貢献できるようにしつつ、同時に技術面の負債やバグを取り除く。
データベースのスケマ変更
関係型データベースの全体もしくは一部について、論理構造の総体を改変すること。既存のデータベース改変が求められる場合は、まず設計し次にコミュニティ技術チームの外部で特定のチームの承認を受けます。これは通常、必要な時間が長くなりプロジェクトの複雑さが増えがちです。
サードパーティの規範
コミュニティ技術チーム（Community Tech team）以外が決めた規範の一例としてAPIs 類やライブラリがあります。