Can we manually create an SUL account and then use that username, so that we can leverage global user pages?

From what I've researched about global accounts we can create them manually, but "the global pages will only be inherited on wikis where you have a local account ". This means we would have to create a global account on Meta and then log in to the stewarded wikis with said account. For (maybe?) local testing, we would have to install the GlobalUserPage extension and configure it. We would also have to create multiple wikis to test.

In T372413#10105189, @Scardenasmolinar wrote:

Can we manually create an SUL account and then use that username, so that we can leverage global user pages?

From what I've researched about global accounts we can create them manually, but "the global pages will only be inherited on wikis where you have a local account ". This means we would have to create a global account on Meta and then log in to the stewarded wikis with said account.

I've seen a user script which enables rapid logging-in to enable an account on a bunch of wikis, so I think this can be done fairly quickly!

Also, you could script callling Special:Createlocalaccount for an account to import it to a local project

Is it technically feasible for us to have a global (presumably on Meta) configuration page for Automoderator?
Could we have Automoderator use local configuration if it exists, and global configuration if not?

Based on my research, I don't think we can have a global configuration on Meta. I haven't seen any example of something like that implemented anywhere. I think we will have to rely on local configuration or on the configuration in extension.json.

Can we easily deploy Automoderator to a large number of wikis at once?

Yes, we can deploy to a large number of wikis, as long as they all fulfill the deployment criteria (having an AutoModerator user, False Positive Reporting page, etc.)

How would we handle a community migrating from global control of Automoderator to local control?

Since global control will only be possible in extension.json or on configuration files, we can easily override it by creating local configuration using Community Config.

In T372413#10120056, @Scardenasmolinar wrote:

Based on my research, I don't think we can have a global configuration on Meta. I haven't seen any example of something like that implemented anywhere.

SpamBlacklist and TitleBlacklist have global and local lists.

Just reviewing this and I had a few questions/comments, bear with me if some of these questions are silly.

Can we easily deploy Automoderator to a large number of wikis at once?

The only other thing I would add is that we also need to ensure all the extensions and configuration on the wikis play nice with Automoderator.
eg. Flow Extension

Is it technically feasible for us to have a global (presumably on Meta) configuration page for Automoderator?
Could we have Automoderator use local configuration if it exists, and global configuration if not?

The extension.json acts as a global configuration that users can customize locally via community config.
Are we wondering how stewards can update community configuration? That may be a question for the growth team-do we want to allow stewards to override the config?

Can we interface with the global opt-out list, which I understand would effectively be the list of global vs local automoderator wikis?

I'm curious what the use case would be for this? Do we have any wikis that would not want to use the standard config in the extension.json or community config?

In T372413#10122340, @Kgraessle wrote:

Just reviewing this and I had a few questions/comments, bear with me if some of these questions are silly.

Can we easily deploy Automoderator to a large number of wikis at once?

The only other thing I would add is that we also need to ensure all the extensions and configuration on the wikis play nice with Automoderator.
eg. Flow Extension

Good point! We should investigate/think about whether there are any lesser-used extensions which might cause a headache.

Can we interface with the global opt-out list, which I understand would effectively be the list of global vs local automoderator wikis?

I'm curious what the use case would be for this? Do we have any wikis that would not want to use the standard config in the extension.json or community config?

We, or stewards, need to define in some way what the list of possible wikis is that Stewards would have control over, assuming there's a centrally-configurable venue. That opt-out list is one such list, but may not be the right one for this use case.

In T372413#10120056, @Scardenasmolinar wrote:

Is it technically feasible for us to have a global (presumably on Meta) configuration page for Automoderator?
Could we have Automoderator use local configuration if it exists, and global configuration if not?

Based on my research, I don't think we can have a global configuration on Meta. I haven't seen any example of something like that implemented anywhere. I think we will have to rely on local configuration or on the configuration in extension.json.

