Community configuration 2.0/ja

Summary
The Growth team developed Community configuration to help communities customize and scale Growth features. With the success of this feature (that we consider as the 1.0), it has become apparent that other WMF teams, external developers, and other users of MediaWiki could benefit from this tool, so the Growth team is exploring the possibility of moving this feature from the GrowthExperiments extension to a separate extension.

This project will include a community consultation, discussion with technical stakeholders, scalable design improvements, and engineering work to move the Community configuration feature from the GrowthExperiments extension to a separate extension. Short-term this project supports the Editing and Moderator Tools team projects (Edit check and Automoderator), and long-term this work will help evolve how WMF product and technology teams develop and deploy features.

Prioritizing work on Community configuration 2.0 acknowledges that each community has unique needs, and invested community members should be empowered to configure features to meet those needs. This approach removes the barrier for non-technical moderators to customize project settings for their communities and fosters a more inclusive and collaborative product development process, thus enabling WMF to better serve the Wikimedia movement.

Current status

 * 2021-02-11: Work started on Growth's Community configuration
 * 2021-06-29: Growth's community configuration is available on all Growth wikis
 * 2023-04-20: Hackathon session: Community configuration – letting communities take control by JSON configuration (Hackathon session slides, Google Slides)
 * 2023-08-18: Present initial plans at Wikimania (Moderator support slides)
 *  Next : Community consultation and collaboratively setting key performance indicators

Hypothesis
''' If editors with extended rights can transparently and easily configure important on-wiki functionality for all users, communities will have control over how features function on their wikis, and WMF teams will be able to ship new functionality quickly. '''

The Growth team is guided by the Annual Plan of the Wikimedia Foundation and the Product & Technology department's Objectives and Key Results. This hypothesis and associated project is one of several WMF team projects under the WikiExperiences 1.2 Key Result, which focuses on enhancing the user experience for editors with extended rights.

Use cases
There are many use cases that highlight the need for a standard way to make features community configurable. The 2.0 version of Community configuration will be more extensible and scalable, and usable outside of the GrowthExperiments extension, thereby positioning it to be a valuable asset for other WMF teams and their respective features. Community configuration has been identified as a need by several WMF team’s and their associated Annual Plan priorities:


 * 1) Editing Team: Edit Check
 * 2) * Potential use case: Communities will configure when a reference Edit Check is triggered, and the resulting message and outcome.
 * 3) Moderator Tool Team: Automoderator
 * 4) * Potential use case: Communities will configure the Automoderator to only take action on edits from certain user groups.
 * 5) Trust and Safety Team: Private Incident Reporting System
 * 6) * Potential use case: Communities will need to configure what email address or system is used to escalate different types of incident reports.
 * 7) Campaign Team: CampaignEvents extension
 * 8) * Potential use case: Communities will want to configure which namespaces are permitted for event pages and who is eligible for Organizer rights to set up event registration.
 * 9) Mobile App team: Anti-vandalism tools for the Android App.
 * 10) * Potential use case: Communities can create warning templates that can be displayed across official WMF mobile apps and third party patrolling apps.
 * 11) Web team: Accessibility for reading
 * 12) * 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.

We want to

 * 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.

We don't want to

 * Create a tool that creates bias or only benefits a certain user group.
 * Create a tool that works only with certain features.
 * Create a tool that is difficult to find or understand.

主な成果
当プロジェクトは拡張権限を預かる編集者と協働して目標と主要な成果を確立していきます. 現状で可能性のある主な成果は次を含みます.
 * 2024年3月末リリースをめどに、複数の Growth 機能の開発においてコミュニティ設定2.0を組み込み、設定変更可能なものに仕上げようとしています.
 * ウィキメディア財団製品技術部門の他の1チーム以上が当コミュニティ設定2.0を採用したプロジェクトに取り組み、2024年6月末をめどにツールの発表もしくは成果を共有すると見込まれます.
 * By the end of the fiscal year, Community configuration 2.0 has been used to customize at least 20 wikis. In other words, editors with extended rights are aware and utilize Community configuration.
 * By the end of the fiscal year, initial guidelines for the types of functionality that should and should not be in Community configuration, and types of user rights, will be agreed in consultation and collaboration with volunteers and interested product teams.



コミュニティの協議
As part of this project, there are three main groups of stakeholders we will consult with:


 * 1) Wiki communities: Including Wikipedia admins and users with extended rights that have used Growth's Community configuration previously or might utilize Community configuration 2.0 in the future. We will also consult with developers of user scripts and gadgets.
 * 2) Technical community: A wider discussion with the technical community as a whole (wikitech-l, MediaWiki core developers.
 * 3) WMF teams: Wikimedia Foundation Product and Technology teams interested in utilizing Community configuration 2.0 in upcoming projects.

未解決の質問集

 * How do you feel about the prospect of more WMF teams developing features that can be enabled, disabled, and configured by your local wiki Administrators? Do you have any reservations or concerns about this project?
 * これらのツールを管理者にもれなく伝えて理解してもらうには、どんな方法がありますか？
 * 管理者はコミュニティ設定の変更に自信を持てるでしょうか？ 手順に曖昧もしくは不明瞭な箇所はあるかないか？
 * コミュニティ設定2.0は誰に対しても可視化する必要があるものの、その修正は経験を積み選ばれたウィキメディアンの手に委ねるべきでしょうか？ 設定のオプションは全て管理者もしくはインタフェース管理者の権限がないと編集できないようにするべきですか？ このツールの特定のオプションに限り、利用者のアクセスをレベル分けすると適切でしょうか？
 * Do you have any thoughts or suggestions about how we can best define and measure the success of this project?
 * コミュニティ設定2.0の：ユーザスクリプトやガジェット、外部アプリの対応をするのかどうか（Android／iOS 版のウィキペディア・アプリを例に想定）.
 * 設定ファイル config の変更点を全て／ほとんどのウィキメディアのプロジェクト群に適用する場合、どう取り扱うか？

Wiki communities: discussion summary
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.

Research
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 2.0 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.