コミュニティ要望調査/よくある質問

ウィキソフトウェアの機能を改善したいと思ったことはありませんか？プラットフォームをより使いやすく、機能的にするための新しいツールのアイデアはありますか？そのような改善のために、他の誰かのアイデアを援助したいですか？調査に参加することは、まさにそれを実現するための方法です。

コミュニティ要望調査に参加することで、ウィキメディア財団チームが取り組んでいるコミュニティ技術のプラットフォーム変更に影響を与えることができます。また、コミュニティ技術と協力してこれらのツールを作成することもできます。

さまざまな方法で参加できます。技術的な知識や長年にわたるウィキの経験は必要ありません：

提案期間では、あらゆるプロジェクトと言語の貢献者が、2023年に実現したい機能と修正の提案を提出できます。

コミュニティ技術チームでは、ユーザー1人あたりの提案の数を10個に制限しています。なぜでしょうか？詳しくは、提案が提出された後の処理を参照してください。10個を超えるアイデアがある場合は、自由に他の人に提案を勧めてください。

よい提案とはどのようなものでしょうか？ 以下に、提案が採用される可能性を高める手順を説明します。

提案は、アクティブなウィキメディア編集者の技術的ニーズに関するものでなければなりません。エンジニアリング作業を必要するものでなければならず、ポリシーや社会的な変更に関するものであってはいけません。

コミュニティ技術チームが提案を拒否するのは、以下のような場合です	エンジニアリングの作業が必要な提案とは次のようなものです
たとえ「技術的な」編集（テンプレートやモジュールなど）だとしても、ウィキの編集のみしか必要でない場合 すでにウィキメディア財団のチームの計画に組み込まれている場合 過去にその提案がコミュニティ技術によって拒否されたことがあるか、他のウィキメディア財団のチームに拒否されたことがある場合 ウィキメディア財団チームが取り組んできた機能の削除または無効化を求める場合	ウィキメディアのプロジェクト群のためのツールを作ること サポート対象外の重要なツールの機能の定義や改善 これらのツールをより有効に活用できるように、より優れたドキュメントを作成すること ガジェット、ボット、ウィザードを作成して、ユーザーがすでに行っている作業を支援すること ウィキメディアのプロジェクト群のためのツールを作ること すでにあるガジェットやボットを修正して、より多くのプロジェクトで作業できるようにすること コミュニティによって作成された頻繁に使用されるコード（ガジェットとユーザースクリプト）をMediaWikiソフトウェアのパーツに変換すること

コミュニティ要望調査で対応できる作業は、コミュニティ技術チームの能力による限りがあります。

チームは財団の「大きなアイデア」に感謝し、無視しません。ただし、一部の提案には、コミュニティテック以外の専任チームが必要です。

そうした提案は、投票の対象にならない別のページに移動されます。その後、そのページへのリンクが他のウィキメディア財団のチームと共有されます。

例:

外部の投票機能セキュアポル SecurePoll をローカルのウィキから使えるようにしてほしい（規模が大きすぎる） 記事に「中立な観点の感知機能」を（POV Detector）（規模が大きすぎる） ウィキボヤージュのモバイル版アプリがほしい（規模が大きすぎる）

ウォッチリスト項目の有効期限 （大きめ） 編集要約からユーザにPingを実行する （理想的な大きさ） 差分からコピー&ペースト （小さめだがが小さすぎない）

その問題がユーザーにとって重要である理由についてコンテキストを提供してください。よい提案とは、次の点を正確に説明するようなものです。

• 問題は何か
• 誰がその問題に影響を受けるのか
• 可能であれば、スクリーンショット、リンク、問題空間に関するディスカッションの詳細を示すトークページを追加します。

これは、コミュニティ技術がどこから作業を開始するべきかを理解するのに役立ちます。

「（x機能）が古くなっている」、「改善が必要」、「バグが多い」とだけ言うような提案ではいけません。それだけでは、何をする必要があるかを理解するのに十分な情報がありません。

提案はどの言語で提出しても構いません。コミュニティ技術は、誰もが提案をより簡単に読んで投票することができるように、ボランティアが文章を翻訳することを奨励しています。詳しくはレビュー期間を読んでください。

