CommunityConfiguration extension also does this.

This is about server side code such as this one: rEWMVaa3ea0c662a06b634ba93259fab34241c397f2a0

There's CSS now in WikimediaMessages too that maybe should have a better home. :)

There are also 24 usages of $wgHooks at https://noc.wikimedia.org/conf/highlight.php?file=CommonSettings.php

https://www.mediawiki.org/wiki/Gerrit/New_repositories/Requests#mediawiki/extensions/WikimediaHooks

We have three Wikimedia* extensions that are for adapting other extensions' behavior to Wikimedia policies/expectations/brand/whatever:

What if instead of making a 4th extension (and a 5th place overall for WMF deployed changes) the 3 existing extensions were merged into a single "WikimediaCustomizations" extension? I don't care about the name, but generally the idea would be have one spot to put all the MediaWiki internals changes (message customization, analytics integration, maintenance scripts, miscellaneous hook implementations) and operations/mediawiki-config for LocalSettings.php configuration things.

In T401939#11183014, @bd808 wrote:

We have three Wikimedia* extensions that are for adapting other extensions' behavior to Wikimedia policies/expectations/brand/whatever:

What if instead of making a 4th extension (and a 5th place overall for WMF deployed changes) the 3 existing extensions were merged into a single "WikimediaCustomizations" extension? I don't care about the name, but generally the idea would be have one spot to put all the MediaWiki internals changes (message customization, analytics integration, maintenance scripts, miscellaneous hook implementations) and operations/mediawiki-config for LocalSettings.php configuration things.

(1) Making an extension having different purposes is bad, since we expect each extension has a clear group of maintainers and merging extensions with different (potential) maintainers defeats such purpose. (2) WikimediaMaintenance is just used in CLI and not deployed anywhere.

In T401939#11183014, @bd808 wrote:

What if instead of making a 4th extension (and a 5th place overall for WMF deployed changes) the 3 existing extensions were merged into a single "WikimediaCustomizations" extension?

It would definitely simplify things conceptually. Some drawbacks I can think of:

• Loss of git history (or some complicated and imperfect history rewrite).
• More migration work - setting up a new extension is straightforward, moving code from one extension to another while the site depends on the functionality (especially if we want to somewhat preserve git history) is less so. But then we want to migrate a fair amount of current hooks anyway...
• More complex CI dependency chains. WikimediaMessages is depended on by a lot of extensions. (Though I'm not really sure why - i18n replacements shouldn't meaningfully affect tests, right?) Meanwhile WikimediaEvents is not dependend on that much but itself has a pretty impressive dependency list.
• Maybe harder to install locally? Both WikimediaMessages and WikimediaEvents provide lots of integrations that you'd want to test locally when working on an extension they interact with. Then again, as long as this generic site customization doesn't hard depend on the extensions it interacts with, I don't think that should be a problem.

Aside from the naming (which as we know is hard), this does not need to be decided upfront - some or all of the other Wikimedia* extensions could be merged into it at any point in time.

There are btw a bunch of other extensions named WikimediaSomething (WikimediaEditorTasks, WikimediaIncubator, WikimediaBadges, WikimediaApiPortalOAuth, WikimediaCampaignEvents) but I think those are more like normal extensions that provide some self-contained feature without interacting a lot with other extensions, that feature just happens to be something that's probably only of interest to Wikimedia wikis. (Or maybe not? I'm not really familiar with most of them.)