Hello! Thanks for having this spike and for doing the research. CommunityConfiguration actually does support global configuration, even though no one makes use of this capability at this point. However, it is a relatively tricky topic, and I would be curious to learn how you envision the global configuration to be used. CommunityConfiguration offers two ways how to work with a global configuration:

(A) Via a global configuration provider
As of writing, all configuration providers are based on wikipages. However, this is not a requirement – it is possible to define a configuration provider that loads data from an URL address. It is also possible to define CommunityConfiguration-providers in configuration, as opposed to via extension.json. This makes it possible to do something like the following in the WMF configuration for AutoModerator:

// concept level configuration, to be put to CommonSettings.php under $wmgUseAutoModerator
if ( $wgDBname === 'metawiki' ) {
	$wgCommunityConfigurationProviders['AutoModeratorGlobal'] = [
		'store' => [
			'type' => 'wikipage',
			'args' => [ 'MediaWiki:AutoModeratorGlobalConfig.json' ],
		],
		'validator' => [
			'type' => 'jsonschema',
			'args' => [ 'AutoModerator\Config\Validation\AutoModeratorGlobalConfigSchema' ],
		],
		// To avoid mixups with local configuration
		'type' => 'data',
	];
} else {
	$wgCommunityConfigurationProviders['AutoModeratorGlobal'] = [
		'store' => [
			// NOTE: As of writing, exists only as a PoC patch for CommunityConfiguration (see below for more details)
			'type' => 'http',
			'args' => [ 'https://meta.wikimedia.org/w/api.php?action=query&format=json&meta=communityconfiguration&formatversion=2&ccrprovider=AutoModeratorGlobal' ],
		],
		'validator' => [
			// NOTE: Validation can be disabled here (relying on Meta's validation), or reinforced by using the same validator as Meta does
			'type' => 'noop',
		],
		// To avoid mixups with local configuration
		'type' => 'data',
	];
}

(in addition to this, the type for the existing AutoModerator provider would probably need to be changed to data as well)

The only missing part is the http store, which does not yet exist in MediaWiki-extensions-CommunityConfiguration. However, a while ago, the Growth team debated introducing it (although for different reasons). During those debates, I wrote a PoC code for the http store. We ended up not finishing the work, as we ultimately went with a different use-case for our use-case (see T359185 for details, if interested), but I believe it would be reasonably easy for an engineer to pick it up from where we left it.

Assuming the http provider gets introduced, this would effectively give AutoModerator two sets of configuration: one of them retrieved from the local wiki (queryable via ConfigurationProviderFactory::newProvider( 'AutoModerator' )), the other one from Meta-Wiki (queryable via ConfigurationProviderFactory::newProvider( 'AutoModeratorGlobal' )).

It would be then up to AutoModerator to decide when to use which one. For example, it could use global configuration if the wiki is small, and local configuration otherwise. This decision-making would have to be created within AutoModerator itself; CommunityConfiguration's role would be just providing both the global and local configuration, without translating them to single effective configuration.

(B) Via dynamic defaults
Right now, all CommunityConfiguration users define their defaults statically, via self::DEFAULT => (VALUE). Since T363412, CommunityConfiguration also supports dynamic defaults. This allows extensions to define defaults dynamically, on per-wiki basis. For example, AutoModerator might define one default if the wiki is small and another default if it is large. This is how it could look in a schema:

class AutoModeratorConfigSchema extends JsonSchema {

	public const AutoModeratorEnableRevisionCheck = [
		self::TYPE => self::TYPE_BOOLEAN,
		self::DEFAULT => false, // used as the "supradefault", when the dynamic default cannot be used for some reason
		self::DYNAMIC_DEFAULT => true,
	];

	public static function getDefaultAutoModeratorEnableRevisionCheck() { // this returns the actual default value for AutoModeratorEnableRevisionCheck
		return Utils::isWikiSmall( WikiMap::getCurrentWikiId() );
	}
}