例:

より良いボットを追加 （十分に正確でなく、行間を読むには大きすぎる） ほとんどの人にとってウィキをより簡単にする（1つの問題ではなく、多くの変更の原則） 人工知能を実装 （1つの問題ではなく、多くの変更の原則）

差分画面で行われる段落分割の改善 すべてのアクティブなセッションを表示させる ウィキデータを使って検索を改善する

問題を解決する方法を提案する必要はありません。解決策を見つけるのはコミュニティ技術の仕事です。

解決策をあらかじめ提示することが制約になることもあります。たとえば、投票者が誤って特定のソリューションに投票し、あとになって年内に構築が不可能であることが判明した場合、コミュニティ技術は別の方法で解決することになります。

例:

タグ機能（Evernote のように検索とカテゴリ設定を可能にする）（問題についての情報がありません）

一括アップロードプログラム（問題についての情報がありません）

自分の考えに注意を向け、他の場所で起こっているアイデアについての会話の一部にしたいと思うかもしれません。フィードバックを収集し、提案を共有します。これは、投票フェーズの前に、早い段階で行うことができます。このようにして、貢献者は問題について知ることができ、時が来たら参加して投票することを忘れないでください。

また、私たちの販促資料もご覧ください。これらを使用できます。

ここでは、多くの票を集めたいくつかのプロジェクトの一覧を以下に示します。コミュニティ技術チームは、それらに取り組むことを約束しましたが、辞退せざるを得ませんでした。今年中に取り組むことは不可能ではないにせよ、その可能性は低いです。

調査年	投票結果の順位	プロジェクト	説明
2019	2位	ダークモード	他のチームのプロジェクトと重複しています。重複するプロジェクトはデスクトップの改善です。（詳しく読む）
2019	6位	mw.toolbar を元に戻す	この問題はコミュニティ技術チームの介入なしにほぼ解決されました。また、他のチームによって行われた変更を元に戻さないことがコミュニティ技術チームのポリシーです。（詳しく読む）
2019	8位	記事のリマインダー	これは技術的に複雑すぎます。また、別のウィキメディア財団チームによって行われる必要があります。同じ結果を得るには他の方法があります。（詳しく読む）
2019	10位	関係するすべての編集者が利用できる2要素認証	これは技術的に複雑すぎます。また、別のウィキメディア財団チームによって行われる必要があります。（詳しく読む）
2017	6位	その他の言語に関する文書の警告	これは技術的に複雑すぎます。また、コミュニティ技術チームはそのようなツールを構築し、維持することができません。（詳しく読む）
2016	1位	グローバルガジェット	これは技術的に複雑すぎます。また、コミュニティ技術チームはそのようなツールを構築し、維持することができません。
2015	3位	ガジェット、テンプレート、Lua モジュールのための中央リポジトリ
2015	6位	すべての言語でコモンズのカテゴリを許可する	他のチームのプロジェクトと重複しています。重複するプロジェクトはコモンズの構造化データとウィキメディアの曖昧さ回避ページです。
2015	6位	ウィキ横断のウォッチリスト	これは技術的に複雑過ぎます。（詳しく読む）
2015	8位	グローバルなウィキ横断トークページ	他のチームのプロジェクトと重複しています。重複するプロジェクトはフロー・構造化されたディスカッションおよびクロスウィキ通知です。（詳しく読む）
2015	10位	ユーザーをウォッチリストに追加する機能	悪意を持ってこのツールを使用すると、ユーザーへの嫌がらせが容易になる可能性があります。（詳しく読む）

コミュニティは、投票の段階で成功する可能性が最も高い方法でアイデアを提示する提案を共同で作成することができます。

提案が提出されると、誰もがその提案について意見を述べ、質問や変更の提案など、より良いものにするために協力が求められます。

類似した提案を組み合わせることできますし、非常に広範囲な提案はより具体的なアイデアに分割する必要があります。

目標は、投票の段階で可能な限り最良の提案を作成することです。

提案を提出する人は、その議論に積極的に参加し、途中で変更を加える手助けをすることが期待されます。

はい。

