Page MenuHomePhabricator

[Session] Community configuration: What happened in a year?
Closed, ResolvedPublic

Description

  • Title of session: Community configuration: What happened in a year?
  • Session description: In 2023, the Growth team started working on the Community configuration project, which aims to make it possible for MediaWiki on-wiki administrators to change wiki settings directly, without having to involve a system administrator. The project's development started last year with a Hackathon session (T331865). During that session, many open questions were discussed (and new ones raised), generating useful thoughts that aided the process of making CommunityConfiguration a reality. Many other things changed as well: the project is now better defined, and most importantly, already deployed to the Beta Cluster. Within this session, the Growth team would like to summarize the state of Community configuration, where we are at, what is expected to be completed within the next months and what are the next steps.
  • Username for contact: @Urbanecm_WMF (primary), @Michael (secondary)
  • Session duration (25 or 50 min): 25 min
  • Session type (presentation, workshop, discussion, etc.): presentation
  • Language of session (English, Arabic, etc.): English
  • Prerequisites (some Python, etc.): none
  • Any other details to share?: There is a workshop-type session that follows this one, T362879: [Session] Make your extension community configurable.
  • Interested? Add your username below:

notes from session

Community configuration: What happened in a year?

Date and time: 3 May, 15:00 - 15:30

Relevant links

Presenter

[[User:Martin Urbanec (WMF)|Martin Urbanec (WMF)]], [[User:MGrosse-WMF|MGrosse-WMF]]

Participants

Notes