If you decide to go through this approach, it is necessary to keep in mind the purpose of defaults. CommunityConfiguration only makes use of them until an admin presses Save Changes for the first time. Once that happens, CommunityConfiguration uses whatever the admin selected in the edit form the last time, without paying attention to the default. This is the case even if the default changes in the future (because a developer changes it, or because the dynamic default now evaluates to something else; for example, because a wiki is not small anymore). Once we get to the "all projects used CommunityConfiguration at least once" state, the default wouldn't have any effect anymore. For this reason, I do not recommend this approach, unless you are absolutely certain this meets your requirements.

Recommendation
If I were you, I would use the first option. Decision whether to use the global configuration or the local one can be left to the local community (via a local community configuration option, which would be used for routing the configuration). Using their own CommunityConfiguration form, they would be able to decide whether they want to leave control to the Stewards (and use the global configuration), or whether they want to control AutoModerator themselves (and use the local configuration). The default for this "routing" configuration option could be computed using the dynamic defaults, as it would provide each wiki with a reasonable default based on its size (allowing them to override the decision as necessary).

@Scardenasmolinar @Kgraessle, hope this overview helps with considering additional possibilities that may not be obvious after reviewing existing usages. If there is anything unclear in what I wrote above, or if you have any questions, let us know – I would be happy to answer them.

In T372413#10129650, @Samwalton9-WMF wrote:

We, or stewards, need to define in some way what the list of possible wikis is that Stewards would have control over, assuming there's a centrally-configurable venue. That opt-out list is one such list, but may not be the right one for this use case.

(Speaking from my Steward experience) I do not recommend this decision to be based solely on the wikiset. It is certainly a good starting point, but ultimately "using AutoModerator based on central configuration" and "allow global sysops to make sysop actions here" are very different decisions in nature. I think it would be best if individual wikis has the ability to opt out from the central configuration (ideally, using CommunityConfiguration), leaving the wikiset to only populate the initial configuration on that wiki.

In T372413#10130621, @Urbanecm_WMF wrote:

In T372413#10120056, @Scardenasmolinar wrote:

Is it technically feasible for us to have a global (presumably on Meta) configuration page for Automoderator?
Could we have Automoderator use local configuration if it exists, and global configuration if not?

Based on my research, I don't think we can have a global configuration on Meta. I haven't seen any example of something like that implemented anywhere. I think we will have to rely on local configuration or on the configuration in extension.json.

Hello! Thanks for having this spike and for doing the research. CommunityConfiguration actually does support global configuration, even though no one makes use of this capability at this point. However, it is a relatively tricky topic, and I would be curious to learn how you envision the global configuration to be used. CommunityConfiguration offers two ways how to work with a global configuration:

(A) Via a global configuration provider
As of writing, all configuration providers are based on wikipages. However, this is not a requirement – it is possible to define a configuration provider that loads data from an URL address. It is also possible to define CommunityConfiguration-providers in configuration, as opposed to via extension.json. This makes it possible to do something like the following in the WMF configuration for AutoModerator:

// concept level configuration, to be put to CommonSettings.php under $wmgUseAutoModerator
if ( $wgDBname === 'metawiki' ) {
	$wgCommunityConfigurationProviders['AutoModeratorGlobal'] = [
		'store' => [
			'type' => 'wikipage',
			'args' => [ 'MediaWiki:AutoModeratorGlobalConfig.json' ],
		],
		'validator' => [
			'type' => 'jsonschema',
			'args' => [ 'AutoModerator\Config\Validation\AutoModeratorGlobalConfigSchema' ],
		],
		// To avoid mixups with local configuration
		'type' => 'data',
	];
} else {
	$wgCommunityConfigurationProviders['AutoModeratorGlobal'] = [
		'store' => [
			// NOTE: As of writing, exists only as a PoC patch for CommunityConfiguration (see below for more details)
			'type' => 'http',
			'args' => [ 'https://meta.wikimedia.org/w/api.php?action=query&format=json&meta=communityconfiguration&formatversion=2&ccrprovider=AutoModeratorGlobal' ],
		],
		'validator' => [
			// NOTE: Validation can be disabled here (relying on Meta's validation), or reinforced by using the same validator as Meta does
			'type' => 'noop',
		],
		// To avoid mixups with local configuration
		'type' => 'data',
	];
}

