コミュニティ設定
|
コミュニティ設定
 コミュニティ設定の概念を一般化して、どの MediaWiki 開発者にも使えるようにする。
|
要約
この CommunityConfiguration 拡張機能の開発は、コミュニティ単位でそれぞれ固有のニーズに対応できるよう、ウィキの機能設定が可能になるよう意図しました。 コミュニティ設定を使うと、管理者は担当するコミュニティのために設定をカスタム化し、包摂性を高めたり共同作業がしやすい製品開発のプロセスを整え、その結果、ウィキメディア運動においてウィキメディア財団の対応より向上します。
かつて担当だったGrowth チームは当初、コミュニティ設定を自分たちの拡張機能 GrowthExperiments 用に開発を始め、各種 Growth 機能をコミュニティ単位でカスタム化し拡充できるように目指しました。こうしてコミュニティ設定は成果を上げるとウィキメディア財団の他の担当部署も、外部開発者もMediaWiki の他の利用者もこのツールの恩恵を受けられる点から、Growth チームはこの機能をGrowthExperiments 拡張機能から切り離して、独自の拡張機能へ移動させました。
現状
- - Growthチーム担当のコミュニティ設定作業に着手
- - Growth ウィキすべてにコミュニティ設定機能を導入済み
- - ハッカソンの一コマ：コミュニティ設定機能 – コミュニティがJSON設定を使って制御可能に (ハッカソンのセッションで使ったスライド集、形式は Google スライド)
- - ウィキマニアで発表した現状の初期案 (Moderator support slides)
- - Technical RFC announced on wikitech-l
- - 「コミュニティ設定2.0」を改名、簡略に「コミュニティ設定」と呼びます。製品化以前の旧来のGrowth コミュニティ設定は別のものと定義しました。
- - 拡張機能のコミュニティ設定はベータ版ウィキペディアとテスト版ウィキペディアに展開。
- - 拡張機能のコミュニティ設定はパイロット版ウィキペディア類に展開（ウィキペディアのスペイン語版とアラビア語版）。
- - 全ウィキペディアに導入（T360571）
- 次の段階：より多くの設定項目を追加。
仮説
拡張権限を預かる編集者がもしオンウィキのすべての利用者に関連する重要な機能を仮に透明性を保ちながら容易に設定できるとしたら、コミュニティはそれぞれのウィキで機能群がどのように機能するか自律的に制御でき、WMFの各チームは新しい機能を迅速に出荷できます。
Growthチームはウィキメディア財団の年次計画ならびに製品・技術部門の目的と主な成果（OKRs）に従って業務を行います。これらの仮説と関連のプロジェクトはWikiExperiences 1.2 主な成果（KR）に準拠するWMF財団の部署単位のプロジェクトの一つで、拡張権限を預かる編集者の利用者体験の向上を目指しています。
担当の Growth チームに加えてウィキメディア財団の他の担当チーム5件は、これに関連するプロジェクトに注力してWikiExperiences 1.2 の主な成果に反映させました。
使用事例
使用事例には、機能をコミュニティ単位で構成可能にするなら方法の標準化が必要だと強調したものがたくさんあります。コミュニティ設定はGrowthExperiments 拡張機能から取り出したとしても、さらに拡張して運用規模が広がり使いたくなるから、他の WMF チームやそれぞれの機能にとっては貴重な資産と位置付けることができます。財団の複数の担当チームは以下のように、それぞれの年次計画の優先事項としてコミュニティ設定の必要性を認めました。
- 編集機能チーム：編集チェック (T327563)
- 予測される使用事例：コミュニティでは編集チェックが発動する状況と、表示するメッセージ、結果としてどうなるか設定
- 仲裁ツール・チーム：自動仲裁のオートモデレータ（Automoderator） (T365046)
- 予測される使用事例： コミュニティは自動仲裁用の Automoderator を設定、特定の利用者グループが編集した場合に限定して発動させる。
- 信頼安全製品チーム： 事案通報システム（Incident Reporting System）
- Potential use case: Communities will configure pathways for different types of incident reports, as well as configure rules on who can use the system in which situations.
- Campaign Team: CampaignEvents extension (T370724)
- Potential use case: Communities will configure if certain CampaignEvents features are available on their wikis.
- Mobile App team: Anti-vandalism tools for the Android App.
- Potential use case: Communities can create warning templates that can be displayed across official WMF mobile apps and third party patrolling apps.
- Web team: Accessibility for reading
- Potential use case: Communities may need to configure default font sizes, as certain language scripts need to be larger to be readable and meet accessibility needs.
Many other possible use cases have been brainstormed by community members and are listed in the associated epic: T323811.
目標
達成したいこと
- Create a tool that is easily understood by any experienced editor.
- Empower communities to customize wiki features to best suit the local needs of their wiki.
- Create a tool that helps increase the speed in which WMF Product and Technology teams can scale features to all wikis.
- Create a tool that helps volunteer developers, gadget creators, and any software developer interested in creating community configurable tools for MediaWiki.
避けたいこと
- バイアス（偏重）や特定の利用者グループに限定して利益をもたらすツールの作成。
- 特定の機能限定で動作するツールの作成。
- 探すのも理解するのも難しいツールの作成。
主な成果
当プロジェクトは拡張権限を預かる編集者と協働して目標と主要な成果を確立していきます。現状で可能性のある主な成果は次を含みます。
- 2024年3月末リリースをめどに、複数の Growth 機能の開発においてコミュニティ設定を組み込み、設定変更可能なものに仕上げようとしています。
- ウィキメディア財団製品技術部門の他の1チーム以上が当コミュニティ設定を採用したプロジェクトに取り組み、2024年6月末をめどにツールの発表もしくは成果を共有すると見込まれます。
- 2024予算年度末までにコミュニティ設定は20件以上のウィキで採用されカスタム化されました。言い換えるなら、拡張権限を預かる編集者はコミュニティ設定を認知し利用したことになります。
- 2024予算年度末までにコミュニティ設定機能に関するガイドライン初期案について、ボランティア利用者ならびに関心を寄せる製品チームからの聴き取りと共同作業で盛り込む・あるいは除外するべき機能の種別、利用者権限の種別ををまとめる必要があります。
Technical Considerations
コミュニティ設定1.0から得た技術面の学び
Community configuration 1.0 made the following things challenging:
- Changes: Once a configuration value has been first configured on-wiki, it is challenging to change its format (one has to edit the configuration files and update their format). CC 1.0 is problematic at backwards and forwards compatibility.
- External access: Configuration values cannot be easily accessed from external clients (such as the Android app), ie. without loading the underlying JSON page, the structure of which can be changed without notice by the Growth team.
- Extensibility: Adding new fields to the configuration form is not terribly difficult, but it is often forgotten about. The backing JSON files give admins access to more than what Special:EditGrowthConfig offers. Unfortunately, most “hidden capabilities” are only known by Growth engineers.
- Deletability: Configuration stored as on-wiki JSON files has its disadvantages. The biggest disadvantage Growth team ran into is that they can be deleted (example: T344013). Once that happens, the Growth features revert to extension.json-provided defaults, which disrupts the experience to newcomers (although nothing broke from a technical perspective, the user experience is nearly-unusable).
- Suddenness: It is worth knowing about certain configuration changes when they happen, so they can be properly reacted to. For example, if a wiki decides to turn off Add link, the Growth team would want to learn why and if possible, resolve issue(s) identified by the community. This is not (easily) possible with CC1.0.
高次の技術要件
コミュニティ設定に求められるもの:
- Auditable: Any change made to the configuration should be auditable, including the reasons for “who made the change”, “why the change was made” and “what the change consisted of”. The experience should be comparable to the history of MediaWiki pages, as that is what the users are used to.
- Extensible: Even though we made scoping decisions (eg. to not include gadgets in the MVP), those decisions should not affect ability to extend Community Configuration in the future without significant efforts.
- Externally available: Users external to MediaWiki should be able to access the current setting values configured via Community Configuration. This is needed to ensure Community Configuration values can be used from places outside of MediaWiki (such as the Wikipedia Apps for mobile devices, Toolforge tools and similar).
コミュニティの協議
As part of this project, there are three main groups of stakeholders we will consult with:
- ウィキ・コミュニティ：ウィキペディアの拡張権限を預かる利用者と管理者を含め、Growthチームのコミュニティ設計を試した経験がある、もしくは近々、そのバージョンを試してみたい人たち。またユーザスクリプトやガジェットの開発者の皆さんにも相談します。
- 技術コミュニティ: 技術コミュニティ全体を対象として、より広汎な協議をします。(wikitech-l、MediaWiki コアの技術者)。
- WMFの各チーム：ウィキメディア財団製品・技術チームは今後の複数のプロジェクトに関してコミュニティ設計に関心を寄せています。
未解決の質問集
- 今後、複数のWMFチームがさまざまな機能を開発し、皆さんのローカルウィキの管理者が採否や設定を任されるとしたら、どう感じますか？ ちょっと待ってほしいと抵抗感を感じたり、当プロジェクトに何か懸念はありませんか？
- これらのツールを管理者にもれなく伝えて理解してもらうには、どんな方法がありますか？
- 管理者はコミュニティ設定の変更に自信を持てるでしょうか？ 手順に曖昧もしくは不明瞭な箇所はあるかないか？
- コミュニティ設定は誰に対しても可視化する必要があるものの、その修正は経験を積み選ばれたウィキメディアンの手に委ねるべきでしょうか？ 設定のオプションは全て管理者もしくはインタフェース管理者の権限がないと編集できないようにするべきですか？ このツールの特定のオプションに限り、利用者のアクセスをレベル分けすると適切でしょうか？
- 当プロジェクトの最善の目標設定と成果計測に関して、何かお考えやご指摘はありませんか？
- コミュニティ設定の範囲：ユーザスクリプトやガジェット、外部アプリの対応をするのかどうか（Android／iOS 版のウィキペディア・アプリを例に想定）。
- 設定ファイル config の変更点を全て／ほとんどのウィキメディアのプロジェクト群に適用する場合、どう取り扱うか？
Wiki communities
The Growth team's Community Relations Specialist contacted admins who had recently edited Growth's Community Configuration (T336608). The main ideas admins communicated are as follows:
- The usual roles and processes to monitor and edit the configuration are preferred:
- All configuration pages should be readable by anyone.
- Admins (or Interface Admins) should be able to edit because they have enough knowledge.
- Admins can apply requests made after a community discussion.
- The need for a history of requests and tracking of changes is necessary.
- This configuration page may impact a lot of users, and should be handled with care. Several ways to prevent issues were suggested:
- The creation of a new role, for trusted admins who understand Community Configuration.
- The creation of a reviewing process to validate a change made by one admin.
- A clear and centralized history page is needed to spot any changes made on the different configurations.
Wikimania presentation
The Growth Team's Product Manager presented at Wikimania Singapore to share initial details about the Community Configuration project along with other projects WMF teams are completing to support moderators. We answered the following questions from session attendees:
- Is the Special page available for non-admins in a read-only mode?
- Yes, the special page is currently available for anyone to view. Only admins can actually edit the configuration. Example: Special:EditGrowthConfig.
- Will Community Configuration be available on other wikis outside of Wikipedia?
- Currently the 1.0 version of Community Configuration is part of the GrowthExperiments extension and therefore only available on wikis that have that extension enabled. We hope to build the version in a way that is more extensible and flexible so that it can be used on any wiki that installs the Community Configuration extension.
- 当チームの目標は、この拡張機能のスケールを拡充してウィキメディアのすべてのプロジェクトに導入すること。コミュニティ設定がウィキメディアの全プロジェクトで使えるようになるとそれぞれの場所に統合しやすくなり、するとこの拡張機能さえあればウィキメディアの文脈でいつでも頼りにできます。
- コミュニティ設定について特異な利用事例が既知であるとして、その情報をどこに共有すると当チームが事例として着目するでしょうか？
- Although we can't make promises that we can support everything in the initial release, we are compiling a list of use cases in the Community Configuration Epic. Any community member with ideas is welcome to add comments to that task with the use case (of course we welcome feedback and comments on the talk page here too).
- Will there be cases in which there are additional restrictions or warnings as to what a Admin can change?
- This project will include creating guidelines on the use of this feature. We will create better onboarding for Admins, as well as developer guidelines for engineers supporting Community Configuration of non-Growth features.
- There will also be error checking and warnings in place to ensure Community Configuration is as stable as possible. For example: if the form expects a positive integer in a certain field, the form will present an error if a negative integer or non-integer string is added.
- We have considered Community Configuration eventually supporting a process in which more than one admin needs to approve a change if the change could be controversial or high-impact. This won't be part of the MVP, but something we may consider in the future.
- Will Community Configuration work for external apps, like the Wikipedia Android and iOS apps?
- Community Configuration will be readable by external apps, but the actual Community Configuration form will not be adjustable by admins from within the apps.
- Will interface admins still be able to make changes to JSON configuration files if they are also Community Configurable, or will these changes now be restricted to updates via Community Configuration?
- Community Configuration will not restrict interface admins from making changes to JSON configuration files. However, in the future, there may be some configurations that admins should not be able to edit. If that happens, we would need to restrict manual editing of any raw JSON file associated with that configuration.
WMF Teams
We have completed an initial listening tour with nine WMF Product teams. Some key takeaways are:
- All teams have either a short-term or long-term need for Community Configuration, the short term needs have been documented as Community Configuration use cases.
- Several teams noted the importance of data transparency in making configuration decisions.
- Several teams mentioned the need for metrics and the community ability to evaluate Community Configuration decisions.
- Teams mentioned several social concerns, including: accountability and transparency, balancing legal requirements with community autonomy, discoverability, permissions and user roles, and the need to avoiding increasing patroller burden.
- Teams mentioned a few technical concerns, especially the need for Community Configuration to be nuanced and flexible.
Technical consultation
We conducted a wider discussion with technical stakeholders via starting a wikitech-l thread explaining the project and asking for feedback in the related Phab task (T349757) and the Community Configuration Product Requirements Document. After discussing feedback and responding to concerns by creating follow up tasks (like T351227), we wrapped up the technical RFC.
Research
Comparative review
The Growth team's designer completed a short comparative review of Admin tools in use on other platforms (T338386). The full report is available here: Comparative review: Configuration / Admin tools. The following is a summary of the relevant insights that relate to the Growth team's Community Configuration project:
- Most tools make use of a ‘Dashboard’ as the first thing you see when you enter the panel – you can access things like recent activity, quick links, actionable insights.
- In terms of organization/layout, most tools make use of modules while having a sidebar on the left, with menu items on it being expandable in some of the tools.
- Some platforms let users/communities customize modules and how they’re presented - for example, modules being draggable to different parts of the screen, or being able to hide modules that you or your community don’t use.
- Settings UI: for most of these, tools use components like toggle switches (turn on/off), text inputs, and dropdown menus.
- Typology of settings:
- Display settings: being able to change the color/layout/etc. of a feature
- Feature access: being able to activate/deactivate (turn on/off) certain features
- Thresholds/Limits: e.g., a certain activity can be done no more than X times per day.
- User access/permissions: only certain user groups having access to a feature
- Audience-specific or other conditional customisation: e.g. links to resources being different from community to community.
Editor interviews
The Growth team partnered with WMF Design Research to complete semi-structured interviews with admins and experienced Wikimedians from English Wikipedia, Spanish Wikipedia, and Swahili Wikipedia. The following are a few key take-aways:
- Participants from smaller wikis are enthusiastic about how “democratizing” Community Configuration is.
- Participants from larger wikis trust that the restrictions/permissions that currently govern configuration will continue to do so under Community Configuration.
- Participants found the Community Configuration designs to be an improvement over the existing configuration processes/systems they are familiar with.
- Participant concerns about empowering too many people to make configuration changes were alleviated once participants interacted with the Community Configuration prototypes.
- The explanatory messages, logo image, and page title used in the prototype should be reconsidered in light of the fact that Community Configuration will be used by many non-technical, non-native speakers of English.
Design
Initial designs
We will utilize what we've learned from the existing Special:EditGrowthConfig page to make the new Community Configuration page more user-friendly, intuitive, and scalable. We are currently exploring two main design concepts for the Community Configuration page: an accordion style layout or a dashboard style layout. We will gather community feedback to determine which design we pursue, and how we can further improve the Community Configuration design and UX.
-
Concept A: Accordion style -
Concept B: Dashboard style
Second iteration designs
As we progressed with designs and community discussions, it became clear that there should be a central page to access all Community Configuration options. This central page will act as a Community Configuration dashboard and allow easily access and navigation to each individual Community Configuration form. The individual feature form is where configuration changes will be saved. The form will also allow for easy access to the configuration edit history, help pages, and related metrics.
-
Community Configuration dashboard design -
Community Configuration form design for Mentorship features
Measurement and instrumentation
Community Configuration edits are publicly tracked on the associated history page, so instrumentation needs are fairly minimal. However we would like to be able to answer the following questions:
- How often is the Community Configuration dashboard (Special:CommunityConfiguration) visited?
- How often is an individual Community Configuration edit form visited?
- How often is a Community Configuration edit completed?
Measurement and instrumentation details are available via: T366224.