What happened with Community Configuration over the past year?
Motivation
CC is aimed at helping with direct decision making from the community, helping improve sense of speed and transparency
Current proof of concept is in GrowthExperiments extension - but useful outside of this context too!
Therefore, Community Configuration 2.0 (CC2.0) is a generic extension that other extensions can hook into.
CC is now an extension that works! Security review passed, improvements made after performance review. Ready for deployment
Each configurable config is listed on a central Dashboard
Live in es.beta.wiki already - https://es.wikipedia.beta.wmflabs.org/wiki/Especial:CommunityConfiguration
Easy to make changes without needing a code deployment
Most open questions from last year have now been answered
“should all configuration be present in one place or one config per feature set?” – decided on dashboard approach: each feature set has its own editor and is independent of other features
"Should communities be able to add their own fields to CC (e.g. gadgets,user scripts)?"
Would like to see this eventually, but out of scope for now. CC can only be used from MediaWiki itself (except core, since it's an extension). Except that they can read a config (e.g. the apps can read the page).
"How to ensure config is always loaded from the correct place?"
Single configuration service which knows which CC configs are good to use. To use this you just need to replace the config with CC.
Still some open questions
"How to make CC discoverable?"
You have to know that Special:CommunityConfiguration exists. Once you know that, you can find the configurable features, but the initial discovery is not a solved problem.
Architecture
Four modules, more or less independent of each other. Each could be replaced/changed without affecting the rest.
Validator
Makes sure configuration meets requirements set by the software
Providing information about the recognised config options that exist
JSON schema for validation purposes. Closely follows json schema language itself.
Editor form
Form is automatically generated, has known form types based on the schema.
Default logic can be replaced with something else.
Store
Based on on-wiki JSON pages in wiki pages in the MediaWiki namespace.
In the future it could be possible to have some other store type.
Configuration provider
Groups store and validator together.
Defined in extension.json
'My extension will use wiki page store, will put the data on this page, and validate with this schema'
Also defines how configuration is accessed. e.g. type = mediawiki config.
Makes it possible to use CC for both data that needs to be changed by community, and for mw config.
Next steps
Production deployment of CC2.0 for GrowthExperiments config.
Making available to community in production
If other teams want to use it we'll try to be consistent.
Also aiming to work CC into other extensions via WMF teams

CC workshop tomorrow to help with converting something to use CC!

Questions

Q:Do you have a list of data types that CC supports?
A: Currently support what JSON schema supports, including arrays and objects. Also support a field that's a string that's interepreted as a MediaWiki title
Q:Rolling out to other extensions, do you have some in mind?
A:Yes - Automoderator (Moderator Tools) fully plans to use it - already uses onwiki config in a basic json page.
Q:Any future plans after production deployment and first uses?
A: No plans to migrate other tools to CC, but will happily support other tools using it.
Q:Will it be possible for an extension to have it as an optional dependency?
A:Yes. Would need to create a wrapper service, to either return CC or whatever the other config is. CC could then be a soft dependency. Probably best for CC to be a hard dependency. Best to commit to switching to it fully.
Q:Maybe it should move into Core?
A: We don't really want CC to be in core, could be a circular issue defining its own behaviour. But there are core features that would be nice to customise. Come to Birgit's session at 9:30 tomorrow if you have thoughts about which extensions are in core etc.

Photos

Social

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
debt triaged this task as Medium priority.Apr 22 2024, 2:41 PM

Community configuration: What happened in a year?

Date and time: 3 May, 15:00 - 15:30

Relevant links

Presenter

[[User:Martin Urbanec (WMF)|Martin Urbanec (WMF)]], [[User:MGrosse-WMF|MGrosse-WMF]]

Notes

What happened with Community Configuration over the past year?
Motivation
CC is aimed at helping with direct decision making from the community, helping improve sense of speed and transparency
Current proof of concept is in GrowthExperiments extension - but useful outside of this context too!
Therefore, Community Configuration 2.0 (CC2.0) is a generic extension that other extensions can hook into.
CC is now an extension that works! Security review passed, improvements made after performance review. Ready for deployment
Each configurable config is listed on a central Dashboard
Live in es.beta.wiki already - https://es.wikipedia.beta.wmflabs.org/wiki/Especial:CommunityConfiguration
Easy to make changes without needing a code deployment
Most open questions from last year have now been answered
“should all configuration be present in one place or one config per feature set?” – decided on dashboard approach: each feature set has its own editor and is independent of other features
"Should communities be able to add their own fields to CC (e.g. gadgets,user scripts)?"
Would like to see this eventually, but out of scope for now. CC can only be used from MediaWiki itself (except core, since it's an extension). Except that they can read a config (e.g. the apps can read the page).
"How to ensure config is always loaded from the correct place?"
Single configuration service which knows which CC configs are good to use. To use this you just need to replace the config with CC.
Still some open questions
"How to make CC discoverable?"
You have to know that Special:CommunityConfiguration exists. Once you know that, you can find the configurable features, but the initial discovery is not a solved problem.
Architecture
Four modules, more or less independent of each other. Each could be replaced/changed without affecting the rest.
Validator
Makes sure configuration meets requirements set by the software
Providing information about the recognised config options that exist
JSON schema for validation purposes. Closely follows json schema language itself.
Editor form
Form is automatically generated, has known form types based on the schema.
Default logic can be replaced with something else.
Store
Based on on-wiki JSON pages in wiki pages in the MediaWiki namespace.
In the future it could be possible to have some other store type.
Configuration provider
Groups store and validator together.
Defined in extension.json
'My extension will use wiki page store, will put the data on this page, and validate with this schema'
Also defines how configuration is accessed. e.g. type = mediawiki config.
Makes it possible to use CC for both data that needs to be changed by community, and for mw config.
Next steps
Production deployment of CC2.0 for GrowthExperiments config.
Making available to community in production
If other teams want to use it we'll try to be consistent.
Also aiming to work CC into other extensions via WMF teams

CC workshop tomorrow to help with converting something to use CC!

Questions

Do you have a list of data types that CC supports?
Currently support what JSON schema supports, including arrays and objects.
Also support a field that's a string that's interepreted as a MediaWiki title
Rolling out to other extensions, do you have some in mind?
Yes - Automoderator (Moderator Tools) fully plans to use it - already uses onwiki config in a basic json page.
Any future plans after production deployment and first uses?
No plans to migrate other tools to CC, but will happily support other tools using it.
Will it be possible for an extension to have it as an optional dependency?
Yes. Would need to create a wrapper service, to either return CC or whatever the other config is.
CC could then be a soft dependency.
Probably best for CC to be a hard dependency. Best to commit to switching to it fully.
Maybe it should move into Core?
We don't really want CC to be in core, could be a circular issue defining its own behaviour.
But there are core features that would be nice to customise.
Come to Birgit's session at 9:30 tomorrow if you have thoughts about which extensions are in core etc.

Link to Etherpad: https://etherpad.wikimedia.org/p/wmh2024-Community_configuration