(in addition to this, the type for the existing AutoModerator provider would probably need to be changed to data as well)

The only missing part is the http store, which does not yet exist in MediaWiki-extensions-CommunityConfiguration. However, a while ago, the Growth team debated introducing it (although for different reasons). During those debates, I wrote a PoC code for the http store. We ended up not finishing the work, as we ultimately went with a different use-case for our use-case (see T359185 for details, if interested), but I believe it would be reasonably easy for an engineer to pick it up from where we left it.

Assuming the http provider gets introduced, this would effectively give AutoModerator two sets of configuration: one of them retrieved from the local wiki (queryable via ConfigurationProviderFactory::newProvider( 'AutoModerator' )), the other one from Meta-Wiki (queryable via ConfigurationProviderFactory::newProvider( 'AutoModeratorGlobal' )).

It would be then up to AutoModerator to decide when to use which one. For example, it could use global configuration if the wiki is small, and local configuration otherwise. This decision-making would have to be created within AutoModerator itself; CommunityConfiguration's role would be just providing both the global and local configuration, without translating them to single effective configuration.

(B) Via dynamic defaults
Right now, all CommunityConfiguration users define their defaults statically, via self::DEFAULT => (VALUE). Since T363412, CommunityConfiguration also supports dynamic defaults. This allows extensions to define defaults dynamically, on per-wiki basis. For example, AutoModerator might define one default if the wiki is small and another default if it is large. This is how it could look in a schema:

class AutoModeratorConfigSchema extends JsonSchema {

	public const AutoModeratorEnableRevisionCheck = [
		self::TYPE => self::TYPE_BOOLEAN,
		self::DEFAULT => false, // used as the "supradefault", when the dynamic default cannot be used for some reason
		self::DYNAMIC_DEFAULT => true,
	];

	public static function getDefaultAutoModeratorEnableRevisionCheck() { // this returns the actual default value for AutoModeratorEnableRevisionCheck
		return Utils::isWikiSmall( WikiMap::getCurrentWikiId() );
	}
}

If you decide to go through this approach, it is necessary to keep in mind the purpose of defaults. CommunityConfiguration only makes use of them until an admin presses Save Changes for the first time. Once that happens, CommunityConfiguration uses whatever the admin selected in the edit form the last time, without paying attention to the default. This is the case even if the default changes in the future (because a developer changes it, or because the dynamic default now evaluates to something else; for example, because a wiki is not small anymore). Once we get to the "all projects used CommunityConfiguration at least once" state, the default wouldn't have any effect anymore. For this reason, I do not recommend this approach, unless you are absolutely certain this meets your requirements.

Recommendation
If I were you, I would use the first option. Decision whether to use the global configuration or the local one can be left to the local community (via a local community configuration option, which would be used for routing the configuration). Using their own CommunityConfiguration form, they would be able to decide whether they want to leave control to the Stewards (and use the global configuration), or whether they want to control AutoModerator themselves (and use the local configuration). The default for this "routing" configuration option could be computed using the dynamic defaults, as it would provide each wiki with a reasonable default based on its size (allowing them to override the decision as necessary).

@Scardenasmolinar @Kgraessle, hope this overview helps with considering additional possibilities that may not be obvious after reviewing existing usages. If there is anything unclear in what I wrote above, or if you have any questions, let us know – I would be happy to answer them.

---

In T372413#10129650, @Samwalton9-WMF wrote:

We, or stewards, need to define in some way what the list of possible wikis is that Stewards would have control over, assuming there's a centrally-configurable venue. That opt-out list is one such list, but may not be the right one for this use case.

