Community Configuration/cs

Projekty Wikimedia Foundation Community Configuration Generalize the concept of Community Configuration to be usable by any MediaWiki developer. Skupina: Growth Začal: 2023-07-01 Vedoucí: Tech Lead: Martin Urbanec Product Manager: Kirsten Stoller Aktualizace: Most updates posted here .

The CommunityConfiguration extension was developed to help communities customize wiki features to meet their unique needs. Community Configuration allows admins to customize settings for their communities and fosters a more inclusive and collaborative product development process, thus enabling WMF to better serve the Wikimedia movement.

• 11. února 2021 - Work started on Growth's Community Configuration
• 29. června 2021 - Growth's Community Configuration is available on all Growth wikis
• 20. dubna 2023 - Hackathon session: Community Configuration – letting communities take control by JSON configuration (Hackathon session slides, Google Slides)
• 18. srpna 2023 - Present initial plans at Wikimania (Moderator support slides)
• 25. října 2023 - Technical RFC announced on wikitech-l
• 5. března 2024 - "Community Configuration 2.0" is renamed "Community Configuration", for simplicity. Growth Community Configuration is considered as a separated, pre-project.
• 6. června 2024 - The Community Configuration extension was released to all Beta Wikipedias and Test Wikipedia.
• 17. června 2024 - The Community Configuration extension was released to Growth Pilot wikis (Spanish and Arabic Wikipedia).
• 17. července 2024 - Release to all Wikipedias (T360571)
• Next: more configurations are made available.

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.

1. Editing Team: Edit Check (T327563)
   • Potential use case: Communities will configure when a reference Edit Check is triggered, and the resulting message and outcome.
2. Moderator Tool Team: Automoderator (T365046)
   • Potential use case: Communities will configure the Automoderator to only take action on edits from certain user groups.
3. Trust and Safety Product Team: 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.
4. Campaign Team: CampaignEvents extension (T370724)
   • Potential use case: Communities will configure if certain CampaignEvents features are available on their wikis.
5. 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.
6. 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.

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

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

• By the end of March 2024, configurable Growth features will utilize Community Configuration.
• By the end of June 2024, at least one other WMF team in Product and Technology has either launched or is in the active development stage for a project that is using Community Configuration.
• By the end of the fiscal year 2024, Community Configuration 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 2024, 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.

• 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).

1. Wiki communities: Including Wikipedia admins and users with extended rights that have used Growth's Community Configuration previously or might utilize Community Configuration 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 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?
• What can we do to ensure that all Administrators are well-informed about these tools?
• Are Administrators confident in making alterations to Community Configuration? Which parts of the procedure are unclear or ambiguous?
• While Community Configuration should be visible to all, it should only be modifiable by a select group of experienced Wikimedians? Should all configuration options be exclusively editable by Administrators and interface administrators? Should we consider different user access levels for certain Community Configuration options?
• Do you have any thoughts or suggestions about how we can best define and measure the success of this project?
• Scope of Community Configuration: will it support user scripts, gadgets, external apps (like the Android/iOS Wikipedia app).
• How should we handle config changes that need to apply on all/most Wikimedia projects?

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

• 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.
  • Our goal is to scale the extension up to all Wikimedia projects. Having Community Configuration enabled across all Wikimedia projects would make it easy to integrate with, as you could rely on the extension always being available in a Wikimedia context.
• If we know of specific use cases for Community Configuration, where can we share this information so that the Growth team considers the use case?
  • 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.

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

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.

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.

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.

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

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

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.

• Translate Community Configuration