Page MenuHomePhabricator

Community configuration: Define architecture of the system
Closed, ResolvedPublic


The Growth team introduced Community configuration to allow administrators to customize how the Growth features should work like at individual wikis. Community configuration makes deployment easier for Growth, as we don't have to deliver a "one size fits all" approach. It is also easier for communities to make use of Special:EditGrowthConfig, than having to communicate with the Growth team to request a change in the MediaWiki configuration.

Growth's Community configuration is currently a monolithic system, consisting of the configuration store (reading/writing to/from MediaWiki pages with the configuration) and the editing form. While this system works for Growth, it is not suitable for a wider expansion of Community configuration, as that system has numbers of possible use cases that need to be accommodated. Modular setup would be more flexible and make Community configuration 2.0 useful for other usecases as well.

Having Community configuration 2.0 modular also makes it possible for the system to be used outside of MediaWiki itself. For example, to allow the Android/iOS apps to reuse certain community configured variables or for easier integration of community-maintained gadgets. Community configuration 2.0 can consist of the following main components (details are TBD):

Top-level notes

Community configuration 2.0 stores configuration in on-wiki JSON pages. Each JSON page configures a given featureset, which might be an extension, a gadget or a feature subset. Each JSON page is validated independently: one generic key/value configuration page seems like a good fit for many usecases; other pages can be introduced as-needed for usecases with special validation needs.

For example, Growth-Team has MediaWiki:GrowthExperimentsConfig.json as a generic config page, with MediaWiki:NewcomerTasks.json to configure attributes specific to newcomer tasks and MediaWiki:GrowthMentors.json to configure the list of mentors (who the mentors are).

Validation: Schema provider

Schema provider is responsible for ensuring the data stored in Community configuration is valid. It seems wise to make use of existing schema technologies, such as JSON Schema, especially since we already require justinrainbow/json-schema as a dependency in Composer. Currently, validation is very loose and only ensures the right datatype is used, which is good enough to avoid taking the site down, but not a proper long-term schema solution. Schema provider consists of the following parts:

  • Storage: Responsible for fetching the right schema for each configuration page. Schema is stored in source version control, assuming core/extension/skin is the configured component. For community configured gadgets, the schema should live on-wiki (as it makes sense for it to be in the same environment as the gadget's source code). It is TBD whether the schema should be in a separate page, or in a MCR slot for the configuration page.
  • Validation: Ensures passed PHP object is valid according to a given Title's schema.
  • Migration layer: Transforms a PHP object from an older-schema version to a newer schema version. This is important to preserve compatibility across schemas, when a new feature is added or the need for additional configuration options is otherwise predicted. Each schema version (except the first one) needs to have a migration class/function, which transforms the configuration object from the directly previous schema to the new one.

Backend: Configuration store

Configuration store is the heart of Community configuration 2.0. The store is composed of the following subcomponent, with responsibilities as-follows:

  • Storage: Responsible for determining where the current configuration is stored (in which on-wiki JSON page) and for loading/writing from/to the page. Configuration pages can be either stored in a dedicated namespace for configuration or the MediaWiki namespace (current state of affairs).
  • Permissions: Responsible for determining whether an user is authorized to make a write change to the config page. Permissions checks are required on the page-level
  • Validation: Middleware fetching the right schema from the Schema provider discussed above and ensuring the written/loaded configuration meets the defined criteria.
  • Access layer: API exposing the current configuration (+write endpoint) to both external callers (via the Action/REST MediaWiki API) and internal callers (via MediaWiki classes). Configuration needs to be exposed in a stable way, in order to keep caller breakages to the minimum.

Frontend: Editing form

To ensure admins who are not tech-savvy can use the Community configuration, an editing form would exist (similar to Special:EditGrowthConfig, or a site-wide version of Special:Preferences). Usage of the configuration form would be optional -- Community configuration users that want to incorporate community configuration into their own interface would be able to do so.

Ideally, the configuration would be automatically generated based on the schema, see T332849: [Spike] Investigate form generation options for community configuration.

Related Objects

Event Timeline

I think this is done.