(Also, a historical example of consolidating code: T57678: Move WikimediaShopLink's i18n messages to WikimediaMessages extension and move the Skin hook to wmf-config)

Is the Wikisource extension the only Wikimedia project-specific extension so far? Splitting by project like that seems like a reasonable way to limit an extension's scope — although of course lots of what's in question here is globally-applicable stuff.

It does sound like a general Wikimedia extension makes lots of sense, better than splitting things into separate Wikimedia* extensions based on implementation detail. It could perhaps become a tempting place to put things that might be better built to be wiki-agnostic (i.e. easier than setting up a new extension), but if the alternative is mediawiki-config then it'd definitely be an improvement.

In T401939#11184117, @Samwilson wrote:

Is the Wikisource extension the only Wikimedia project-specific extension so far? Splitting by project like that seems like a reasonable way to limit an extension's scope — although of course lots of what's in question here is globally-applicable stuff.

It does sound like a general Wikimedia extension makes lots of sense, better than splitting things into separate Wikimedia* extensions based on implementation detail. It could perhaps become a tempting place to put things that might be better built to be wiki-agnostic (i.e. easier than setting up a new extension), but if the alternative is mediawiki-config then it'd definitely be an improvement.

See https://www.mediawiki.org/wiki/Category:Wiki-specific_extensions. Currently there are 8 Wikimedia-specific extensions.

Let's go with the more generic WikimediaCustomizations name, and leave it to the future whether WikimediaMessages etc. gets merged. I don't want to block this task on that (there are some relatively urgent motivations for it), and the CI issue seems potentially disruptive.

In T401939#11198304, @Tgr wrote:

Let's go with the more generic WikimediaCustomizations name, and leave it to the future whether WikimediaMessages etc. gets merged. I don't want to block this task on that (there are some relatively urgent motivations for it), and the CI issue seems potentially disruptive.

Could we make it more specific? WikimediaOverrides? WikimediaCustomConfig?

What if instead of making a 4th extension (and a 5th place overall for WMF deployed changes) the 3 existing extensions were merged into a single "WikimediaCustomizations" extension?

Big +1 to this end goal. FWIW I do think we could retain git history using sub directories and git remote.

WikimediaOverrides

+1 to this name.

In T401939#11198305, @Jdforrester-WMF wrote:

Could we make it more specific? WikimediaOverrides? WikimediaCustomConfig?

No objections in theory although those sound less specific to me.

WikimediaCustomizations has meanwhile been created though so if you don't have strong feelings about the name, I'll stick with that.

(If you do have strong feelings about the name, we can create another repo - certainly easier now than once it's deployed.)

In T401939#11214024, @Tgr wrote:

In T401939#11198305, @Jdforrester-WMF wrote:

Could we make it more specific? WikimediaOverrides? WikimediaCustomConfig?

No objections in theory although those sound less specific to me.

Per your desciption, this is meant to be the ultra-repo with six current use cases slammed into it. "Less specific" is apt, surely? :-)

WikimediaCustomizations has meanwhile been created though so if you don't have strong feelings about the name, I'll stick with that.

"Customisations" (and "CustomConfig", for that matter) implies a system with config options where we're picking from a list; but that already exists, opeations/mediawiki-config. "Overrides" at least strongly suggests that we're changing the code to do something different from how it would normally work, which I think is closer?

(If you do have strong feelings about the name, we can create another repo - certainly easier now than once it's deployed.)

Eh.

Slight side note; IMO it might be a good idea to have something similar to WikimediaEvents' OWNERS.md for the new extension, to ensure that the stewardship information for each part of the code is documented/easily accessible :)

(It might also be a good idea to have an overarching extension steward regardless, in case e.g. there end up being any parts of the extension for which stewardship becomes unclear.)

Change #1213464 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/vagrant@master] Add wikimediacustomizations role

https://gerrit.wikimedia.org/r/1213464

Change #1213507 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/WikimediaCustomizations@master] Initial commit - add boilerplate

https://gerrit.wikimedia.org/r/1213507

Change #1213508 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/WikimediaCustomizations@master] Add README

https://gerrit.wikimedia.org/r/1213508

Change #1214202 had a related patch set uploaded (by Krinkle; author: Krinkle):

[integration/config@master] zuul: Define jobs for mediawiki/extensions/WikimediaCustomizations repo

https://gerrit.wikimedia.org/r/1214202

Change #1214202 merged by jenkins-bot:

[integration/config@master] zuul: Define jobs for mediawiki/extensions/WikimediaCustomizations repo

https://gerrit.wikimedia.org/r/1214202

Change #1213507 merged by jenkins-bot:

[mediawiki/extensions/WikimediaCustomizations@master] Initial commit - add boilerplate

https://gerrit.wikimedia.org/r/1213507

Change #1213508 merged by jenkins-bot:

[mediawiki/extensions/WikimediaCustomizations@master] Add README

https://gerrit.wikimedia.org/r/1213508

Change #1213464 merged by Gergő Tisza:

[mediawiki/vagrant@master] Add wikimediacustomizations role

https://gerrit.wikimedia.org/r/1213464

@Jdforrester-WMF Writing an extension for deployment says

Add your extension to the json make-wmf-branch release tool at least two weeks prior to your target date for enabling on the Beta Cluster.

but that was probably written with the old train deploy schedule in mind and one week is enough, right?

In T401939#11455222, @Tgr wrote:

@Jdforrester-WMF Writing an extension for deployment says

Add your extension to the json make-wmf-branch release tool at least two weeks prior to your target date for enabling on the Beta Cluster.

but that was probably written with the old train deploy schedule in mind and one week is enough, right?

We have been debating the continued need for this instruction at all in T125678: Scap reliance on extension-list in turn requires extensions to be deployed to WMF production before being deployed to the Beta Cluster, but to answer your current question the two week (and thus two MediaWiki wmf/* releases) time window is correct.

The extension is in production. Moving over existing i18n messages from other extensions is blocked on T415096: Add WikimediaCustomizations to Translatewiki.

In T401939#11539698, @Tgr wrote:

The extension is in production. Moving over existing i18n messages from other extensions is blocked on T415096: Add WikimediaCustomizations to Translatewiki.

Well, you also should have a task for that work, as it'll need a bit of re-config at the TWN end too.

That's T412034: Move Wikimedia-specific i18n messages to WikimediaCustomizations extension.