コミュニティ要望調査/優先課題

This page is a translated version of the page Community Wishlist Survey/Prioritization and the translation is 100% complete.

この記事は読者対象としてボランティアの皆さん、コミュニティ要望調査に強い関心のある人、高度な貢献者を想定しています。文責はコミュニティ技術チーム(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 - 最も複雑性が小さい
  • 技術面の解決策は非常に簡単 - 課題はコードベースだけでなく利用者体験の部分にもある。
  • すでにコミュニティ参加者による開発が済み、解決策は公開のリポジトリに置かれたガジェット、拡張機能またはコードの形式で存在している可能性あり
  • 技術系コミュニティの参加者はコード書きに精通しています
  • 軽めのQ&A形式のテストが必要、タスク1件分相当のQ&A
2 - 中間より低めの複雑さ
  • 技術面の解決策は個別対応 - 課題はコードベースだけでなく一部は利用者体験にもに存在
  • すでにコミュニティ参加者による開発が済み、解決策は公開のリポジトリに置かれたガジェット、拡張機能またはコードの形式で存在している可能性あり
  • 技術系コミュニティの参加者はコード書きに精通しています
  • 保守作業はほとんど不要
  • コードに必要なリファクタリングは非常に少ない
  • サードパーティのコード依存が発生する可能性
  • 軽めのQ&A形式のテストが必要、タスク5件分未満のQ&A
3 - 複雑さは中間
  • 技術面の解決策は無制限 - 課題はコードベースあるいはリポジトリの一部または多分野に加え、利用者体験の多くの部分にも存在
  • 解決策は部分的もしくはゼロ
  • 技術系コミュニティの参加者はこのコードに慣れていないか知識不足です
  • 保守作業は多少は必要
  • コードのリファクタリングを求められる可能性あり
  • 一時的にサードパーティのコード依存を追加する
  • リリース前にQ&A形式のテストが必要、タスク5件超のQ&A
4 - 複雑さが中間より多め
  • 技術面の解決策は無制限 - 課題はコードベースあるいはリポジトリの一部または多分野に加え、利用者体験の多くの部分にも存在
  • 解決策はまだ実施していない
  • 技術系コミュニティの参加者はこのコードに慣れていないか知識不足です
  • 保守作業は必要
  • ある程度のデータベースのスケマ変更が必要な可能性あり
  • コードのリファクタリングが必要
  • 認証/セキュリティ要素の変更が必要すなわち対象は認証、機能フラグ、アクセス制御など
  • 一時的にサードパーティのコード依存を追加する
  • リリース前にQ&A形式のテストが必要、タスク5件超のQ&A
5 - 複雑性が大がかりなとき
  • 技術面の解決策に未知数あり - 課題はコードベースあるいはリポジトリの一部または多分野に加え、利用者体験の多くの部分にも存在
  • システムもしくはツールを新しく開発する必要があるだろう
  • 技術系コミュニティの参加者はこのコードを理解していません
  • 保守作業は必要
  • ある程度のデータベースのスケマ変更が必要な可能性あり
  • コードのリファクタリングが必要
  • 認証/セキュリティ要素の変更が必要すなわち対象は認証、機能フラグ、アクセス制御など
  • 一時的にサードパーティのコード依存を追加する
  • リリース前にQ&A形式のテストが必要、タスク5件超のQ&A
6 - 複雑性が非常に大がかり
  • 技術面の解決策に未知数が多数 - 課題はコードベースあるいはリポジトリの一部または多分野に加え、利用者体験の多くの部分にも存在
  • システムもしくはツールを新しく開発する必要があるだろう
  • 技術系コミュニティの参加者は提案に関連のあるコードベースを理解していません
  • 保守作業は必要
  • コードには相当な量のリファクタリングが必要
  • 難易度が高いデータベースのスケマ変更が必要な可能性あり
  • コードには相当な量のリファクタリングが必要
  • 認証/セキュリティ要素の変更が必要すなわち対象は認証、機能フラグ、アクセス制御など
  • サードパーティのコード依存を追加する
  • リリース前にQ&A形式のテストが必要、タスク10件超のQ&A

プロダクトと設計の複雑さ

基準

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 - 最も複雑性が小さい
  • 設計のソリューションは要望提案自体に折り込み済み - 技術面の修正であり、UI の変更は必要
  • データ収集は不要
  • 発見ユーザー調査収集はありません
  • 自発型の調査は不要
  • 設計なし
2 - 中間より低めの複雑さ
  • 変更は状態の数を制限し体験内の1ページ単位に分離されます(つまり変更の影響はウィキメディアの1プロジェクトに対して1ページのみ波及)
  • 初期段階で聞き取り調査または定量性データを採用したデータ収集の必要は限定的もしくは不要 - 目標は利用者行動やなかなか解決しない問題(ペインポイント)の理解
  • 自発型の調査の実施はごくわずかもしくは不要
  • 製品と設計に関して情報に基づいた決定ができるよう、この要望に取り組む以前に、あらかじめ必要なデータ収集を実施済み
3 - 複雑さは中間
  • あらかじめ必要なデータをだいたい収集済みだが、問題を理解してから要望に取り組むには、新しいデータ追跡の必要があるかもしれない
  • 自発型の利用者調査が必要だが、利用者をその作業用に「調達する」難易度は低い
  • 体験の関連ページは1ページ超あるが、ほとんどの場合は経験そのものの単一の直接の下位集合にしぼり込む
  • 設計は利用者ニーズの単一タイプに限定
4 - 複雑さが中間より多め
  • 必要そうなデータを多少は収集して製品と設計に関して情報に基づいた決定ができる備えをしたが、問題を理解するには、新しいデータ追跡が必要かもしれない
  • 自発型の利用者調査が必要だが、利用者をその作業用に「調達する」難易度は低い
  • 体験の関連ページは1ページ超あるが、ほとんどの場合は経験そのものの単一の直接の下位集合にしぼり込む
  • 要望関連の最初に調査が必要
  • 対応は利用者のニーズ2タイプに限定
  • 体験の関連ページは1ページ超あるが、ほとんどの場合は経験そのものの単一の直接の下位集合にしぼり込む
5 - 複雑性が大がかりなとき
  • 定質性の発見と定量性のデータ収集が必要
  • 自発型の利用者調査が必要な上、要望の複雑さのせいで利用者をその調査に「調達する」難易度が高い
  • UIに新しい技術情報を導入する必要があるかもしれない
  • 作業中に複数ページの修正が必要
  • 要望関連の最初に調査が必要
  • 作業中に複数ページの修正が必要、もしくはプロジェクト全体に影響を与える
  • 利用者の以下のようなさまざまな段階に影響
    • 編集者
    • 閲覧者
    • 査読者その他
6 - 複雑性が非常に大がかり
  • 質的な発見と量的なデータ収集のプロセスを介した調査
  • 物議を醸す可能性があるため、コミュニティと協力して軽減が必要
  • 自発型の利用者調査が必要な上、要望の複雑さのせいで利用者をその調査に「調達する」難易度が高い
  • UIに「学習曲線」に応じた設計または新しい技術情報を に導入する必要がある
  • 作業中に複数ページの修正が必要、もしくはプロジェクト全体に影響を与える
  • 利用者のさまざまな段階とニーズにわたる波及効果:
    • 編集者
    • 閲覧者
    • 投稿者
    • 新規利用者

コミュニティの受ける影響

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 類やライブラリがあります。