(Speaking from my Steward experience) I do not recommend this decision to be based solely on the wikiset. It is certainly a good starting point, but ultimately "using AutoModerator based on central configuration" and "allow global sysops to make sysop actions here" are very different decisions in nature. I think it would be best if individual wikis has the ability to opt out from the central configuration (ideally, using CommunityConfiguration), leaving the wikiset to only populate the initial configuration on that wiki.

@Urbanecm_WMF Thank you for this very informative reply!
It does sound like option A is the direction we'd like to go.

In that case @Samwalton9-WMF whatever ticket comes from this spike would be dependent on completing the POC work that was started in T359185: Community configuration: Define behaviour for external titles and wikipage-based configuration store.
I'll let the rest of the engineers get a chance to review this though before we make any decisions.

In T372413#10130621, @Urbanecm_WMF wrote:

In T372413#10120056, @Scardenasmolinar wrote:

Is it technically feasible for us to have a global (presumably on Meta) configuration page for Automoderator?
Could we have Automoderator use local configuration if it exists, and global configuration if not?

Based on my research, I don't think we can have a global configuration on Meta. I haven't seen any example of something like that implemented anywhere. I think we will have to rely on local configuration or on the configuration in extension.json.

Hello! Thanks for having this spike and for doing the research. CommunityConfiguration actually does support global configuration, even though no one makes use of this capability at this point. However, it is a relatively tricky topic, and I would be curious to learn how you envision the global configuration to be used. CommunityConfiguration offers two ways how to work with a global configuration:

(A) Via a global configuration provider
As of writing, all configuration providers are based on wikipages. However, this is not a requirement – it is possible to define a configuration provider that loads data from an URL address. It is also possible to define CommunityConfiguration-providers in configuration, as opposed to via extension.json. This makes it possible to do something like the following in the WMF configuration for AutoModerator:

// concept level configuration, to be put to CommonSettings.php under $wmgUseAutoModerator
if ( $wgDBname === 'metawiki' ) {
	$wgCommunityConfigurationProviders['AutoModeratorGlobal'] = [
		'store' => [
			'type' => 'wikipage',
			'args' => [ 'MediaWiki:AutoModeratorGlobalConfig.json' ],
		],
		'validator' => [
			'type' => 'jsonschema',
			'args' => [ 'AutoModerator\Config\Validation\AutoModeratorGlobalConfigSchema' ],
		],
		// To avoid mixups with local configuration
		'type' => 'data',
	];
} else {
	$wgCommunityConfigurationProviders['AutoModeratorGlobal'] = [
		'store' => [
			// NOTE: As of writing, exists only as a PoC patch for CommunityConfiguration (see below for more details)
			'type' => 'http',
			'args' => [ 'https://meta.wikimedia.org/w/api.php?action=query&format=json&meta=communityconfiguration&formatversion=2&ccrprovider=AutoModeratorGlobal' ],
		],
		'validator' => [
			// NOTE: Validation can be disabled here (relying on Meta's validation), or reinforced by using the same validator as Meta does
			'type' => 'noop',
		],
		// To avoid mixups with local configuration
		'type' => 'data',
	];
}

(in addition to this, the type for the existing AutoModerator provider would probably need to be changed to data as well)

The only missing part is the http store, which does not yet exist in MediaWiki-extensions-CommunityConfiguration. However, a while ago, the Growth team debated introducing it (although for different reasons). During those debates, I wrote a PoC code for the http store. We ended up not finishing the work, as we ultimately went with a different use-case for our use-case (see T359185 for details, if interested), but I believe it would be reasonably easy for an engineer to pick it up from where we left it.

Assuming the http provider gets introduced, this would effectively give AutoModerator two sets of configuration: one of them retrieved from the local wiki (queryable via ConfigurationProviderFactory::newProvider( 'AutoModerator' )), the other one from Meta-Wiki (queryable via ConfigurationProviderFactory::newProvider( 'AutoModeratorGlobal' )).