もしあなたが以前の調査の提案を新しい調査へコピーし再提出しようとした場合、コミュニティ技術はあなたがその提案を「自分のものとして引き受ける」ことを望みます。それは、あなたがそのアイデアについての議論に積極的に参加し、投票段階に移行する際に、それをより強力なアイデアにするために提案を変更することをいとわないことを意味します。

過去数年間にアーカイブされたいくつかの提案を提出することもできます。例えば、不明確な提案を検討し、より良い説明を行い、提出することができます。

前回の議論へのリンクを貼っていただけると助かりますが、昨年の投票や議論の内容をコピーしないでください。もし、昨年の議論で得られた良い指摘があれば、その提案や注意事項を新しい提案に盛り込んでください。

要望がコミュニティ技術チームによって拒否された場合、それが大幅に変更されていない限り、再提出は不適格です。

例:

• コミュニティ要望調査2021年のアーカイブ
• コミュニティ要望調査2020年のアーカイブ
• コミュニティ要望調査2019年のアーカイブ
• コミュニティ要望調査2017年のアーカイブ

はい。

2023年度は1月23日に開始されます。コミュニティ要望調査サンドボックスを使用してアイデアの作成を始めることができます。これにより、詳細を公開したり、他の人を招待して一緒にアイデアを練ることができるかもしれません。

コミュニティ技術チームの活動領域外ということです。

詳細な説明については、提案の作成方法も参照してください。

提案期間の後、コミュニティ技術チームは投票受付が始まる前に提案をレビューします。

チームは、提案を拒否する必要があるかどうかをチェックします。提案が投票の段階で受け入れられないような問題がある場合は、提案者に連絡して追加の質問をします。

提案が正しい場合、コミュニティ技術のメンバーは、それを翻訳するためのマークを付けます。そうすれば、誰でもその提案を翻訳して、より多くの人が理解できるようにすることができます。

集計される票は、 Support票だけです。

最終的な要望リストは、賛成票の多い順に順位付けされます。あなたが提案者の場合、あなたの提案に対する賛成票は自動的にカウントされます。

参加者は必要な数の提案に投票できます。公正な投票を確保するために、登録ユーザーのみが投票でき、非常に新しいアカウントによる投票は削除されることがあります。

はい。

投票の段階では議論が奨励されます。 Opposeまたは Neutralの投票をコメント付きで投稿したい場合は、自由に投稿してください。

これらの議論は、人々が提案に投票するかどうかを決めるのに役立ちます。また、その議論は1年間を通じて行われる作業の指針となる有用な情報を提供します。

調査が終了したら、コミュニティ技術チームは調査からいくつかの提案を選択して作業します。

提案の人気が選考決定の主な要因ですが、それだけではありません。多くの支持票を得ている提案については、コミュニティ技術は次の点も考慮に入れます。

技術的な複雑さ	プロダクトとデザインの複雑さ	歴史的に十分なサービスを受けていないニーズとコミュニティへの影響
投資が必要なソフトウェアエンジニアリングの労力。 これには、コードのレビュー、他のチームへの依存関係、インフラストラクチャ、法律、セキュリティの制限、データベースの更新などが含まれます。	解決に向けてデータ収集の努力が求められ、その目標は問題を理解して設計を創案、利用者テストによるデザイン案の評価を行い、また利用者体験の特定の一部を変更して影響が発生してもそれをやわらげるため各担当チーム間の調整に役立てることです。 導入は段階的が良いですが、それとも一気に？ 新しい機能のテストに私たちと参加してくれるコミュニティはどれくらいあるか、具体的にどのコミュニティでしょうか？	提案はWikimedia projectsのサポート不足に関するものですか? 異なるWiki間で機能しますか? どれくらいの人が改善の恩恵を受けられますか? テキスト以外のコンテンツの対応に関することですか?

最終的なスコアは、上記のすべてを組み合わせたものです。次に、コミュニティ技術チームは最終的なスコアが最も高い提案に取りかかります。

有志の開発者や他のチームによって、要望がかなえられる場合もあります。

コミュニティ技術チームでは、投票数だけでなく、要望の複雑さも考慮に入れます。これにより、チームは作業を分散させ、より多くの要望を実現させることができます。

