コミュニティ要望調査2021年
コミュニティ要望調査2021年は終了しています… 合計件数: 268 件の提案、1773 人の投稿者、8596 支持票
この2021年6月より、担当チームでは下記の要望について技術的な工程を開始します。
また並行して製品と設計調査を行う要望は下記のとおりです。
前述の要望よりも、実現できる件数は確実に上回ると予測しています。この7月スタートに合わせて作業工程に組み込み済みのものに絞ったのが、上記の一覧です。
これまで、次の段階へ進むにはどんな手順を経てきたでしょうか？ 2021年要望の優先順位の決定プロセスをまとめました。
調査期間中の開始と終了の時刻を18:00 (UTC) とします。
- 提案の提出、議論、改善: 11月16日 – 2020年11月30日
- コミュニティ技術による提案の査読と整理: 11月23日 – 2020年12月7日
- 投票期間: 12月8日 – 2020年12月21日
- 結果発表: 2020年12月23日
皆さん、こんにちは。
2021年コミュニティ要望調査について、新しい情報をお伝えでき幸いです。さて、今回で6度目となり、プロセスを更新することにしました。
バックログは年に1回：今後、バックログは年に1回とします。具体的には前年から繰り越した案件は、ボランティアの皆さんに年1回、投票してもらうことになります。案件として既出のものを出し直しても、新しい案件を提案してもかまいません。開票が終わると新しくバックログが一式揃います。前回までは複数年のバックログが蓄積され、そのどれからでも案件を提案できていました。今回の改訂により作業の簡素化、最も重要な案件をきちんと述べる、さらに既出の案件の見直しができるようになります。
現状で2019年と2020年から繰り越した案件：両年から合計3件、未着手もしくは作業工番をつけていない要望があります。いずれも多くの票を集めていますので、今回、2021年のバックログに載せます。内訳は2019年の要望から2件で、案件名は差分表示で、またビジュアル編集（VE）で参考資料をお読みください。2020年の要望中、4件は作業中もしくは作業終了です。2020年の1件は未着手で、そのInsert attestation using Wikisource as a corpus（ウィキソースをコーパスとして証明書を添付）を2021年バックログへ取りこみます。2019年度の要望の進捗報告をご参照ください。
定期的に調査して「トップ 10」制度から切り替え：これまでの順位を重視した番付方式（「上位5位」「トップ 10」など）を改めます。理由はこちらです。ソフトウェア担当チームは通常の開発の場合、実際に特定のプロジェクトに取りかかる準備として、大規模な調査をしています。そうするとプロジェクトの実現可能性、作業期間、リスク予測などがあらかじめできるからです。現状のプロセスではその事前調査ができず、遅延やストレス、混乱へとつながりがちでした。これは修正したいです。
新しい方式の導入により、プロジェクトは着手前の精査を行います。要望度の順序に合わせて上位から評価を進めます。この精査期間には、以下の要件を分析します。要望の高さ（つまり得票数）、プロジェクトの規模と範囲、技術的な実現性とリスクならびに従属度（依拠）のレベル、他のチームとの衝突の有無。分析を終えたらわかったことを皆さんと共有します。これはつまり、今後も1年間に複数のプロジェクトに取り組むという意味です。私たちにできることとできないこと（とその理由）をもっと明白にお伝えし、業務計画に関する進捗状況をその年にわたり共有する予定です。
カテゴリ単位で得票表示ボードを分ける：メインの得票表示ボードでは要望全件を表示する標準の構造と、得票数で並べ替える方式を引き継ぎます。それに加え、カテゴリ単位で得票表示ボードを新設します。この方法は大規模なコミュニティ対応の要望（メインの得票表示ボード経由）も、少数コミュニティ対応の要望（個別の得票表示ボード）も作業に取り組めます。作業対象の要望を選定するにあたり、上記の要件が助けになります。
変更する理由：要望集めのプロセスには前から更新が必要だとわかっていました。年月につれて要望件数が増え複雑になったこともあり、ボランティアの皆さんとの意思疎通を改善しなければなりません。それに加えて、すべてのウィキメディアンに対する影響が大きなもの（従来の要望リスト）も、小規模コミュニティからの要望（2020年の実施のとおり）も取り上げていきたいと考えます。そこでプロセス改善について、複数回の協議を行いました。そこから得た知見として、今回の変更があります。総合的にこれらの変更の結果、要望リスト集めのプロセスがさらに透明になり、継続可能で充分な影響力が持てるよう願っています。こうすることで将来的にも要望調査は強化されていくでしょう。これも皆さんのおかげですし、皆さんから提案された要望を読むのをチーム一同、楽しみにしています。
コミュニティ技術チームはウィキメディア財団の作業チームで、活発なウィキメディアの参加者のニーズに合わせて専門性の高いキュレーションや修正用にツールを改良することに特化しています。このチームが基本的に取り組むプロジェクトは、毎年恒例のコミュニティ要望アンケートおいてウィキメディアのコミュニティによって決められます。
実際に活動しているウィキメディアの貢献者は、毎年1回、このチームに取り組んでほしい機能や修正の要望を提出することができます。受付は2週間で、その後、最も関心のある提案に投票をしてください。
提案募集の〆切後、コミュニティ技術チームが要望を精査し、作業対象を数件を選びます。案件の審査基準は以下のとおりです。支持度（得票数）、規模、プロジェクトの主眼、技術的な実現可能性のレベル、リスク予想と依存関係、その他の開発チームとの衝突の予測。ボランティア開発者など、開発チーム内から要望が出る場合もあります。
この調査のプロセスはウィキメディア・ドイツ支部のTechnical Wishes（技術要望）チームが考えたもので、ドイツ語版ウィキペディアで行った要望調査に基づきます。ウィキメディア財団のコミュニティ関与チームから国際的な要望アンケートに支援を受けています。
提案の提出期間にはこの企画の最初の2週間を当てます。
ウィキメディアのすべてのプロジェクトのあらゆる言語版の貢献者の皆さんから、提出期間に提案を受け付けます。2021年に実現させたい新規機能とならんで既存の機能の改善も提案してください。記述する言語に制限はありません。英語以外の言語で記された提案書は、誰でも読めて投票できるように、主催者側で翻訳の手配をしようと考えています。
提案の内容は直接ウィキメディアの貢献者に役立つ明確なタスクとし、簡潔にまとめてください。 提案書には次の事項が必須です。
- 解消するといい問題はありませんか？
- 困っている利用者層とは? (編集者、管理者、ウィキソースの編集者など具体的に)
- この問題の現状は？
- 解決策の内容は？(提案がある場合)
提案はできるだけ具体的に書いてください。「（機能Ｘが）古い」、「改善する必要がある」、「バグが多い」と言うだけでは、何をする必要があるかを理解するのに十分な情報ではないのです。良い提案は、何が問題か、誰がそれに影響を受けているかを正確に説明します。提案について特定の解決策がない場合や、解決策をいくつか思いついたのにどれが最善かわからない場合は、問題ありません。
提案書の提出で、プロセスの開始段階をクリアしました。提案段階の2週間を使ってコミュニティに協力してもらい、投票段階で成功する可能性を高めるために、提案書の改良作業を進めていきます。提案書に対して誰でもコメントできますし、より良いものを目指して質問したり、変更を提案したりしましょう。よく似た提案が複数あるなら合併できます。提案の内容が非常に幅広いなら、より具体的なアイデア単位に分割するほうがいいかもしれません。目標はあくまで、最良の提案をまとめて投票段階へ持ち込むことです。
提案書の提出者は、それを改良する議論に積極的に参加することを期待されますから、変更案を集めたり意見を聞いたりするなど支援役をお願いします。そのためにアカウント1件当たりの提案を3件に制限し、もし投稿が4件以上の場合は3件に絞り込むよう依頼します。とっておきのアイデアをお待ちしています！
同様に提案者は登録利用者に限定し、ウォッチリストを活用して確実に議論の経緯を追い、質問に回答できるようにしています。投票権と同じでウィキメディアのプロジェクトの少なくともどれか1件で活動中の編集者に提案権があります。これらの基準を満たさない場合や、上限の3本に達したのにもっとアイデアを提示したい場合には、他の利用者に働きかけてその人に提案書を出してもらいましょう。
ご注意：ウィキメディア財団 (WMF) が管理する現行の機能の停止や廃止を求めても、コミュニティ技術チームの対応範囲外です。したがって投票の対象に含まれません。
はい、過年度には得票が少なかった提案を、もう一度提出することができます。
昔の調査から案を引っ張ってくる場合は、その案を「自分で引き受けて」ください—つまり、そのアイディアに関する議論に活発に参加し、投票段階で強くなるように積極的に案に何度でも修正を加えてください。前述のように、提案は一人3つまでですし、その中には昨年の調査からの再提案も含まれます。
以前の議論にリンクを貼るのは理解の手助けになりますが、昨年の議論や得票まで複写するのはご遠慮ください。昨年の議論で有意義な指摘を受けた場合には、提案の中に組み込むか新しい提案の中で告知してください。
提出期限の〆切後の1週間を使い、皆さんとともに提案書の査読にとりかかって投票期間の開始に間に合わせます。
活動中の貢献者はどなたでも提案を査読して、応援したいものに投票してください。投票する提案の数に制限はありません。公正さを確保するため投票権は登録利用者に限定し、また登録直後のアカウントによる票は除外する場合があります。
「支持」の票のみ集計した結果により、要望の提案を得票順に発表します。 提案者は自分の提案に対して自動的に支持票を投じたものとして集計します。
そうは言っても投票期間には議論に積極的に参加してください。「不支持」や「中立」の票にコメントを付けて投票する方法があります。議論によって、他の皆さんがどの提案に投票しようか決めやすくなるでしょう。また採用された提案の実現作業にとって、その議論は有益なインプットになるのです。
自分の提案をお知らせするカンバスは適宜、認められています。できるだけ多くの人々に働きかけて構いません。自分が活動するプロジェクトやウィキ・プロジェクト、利用者グループへの呼びかけを奨励します。もちろん票を増やそうと多重アカウントを使ったり投票や賛否の変更を強要することは禁じます。良心的な「投票率を上げる」呼びかけは大歓迎です。
それぞれの提案書の受理は以下の基準に照らします。
- 提案書の主題は技術的変更に関するものとし、方針や社会改革は適用外
- 提案書は問題を述べるものとし、必ずしも特定の解決を求めるものではない
- 主題を十分にしぼりこめているかどうか。関連のないばらばらの問題の寄せ集めは対象外
- すでに他のチームの業務計画に組み込まれていないか、もしくは過去に他のチームにより不受理になっていないか
- 過去にすでにコミュニティ技術で不受理になっていないかどうか
- チームの対応範囲 (英文) に収まるかどうか
コミュニティ技術部門は上記の基準に適合しない提案を不受理にすることがあります。
得票数の順位によって要望の優先順位が決められますが、コミュニティの技術チームは支持票が多い要望を評価し対処する責任を負っています。そのため、コミュニティの技術チームは上位の要望をすべて調査し、技術的なリスク要因と社会的・政策的なリスク要因の両方を評価します。反対票と中立票は潜在的な欠点を明らかにする上で非常に有効です。論議を呼ぶような要望について、コミュニティ技術チームは投票とより合意に基づいた評価とのバランスをとっています。
例えば、2015年の調査ではこれが功を奏しました。「ユーザウォッチリストを実装してほしい」という要望に対し、非常に多くの支持票が集まりましたが、心から反対する票もいくつかありました。コミュニティ技術チームは両方の意見を聞き、このプロジェクトを実行するかどうかについて意思決定しました。
…もう一度、既出の案件を全て載せるだけでいいのでは？
調査を毎年行う主な理由は、より多くの皆さんに参加してもらいたいからです！ これまで調査をきっかけに、担当チームと調査の存在を知った人は増えてきましたし、1年がかりでトップ10位の提案の大部分が実現する頃には、この事業に関心を寄せる人もさらに増え、参加に積極的になってくれると期待しています。ですから、誰にでも新しいアイデアを提案するチャンスがあるようにしたいと考えています。
既出の案件がその後も支持されているかどうか、見極めたいのです。ソフトウェアの改訂に伴って、利用者のニーズも進化していきます。ときには、1年前には熱望された案件が重要でなくなったり、あるいは説明文が現状からずれていたりします。毎年、調査を行うことでコミュニティの要望を再確認できます。
昨年の提案の中にもう一度、検討すべきだと思うものがある場合は、上記の「過年度の提案を再提出することはできますか？」を参照してください。