コミュニティ要望調査/説明文書

コミュニティ技術チームはウィキメディアの活発な編集者のニーズに対応し、専門家に焦点を当てたキュレーションおよびモデレーションツールの改善を目指します。このチーム設置はコアな貢献者の要望に直接応じた結果であり、仲裁用ツールやボットおよびその他の機能に対するサポート改善によりウィキメディアのプロジェクト群の成功を支援します。

2015年11月にはコミュニティ技術チームが初めてプロジェクトを横断したコミュニティ要望調査を実施し、ウィキメディアの編集者にとって最も重要な機能と修正箇所の特定を助けようとしました。ウィキメディアのプロジェクト群に呼びかけ、貢献者の皆さんにコミュニティ技術チームに提案をあげるようお願いしています。提案の募集期間は2週間で、続いていちばん関心がある提案に投票をお願いしました。それ以降、この工程が恒例となって現在に至ります。

設計思想

コミュニティの要望が既に多数あることを認識していますが、それらの大部分はコミュニティによって選別や優先順位付けがされておらず、古いものが多く明確に範囲を定義した要望はほとんどありません。付け加えるなら、技術面の要望調査として、ウィキメディアの多数のプロジェクトに積極的に関与したものを他に知らないこともあります。

アウトリーチ

チームは、できるだけ多くの編集者とコミュニティから意見を求めています。その実現には、コミュニティ関与チームおよびコミュニケーションチームの協力を得てアウトリーチ戦略を策定します。この戦略の場にはブログの投稿やサイトの通知、トークページへの招待や井戸端の通知、メーリングリストや技術ニュースの投稿、チャットルーム (IRC) やSNSその他を含みます。

実現の場

調査そのものはメタ上で実施します。第三者のツールを使わずオンウィキで行う理由は、以下のとおり複数あります。

• 編集者は定義上、ウィキを快適に使用しており、より専門的なソフトウェアよりもウィキの透明性と柔軟性を好む場合が多くあります。コミュニティ自体の調査や世論調査はほとんどの場合、ウィキ上で実施し、たとえば、年間優秀写真賞 Picture of the Year のような比較的複雑な投票も対象です。
• ウィキで議論と投票を簡単に並行して進行させます。
• もしコミュニティのボランティアがオンウィキであれば、提案の翻訳は楽に手がけることができます。

担当範囲

理想はコミュニティ技術チームの担当範囲に沿った提案がされることです。具体的には、提案は明確に定義された個別のタスクで、直接コアなコミュニティに利益をもたらす必要があります。その担当範囲外のタスクは不採用になるか、他の開発チームに紹介される場合があります。

参加の要件

調査に参加するには (提案をあげる場合も投票する場合も) 利用者はアカウント登録をしていて調査前に善意の編集の履歴があり、または活発な開発者として Toolforge に参加している必要があります。ただし、議論には匿名利用者 (IP 利用者) ほか誰でも参加できます。ウィキを横断した編集回数は Special:CentralAuth で検証できます。

第1フェーズ：提案をあげる

調査の第1フェーズでは、技術的な要望の提案を募集します。1人につき提案は3件に制限されます。コミュニティは調査の第1フェーズで一貫して提案の整理、議論および討論を奨励されます。コミュニティ技術チームは提案があがってくるとフィードバックを提供する場合があり、提案の技術面での実現可能性およびチームの作業の範囲に適合するかどうか述べます。ウィキメディア財団の別チームが業務計画に置くアイテムとの重複または競合を見つけた場合、コミュニティ技術チームはその提案にフラグを立て、投票フェーズから除外します。同様に、技術的な要望以外のもの、たとえば方針をめぐる議論、実現不可能な項目あるいはまた単に内容を理解できない提案で提案者に明確化を求めても応答がないものも同じ扱いをします。

このプロセスのほとんどは英語で行われますが、ウィキメディアのどのプロジェクトの人からもご提案を受け付けます。ボランティアの翻訳者に依頼し、提案を英語に翻訳していく見込みです。

提案の種類

提案は何語で提出しても構いませんが、英語で書くようにお勧めしています (他の編集者およびコミュニティ技術チームからフィードバックを受け取るため)。理想としては以下の各点について提案で詳細に述べてください。

• どんな問題を解決したいですか？
• 誰の役に立ちますか？（編集者、管理者、コモンズ利用者、ウィキペディアの利用者など）
• どんな解決策がありますか（考えがある場合）
• Phabricator に類似のタスクはありませんか？

第2フェーズ：提案の査読と整理

第2フェーズでは、コミュニティ技術チームと技術コラボチームが提案を検討します。編集者が投票対象を把握できるように、投票フェーズまでに整理し、明確化を求め、重複の統合など、提案を可能な限り適切な形に整え、個別の提案の利点が明確になるよう努力します。対象範囲外の技術的な要求ではない提案、あるいは作業が不可能なものはアーカイブします。

第3フェーズ：投票

投票期間に編集者はコミュニティ技術チームに取り組んでほしい提案に投票します。  Supportを付けた賛成票の署名を数えて提案の得票数を出します。「中立」もしくは「反対」も受け付けますが、あくまでも提案の不明点を質問したり問題になりそうな件を指摘して議論するためであって、得票数に対する反対票は数えません。

投票期間が終了するとページを新設し、すべての要望を転写して最終集計も示します。

要望の優先順位の決定

We've developed a method to help us approach our wish prioritization more systematically and with transparency over the years. There were a few assumptions built into our prioritization process which are helpful to name explicitly:

• Popularity of a wish should be a very important factor in our selection decision, but not the only one.
• It is best to stagger wishes so that specialists can collaborate with each other as we progress through work-- i.e. as the designer researches the wish and generates visual components for wish, the engineers focus on a wish that is purely technical.
• It is best to communicate transparently with the communities rather than hiding the details. Visibility builds trust and dialogue.

The process consists of going through any wish that scores in the top 30 for a wishlist (we cut off any wishes below that, because realistically, it takes time to investigate every wish and we know we will not be able to grant more wishes for a given year) and scores them based on the following criteria:

Prioritization Score for Community Tech Proposals

Once every wish is scored from every vantage point that impacts its feasibility and impact, we rank them. If we tackle those wishes first, we can tackle most wishes. Also, we can optimize for impact while taking maintenance and complexity into account.

This also means talking to other teams at the Foundation, and investigating if they were already working on projects related to wishes.

開発

開発のプロセスが進むにつれ、個別の要望の状態はウィキページで更新されて、コミュニティはチームの作業の進行状態を簡単に見守りフィードバックを寄せることができます。

得票が伸びなかった要望でも小規模なプロジェクト群には非常に関係が深いものもいくつか実施しますが、しかしながら軸足はグローバルな得票順に置きます。