It would be then up to AutoModerator to decide when to use which one. For example, it could use global configuration if the wiki is small, and local configuration otherwise. This decision-making would have to be created within AutoModerator itself; CommunityConfiguration's role would be just providing both the global and local configuration, without translating them to single effective configuration.

(B) Via dynamic defaults
Right now, all CommunityConfiguration users define their defaults statically, via self::DEFAULT => (VALUE). Since T363412, CommunityConfiguration also supports dynamic defaults. This allows extensions to define defaults dynamically, on per-wiki basis. For example, AutoModerator might define one default if the wiki is small and another default if it is large. This is how it could look in a schema:

class AutoModeratorConfigSchema extends JsonSchema {

	public const AutoModeratorEnableRevisionCheck = [
		self::TYPE => self::TYPE_BOOLEAN,
		self::DEFAULT => false, // used as the "supradefault", when the dynamic default cannot be used for some reason
		self::DYNAMIC_DEFAULT => true,
	];

	public static function getDefaultAutoModeratorEnableRevisionCheck() { // this returns the actual default value for AutoModeratorEnableRevisionCheck
		return Utils::isWikiSmall( WikiMap::getCurrentWikiId() );
	}
}

If you decide to go through this approach, it is necessary to keep in mind the purpose of defaults. CommunityConfiguration only makes use of them until an admin presses Save Changes for the first time. Once that happens, CommunityConfiguration uses whatever the admin selected in the edit form the last time, without paying attention to the default. This is the case even if the default changes in the future (because a developer changes it, or because the dynamic default now evaluates to something else; for example, because a wiki is not small anymore). Once we get to the "all projects used CommunityConfiguration at least once" state, the default wouldn't have any effect anymore. For this reason, I do not recommend this approach, unless you are absolutely certain this meets your requirements.

Recommendation
If I were you, I would use the first option. Decision whether to use the global configuration or the local one can be left to the local community (via a local community configuration option, which would be used for routing the configuration). Using their own CommunityConfiguration form, they would be able to decide whether they want to leave control to the Stewards (and use the global configuration), or whether they want to control AutoModerator themselves (and use the local configuration). The default for this "routing" configuration option could be computed using the dynamic defaults, as it would provide each wiki with a reasonable default based on its size (allowing them to override the decision as necessary).

@Scardenasmolinar @Kgraessle, hope this overview helps with considering additional possibilities that may not be obvious after reviewing existing usages. If there is anything unclear in what I wrote above, or if you have any questions, let us know – I would be happy to answer them.

---

In T372413#10129650, @Samwalton9-WMF wrote:

We, or stewards, need to define in some way what the list of possible wikis is that Stewards would have control over, assuming there's a centrally-configurable venue. That opt-out list is one such list, but may not be the right one for this use case.

(Speaking from my Steward experience) I do not recommend this decision to be based solely on the wikiset. It is certainly a good starting point, but ultimately "using AutoModerator based on central configuration" and "allow global sysops to make sysop actions here" are very different decisions in nature. I think it would be best if individual wikis has the ability to opt out from the central configuration (ideally, using CommunityConfiguration), leaving the wikiset to only populate the initial configuration on that wiki.

Thank you @Urbanecm_WMF for the insightful comment. Like @Kgraessle, I think option A would be the way to go. In today's mid-sprint meeting, we discussed maybe using a SpamBlackList approach that would be at odds with CommunityConfig, so being able to use CC would be ideal for AutoModerator.

Here is a further summary of what was discussed today in our mid-sprint meeting:

• Another option would be to try implementing something similar to what SpamBlackList does. A disadvantage of this approach would be that it would be at odds with Community Configuration. This would add more complexity to AutoModerator's configuration.
• We mentioned Community Configuration's global configuration capability which means we could use something already in use by AutoModerator.
• Choosing the straight configuration route would be relatively straightforward, but stewards would probably need to have some technical skills and changes would need to be backported or they would need to wait for the train.

