コミュニティ要望調査/よい提案の作り方

• メイン
• 協力のお願い
• よくある質問
• 結果発表

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

コミュニティ技術の活動領域内であること

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

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

1年間かかるプロジェクトよりは小さく、バグ修正よりは大きく

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

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

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

例:

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

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

1つの特定の問題を取り上げて、それについて詳しく説明する

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

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

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

「（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位	ユーザーをウォッチリストに追加する機能	悪意を持ってこのツールを使用すると、ユーザーへの嫌がらせが容易になる可能性があります。（詳しく読む）