Let's start with the gadgets that aren't edited by anybody: They aren't edited by anybody for one of the following two reasons:
- Because they are stable and don't need any edits.
- Because on that wiki there is nobody who has the skills to edit them.
If it's number two, this means that they were copied from another wiki. Let's follow your example, and think of MediaWiki:Gadget-HotCat.js in fa.wikiquote: Somebody at some point thought that fa.wikiquote needs that gadget, and copied it. Why did HotCat have to be copied, while RevisionSlider didn't have to be copied, and works everywhere? Because HotCat is a gadget and RevisionSlider is an extension. No one "edits" RevisionSlider on any wiki, neither fa.wikiquote nor de.wikipedia, because it's an extension. There's nothing fundamentally different between RevisionSlider and HotCat—both provide some extra functionality to users. They are different only in how their code is stored and deployed.
If we had a global repository of gadgets, HotCat could be stored globally, and automatically deployed to fa.wikiquote. No one would have to edit the gadget on fa.wikiquote.
But you know what's the craziest part? In practice, we already have a global repository of gadgets. Gadgets can be stored on another wiki, e.g. Commons, and loaded using
mw.loader.load() and a URL, as it is already done with HotCat and a few other gadgets. So, HotCat is a huge gadget, with thousands of lines of code and tens of thousands of users on the English Wikipedia alone, and many thousands more in other wikis. Technically, any Commons admin, of which there are more than 200, can edit it without any more code review. I heard that in the particular case of HotCat there's a convention that every edit is supposed to be checked by someone, but this is a social convention and not a technical constraint. And for some gadgets there is no such convention, and they can just be edited. And there are even some user scripts that aren't stored in the MediaWiki space, so anyone can edit them, and not just admins.
Why is HotCat a gadget and not an extension? No particular reason. Just history. I asked some people involved in its development, and they all said that it can be converted to an extension, and no one bothered to do it. And probably no one really feels that it's necessary, because the current way to develop it, as a wiki page, is good enough. Besides, converting it to an extension has some disadvantages: code review will get harder and changes that do pass code review will be deployed after a week and not immediately.
You also asked about Backport windows (formerly known as SWAT). Backport windows are not fun. You have to be at a certain (online) place at a certain time, connect to IRC (IRC!!!!!! In 2020!!!!!!), wait for your turn, and then wait a few minutes more for scap and all that stuff to run (at least that's how it was a few months ago, last time I did it; maybe things changed since then). It's far, far more difficult than editing a wiki page and pushing "Publish".
Does bad code sneak into gadgets sometimes? Yes, it does. If it was intentional and malicious, the user who did it is usually desysopped or blocked. But bad things can also sneak into code on Gerrit. Does it happen much more often with gadgets than with Gerrit? I honestly don't know, I didn't count. But consider this: reverting bad code in gadgets is actually much easier and faster than reverting code that is deployed through Gerrit—yet again, you just edit a wiki page and push "Publish". No code review, no scheduling a backport window, no waiting for scap. In any case, what's really important is that the possibility of breaking things shouldn't be the top reason to stop every conversation that compares the easiness of deploying code immediately to the difficulty of going through long code review and waiting for several days to deploy.
There is a lot of code that could be deployed immediately after merging. Dozens of extensions could be like that. Just looking at Special:Version: CodeEditor, WikiEditor, Score, SyntaxHighlight, WikiHiero, TimedMediaHandler, WikimediaMessages, and many others. Some of them are more complex than HotCat, but not by orders of magnitude. I can even imagine some parts of more complex extensions, such as VisualEditor, ContentTranslation, or Echo, that could be deployed more quickly.
So, my particular proposals:
- Reduce the deployment train frequency from once a week to once a day or even more.
- Change some repositories' configuration so that their code would be deployed immediately after merging, without waiting for train or backport window.
- Give merge rights to many more people who are trusted editors on Wikimedia projects, at least on some repositories.
- Allow self-merging in some repos (both technically and socially).
Most of these things will require some development work, but for all of them, someone first needs to decide that they are desirable. I mean, someone decided about eight years ago that code will be deployed every week; is that decision still good in 2020? Who can decide that it should be more frequent?
And most of these things can probably be done with Gerrit, without waiting for the migration to GitLab. As I mention already, I totally realize that these thoughts are not really about the migration from Gerrit to GitLab, but about something else. They are about rules and power structures. However, I am bringing them up here because I want to draw everyone's attention to the notion that by itself migration to GitLab will at most resolve some technical issues that the CI people have, and it won't resolve the bigger issues that the Wikimedia editors' community has with the way we manage and deploy source code.