In T372413#10132295, @Scardenasmolinar wrote:

Here is a further summary of what was discussed today in our mid-sprint meeting:

• Another option would be to try implementing something similar to what SpamBlackList does. A disadvantage of this approach would be that it would be at odds with Community Configuration. This would add more complexity to AutoModerator's configuration.
• We mentioned Community Configuration's global configuration capability which means we could use something already in use by AutoModerator.
• Choosing the straight configuration route would be relatively straightforward, but stewards would probably need to have some technical skills and changes would need to be backported or they would need to wait for the train.

Sorry it's taken me a while to weigh in on this here; after reviewing the discussion here and in the mentioned tasks and patches, I think we should move forward with wmf-config-based provider (or straight config) for globally managed wikis; I don't think adding a http-based config lookup will be a great fit for automoderator since it will run after pretty much every edit on a wiki. To be clear @Samwalton9-WMF, this means that we wouldn't be blocked on any CC work so far as I can tell, but it does have the downsides Susana mentions above, eg. global changes require a backport.

@Kgraessle does this sound reasonable? If we're not in alignment on it, we can talk through it some more in engineering. I can be convinced otherwise!

In T372413#10150365, @jsn.sherman wrote:

In T372413#10132295, @Scardenasmolinar wrote:

Here is a further summary of what was discussed today in our mid-sprint meeting:

• Another option would be to try implementing something similar to what SpamBlackList does. A disadvantage of this approach would be that it would be at odds with Community Configuration. This would add more complexity to AutoModerator's configuration.
• We mentioned Community Configuration's global configuration capability which means we could use something already in use by AutoModerator.
• Choosing the straight configuration route would be relatively straightforward, but stewards would probably need to have some technical skills and changes would need to be backported or they would need to wait for the train.

Sorry it's taken me a while to weigh in on this here; after reviewing the discussion here and in the mentioned tasks and patches, I think we should move forward with wmf-config-based provider (or straight config) for globally managed wikis; I don't think adding a http-based config lookup will be a great fit for automoderator since it will run after pretty much every edit on a wiki. To be clear @Samwalton9-WMF, this means that we wouldn't be blocked on any CC work so far as I can tell, but it does have the downsides Susana mentions above, eg. global changes require a backport.

@Kgraessle does this sound reasonable? If we're not in alignment on it, we can talk through it some more in engineering. I can be convinced otherwise!

That's a really good point on using http-based config lookup affecting performance due to making an http call on every edit.
I'm not sure I completely understand the straight configuration approach- would this just be defining default configuration in the mediawiki-config repository for the smaller wikis?

Yep! We could provide a single shared config for a group of globally managed wikis.

In T372413#10150456, @jsn.sherman wrote:

Yep! We could provide a single shared config for a group of globally managed wikis.

Ok, sounds perfectly reasonable to me then!

In T372413#10150365, @jsn.sherman wrote:

[...] I don't think adding a http-based config lookup will be a great fit for automoderator since it will run after pretty much every edit on a wiki. [...]

! In T372413#10150453, @Kgraessle wrote:

That's a really good point on using http-based config lookup affecting performance due to making an http call on every edit.

FWIW, using a HTTP-based lookup shouldn't be a performance problem. In practice, it would be a memcached lookup the vast majority of times, as CommunityConfiguration would cache the result of the store, and only does a full read if needed (at least once a day, plus whenever the configuration is updated).

This is an approach that several other extensions already make use of, seemingly without problems. Specifically, TitleBlacklist or SpamBlacklist also run on every edit and their configuration is in part HTTP-based (https://meta.wikimedia.org/wiki/Title_blacklist, https://meta.wikimedia.org/wiki/Spam_blacklist are both loaded via HTTP internally).

Taking this off our Kanban board while we wait for further Legal response.