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

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.

Done!

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

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

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?

Thanks, I am now resolving this task!

Let's hope this time the bots stay away 😄

I have just installed CheckUser and it was pretty straight-forward. We created this task in case it was more challenging like installing PageTriage was.

@Samwalton9-WMF should we create a spike to investigate how to install ORES on idwiki before we proceed on this ticket?

Hi @BAPerdana-WMF! One last thing, you will need to modify https://id.wikipedia.org/wiki/MediaWiki:AutoModeratorConfig.json on late Thursday/early Friday to add the config AutoModeratorSkipUserRights: [ "bot", "autopatrol" ] instead of AutoModeratorSkipUserGroups. We will now use user rights instead of user groups to skip edits made by trusted accounts. This change will roll out on next week's train.

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

Thanks for creating the ticket!

This change is incoming on next week's train, so if you could make the change on late Thursday/ early Friday next week, that would be great!

@Dogu, for next week can you add the config AutoModeratorSkipUserRights: [ "bot", "autopatrol" ]instead of AutoModeratorSkipUserGroups? We will now use user rights instead of user groups to skip edits made by trusted accounts.

Looks like some bots are still trying to access some non-existent URLs. I think we should 403 them in the nginx configuration.

Merged! I will keep an eye on GlitchTip to see if the errors re-appear.

Merged!

Moving this to QA. We should be able to test this on testwiki tomorrow afternoon.

Got it! That's the signature that's currently ready for review in Gerrit!

I have added the signature to the end of the message. I want your opinions on which signature looks better.

Merged and reviewed that this is working in production. Moving this ticket to Done.

I don't see it on Mac browsers (Safari, Firefox, Chrome). Therefore, I am resolving this ticket. Thanks for the follow-up for an old ticket :)

We will take a look at it as soon as tests are added to the patch!