また、投票数だけに注目することは公平性の問題が生じます。グローバルグループのような少数グループや、小規模なWikimediaプロジェクトのコミュニティも存在します。単純な投票では、彼らは容易に劣勢に立たされ、支援不足の状態が続くでしょう。

それは、要望の複雑さに応じて、年によって異なります。

コミュニティ技術チームは、どのくらい要望に対応できるか予測できないため、確実な対応の件数を約束することはできません。チームは、できるだけ多くの要望を実現するために努力しています。その年のチームのエンジニアやデザイナーの数など、複雑さやリソースによって、実現できる要望は変わってきます。

かつては、コミュニティ技術チームが「上位何位」の要望の実現を約束し、7月から6月の間に達成しようとした時期がありました。ときには、その複雑さゆえに予想以上に時間がかかることもありました。また、チームが急いで仕上げようとした場合もありました。また、このことは、チームが「過剰な約束」をしてしまうことを意味し、ボランティアの信頼を損なってしまう可能性がありました。

2020年、コミュニティ技術チームは、自分たちが実現する要望の総件数を約束することを取りやめました。

• 当チームの最近の活動は更新情報を掲載したページをウォッチリストに入れてください。
• あわせて、コミュニティ要望調査のメインページ付属のトークページはじめ、個別のプロジェクトのトークページをウォッチリストに入れてはどうでしょうか（最近の変更点については、以下のボックスを参照してください。）。
• 個別の要望はコミュニティ要望調査のメインページの集計表に、それぞれの現状を示します。
• コミュニティ技術チームでは、毎月1回、Talk to Us（話しませんか）というオンラインミーティングを開催しています。皆さんどなたでも参加してください。

いいえ。

ウィキメディアムーブメントでは、技術的な変更に多くの組織や個人が取り組んでいます。ボランティア、ウィキメディア提携団体、ウィキメディア財団です。コミュニティ要望調査は、ウィキメディア財団という1つの組織のプロジェクトにすぎません。

ウィキメディア財団で技術プロジェクトに取り組むのは、製品部門と技術部門という2つの部門です。どちらの部門にも、チームはいくつもあります。コミュニティ要望調査は、コミュニティ技術チームという1つのチームのプロジェクトにすぎません。

……以前の調査にあった他の要望には対応しないの？

コミュニティ技術チームの優先事項は、コミュニティの優先的なニーズに適合していく所存です！

ソフトウェアの改訂に伴って、利用者のニーズも進化していきます。ときには、去年の素晴らしい要望がそれほど重要でなくなったり、あるいは説明文が現状からずれていたりします。毎年、調査を行うことでコミュニティの要望を再確認できます。

いいえ。

コミュニティ技術チームでは、過去に作成した機能のメンテナンスも並行して担当します。そのため、可能性としても現実問題としても、新規の課題全体を遂行できるかどうか、しわ寄せが出ることがあります。

コアな貢献者から寄せられた声に直接、対応した結果、このチームを設置し、仲裁用ツールやボットおよびその他の機能をよりよくサポートしており、ウィキメディアのプロジェクト群の成功を補助しています。

この調査過程はそもそもウィキメディア・ドイツ協会^※の技術要望チームが創始したもので、かつてウィキペディアのドイツ語版で要望調査を実施しました。（※＝Wikimedia Deutschland）

コミュニティ技術チームでは2015年11月、初めてコミュニティ要望調査（ Community Wishlist Survey）を実施しており、ウィキメディアの編集者にとってどの機能や修正項目がもっとも有意義か識別をしました。ウィキメディアのすべてのプロジェクトに向け、貢献者の皆さんに提案の応募を呼びかけました。募集期間の2週間が過ぎると、チームは皆さんにいちばん関心のある企画に投票をお願いしました。このような手順を毎年、繰り返してきました。

この手順に改善点を提案したいなら、アンケートのトークページにぜひ投稿してください。いろいろな発想について協議したいところです！

質問やフィードバックをお寄せください。当該のトークページ に投稿、または「話しませんか」ミーティング（Talk to Us）で述べてください。

あるいは担当者宛にご連絡ください。

• Natalia Rodriguez – コミュニティ技術チーム製品管理者
• Sandister Tei – コミュニティ技術チーム コミュニティ関与専門家