See also T323811: [EPIC] Community configuration 2.0: Factor Community configuration out of GrowthExperiments.

Very interesting! Just wanted to mention that cross-wiki community configuration (widely; not restricted to admins) via JSON files, using a custom form-like editor (we were unaware of this Growth editor), is done in the Web2Cit project. Anxious to share experiences!

In T331865#8720980, @diegodlh wrote:

Very interesting! Just wanted to mention that cross-wiki community configuration (widely; not restricted to admins) via JSON files, using a custom form-like editor (we were unaware of this Growth editor), is done in the Web2Cit project. Anxious to share experiences!

Thanks for sharing! Looking forward to talking about how this can be made a combined effort.

Below you may find the link attached that redirects the user to the corresponding Etherpad: https://etherpad.wikimedia.org/p/wmh2023-Community_configuration

Session notes: see next comment.

Thanks, @Novem_Linguae

Version without cyrillic:

Community configuration - letting communities take control by JSON configuration

Date & time: Saturday, May 20th at 14:00 pm EEST / 11:00 am UTC

Relevant links

• Phabricator task: https://phabricator.wikimedia.org/T331865
• https://www.mediawiki.org/wiki/Growth/Community_configuration

Participants

Notes

What is community configuration?

• Community configuration is a way that allows members to change how features behave on wikis. Community configuration is consistent for two different parts. E.g. https://test.wikipedia.org/wiki/Special:EditGrowthConfig
• empowers each community to customise feature to fit their culture and needs

• (showing the short demo with enabling/disabling mentorship,
• possibility of changing the actual json file (e.g. https://test.wikipedia.org/wiki/MediaWiki:GrowthExperimentsConfig.json)

Implementation

• JSON-configuration files

For more advanced changes, editing json file directly is recommended. It only works on variables in an allowlist, to prevent accidentally setting it to the wrong value.

Community configuration has several limitations:

• discoverability, i.e. administrtors often do not know they are able to customise many of the Growth features
• no external access
• limited to Growth: community configuration is fully implemented in the Growth Experiments (from the Growth Team). currently it cannot be re-used for other features that are not from Growth

QA:

• Q: Is there a way to shut it down in the case of emergencies?
  • A: yes, there's a maintaince script that will edit the on wiki JSON
• Q: are there efforts to decouple commnity configuration from Growth features?
  • yes! (coming to that later)
• How does this differ from previous extensions that had onwiki configuration? (some are archived now)
  • This one is directly use by MediaWiki itself to load a configuration, rather than [?]

Presentation Part 2:
Where can community configuration help?

• for example, can be useful for extensions, such as (they already use json to be customized or overwrite MW messages )
• Citoid,
• PageTriage,
• Babel (can be configured with mediawiki-messages, but perhaps it's better to do with json?),
• ProofreadPage,
• Wikimedia Incubator (essentially 100s of wikis in one location, with obvious complexities, different extensions for different sub-wikis),
• [your extension here]

Other examples where it's usefull

• changing the logo
• create extra user groups
• changing the sitename
• [name anything from LocalSettings.php - some could perhaps be safely changable by admins instead of dev-only]

Comment: Perhaps we also need an intermediary level, where it doesn't require a root-dev to deploy certain kinds of changes, but only someone with +2 on a repo. [?]

Q: Database for configuration as an alternative?

• We considered a database, but decided not to use it, to enable and easy visible history of changes

Q: (more of a comment than a Q). in Web2Cit project we also used JSON-files on metawiki for configuration. anyone can edit the configuration. we didnt know of this project. another use case along similar lines.

Presentation Part 3

• Move it to core. Factor out of GrowthExperiments.

Future Plans:
Open questions

• what are the uses cases? what level of flexibility is needed?
• should communities be able to add their own fields? (gadgets, user scripts, etc)
• How to improve the discoverability of the feature?
• Should all configurations be present in one place? like Special:Preferences or one config per featureset (like Special:Edit GrowthConfig)?
• Should config changes be supervised? (WMF, stewards, etc) How can problematic changes be avoided? (e.g. checkuser, userrights, ...)
• Should we use Vue for more modern experience?
• How to ensure config is always loaded from correct storage?
• What should be exposed by the API about the configuration? Harder to query all the wikis at once if they're all stored locally. Should be a way to see the effective configuration.

Discussion

• Are we going to have a way to hve global configuration changes, to change all local configs at once?
• Martin: We have a change configuration script that allows you to override globally or locally. But it can be reverted by admins. So we'd need a way to make it easy to remove a variable from community configuration.
• Is there going to be an easy way to see via a script or API what overrides exist?
• Martin: not yet, we would need an API that can provide this information to various tooling
• Considered controlling extensions that are enabled? E.g. Having hundreds of extensions installed, and then enabled/disabled/configured via onwiki config.
• Martin: unlikely to be part of porting this to core. In the long-term, would be nice to have this available for some extensions.
• Maybe not so useful for Wikimedia, but useful to other wikis
• G: in past we needed to disable extension, community was unhappy, but if we enabled it, would bring down all the sites. That's why we need some level of control from system administrators.

Original question was in the context of Wikibase Cloud.

• Fisch [?]
• How many thoughts about performance?
• That was a concern. How it works is stored in memcache. That cache key is purged whenever an admin changes the file. Currently not a problem because it's only accessed on a page-view from the specific user.
• Lucas: [?]
• Fisch: Maybe a flag in the extension-json, that denotes it is a community-configurable variable? Then pull that into [?]
• Martin: Theoreticaly very nice, but an existing problem is that a value of individual variables differs a lot. Some are an object, some are [??]. There is some validation to prevent the system doing unexpected things, but it's not bulletproof.

Q: Lucas: is the form written in PHP?

• Martin: yes, it's a very large file, factoring this out would involve moving some form of this to core. Link to form code: https://github.com/wikimedia/mediawiki-extensions-GrowthExperiments/blob/master/includes/Specials/SpecialEditGrowthConfig.php

• Could this idea help with configuring gadgets?
  • Could help with configuration side of things, but not with where the code is loaded from. Twinkle is a good example.
  • Could it help with localized translations? Messagebundles is probably a better solution for that.

[LEAVE EMPTY LINES AT BOTTOM - Easier for collaboration]