>>! In T71445#968479, @Ricordisamoa wrote:
> I know this has probably been discussed before, but... what about hosting gadgets via Git/Phabricator?
> At least the largest ones will benefit from more thorough review.

Thanks for bringing this up @Ricordisamoa!

I support the idea of using Git for gadgets in the future. There are other options, but Git is nice.

Using Git/Phabricator for gadgets provides many benefits:

* Code review
 * Review by another person before merging (more stable code).
 * Ability for anyone to submit a patch that others can easily merge (instead of copy-pasting from a talk page, or a user sub page).
 * Inline discussion about the code and making small improvements.
* Continuous integration
 * Ability to write and run unit tests (less breakage for users).
 * Option to enforce coding style and code quality via JSHint (opt-in of course).
* Git
 * "git-blame" to find authors of a particular pieces of code.
 * The option to distinguish between stable and beta versions.
 * Easily backport (apply) individual bugfixes to older versions.
 * Streamlined process for deploying weekly to all wikis (for "global" gadgets).
 * Ability for non-Wikimedia wikis to "install" gadgets on their wikis (and update it). Instead of copying all relevant pages and trying to keep them up-to-date. (Or hotlinking via extra HTTP requests and risking breakage with incompatible versions.)
 * Ability for MediaWiki site-admins to install the right version of gadgets on their wikis. (Thanks to Git branches associated with a MediaWiki  release version.) – No more need to maintain compatibility with old MediaWiki versions or hotlinking code.
* Issue tracker
 * Central place to create and resolve tasks, bugs and feature requests.

We could create an extension like "WikimediaGadgets". Or separate Git repositories with git-submodules or Composer-based. Everything is possible.

Using Git does raise the barrier for contribution a little. But in full perspective of where we are coming from and what we all want, I think that's worth raising the barrier for. With gadgets, the community creates their own modules without involving Wikimedia Foundation. They can create and deploy anything they want. It's very enabling and flexible for the community.

In the last few years, Wikimedia has changed a lot in how it manages code. We no longer have a single repository managed by a handful of people that only deploy updates once or twice a year. Quite the contrary. We now have a plethora of different repositories maintained by different people (including lots of volunteers!). This "Wikimedia Gadgets" repo can have its own access control in Git – separate from MediaWiki and Wikimedia user groups.

Some gadgets have already done this by using GitHub (except for the deployment part, these still copy-paste to wiki pages):
* https://github.com/azatoth/twinkle
* https://github.com/Krinkle/mw-gadget-rtrc
* https://github.com/Krinkle/mw-gadget-whatleaveshere
* https://github.com/countervandalism/mw-gadget-cvnoverlay

Aside from the benefits for authors and users of gadgets, there are a few extra gains.

We'd have a clear distinction between the "wiki-content administrator" role (sysop) and "developer" role. One person can still have both roles, but sysop would no longer imply "developer". We currently have a situation where users can become sysop (to block users, delete pages, etc.) – but at the same time able to change gadgets. (Through the MediaWiki-namespace that got unfortunately re-used for Gadgets). This isn't a matter of personal trust or malicious intent. These users have clearly gained the respect and trust of their respective communities. It's about technical competence and experience to make decisions about software modifications. This is a sensitive area. It's not fair to demand from most sysops that they have to make these decisions. They shouldn't have to deal with requests for edits on Common.js without knowing what the impact of such program would be.

I often find privacy violations in Common.js in the form of well-intended scripts that load files from third-parties. (E.g. fonts, images or scripts.) This is against the Foundations' privacy policy, and probably not what the sysop intended. There's a good chance the sysop and user who suggested such edit, actually believe in our privacy policy. But they simply lack knowledge of how web browsers work. They didn't realise that such edit would result in all readers of the wiki now loading a file from a Google server. (And send their IP address and other details about their computer and geolocation to that Google server – without consent.)

The wikis can use their own policies for deciding what gadget to create, support and enable. The code would be reviewed by members of the community interested in development, instead of sysops. Sysops can still control which gadgets they enable by default etc.