A brief summary of my intent with this ticket:

Users not experienced enough in software development have no business writing code to be executed on all our user's devices.

Everybody is welcome to contribute ideas, create tasks, start polls, etc. but you need an engineer to do the engineering. When I say "engineers" I'm not referring to Wikimedia Foundation staff. Instead, it should fully embrace open source. With the added difference that this "gadget repository" should be viral. Similar to how wikis hand out access for bureaucrats and sysops. In the common case, all granting and revoking of access in this context should be handled by the community, not staff.

The way and the place in which Gadgets are developed should change. But we should not change the the essential purpose and use case of Gadgets.

I don't believe the purpose of Gadgets was to allow people with no engineering experience to react to user requests, hunt the internet for some scrap pieces of code (without having the faintest idea how the code works), and upload the programs onto the wiki. It's the equivalent of having me pilot an airplane. It's irresponsible and sets unfair expectations. Of course I'd screw up if you let them drive a plane.

If that's not the essence of Gadgets, then what is? The essence of Gadgets is the ability for the community to decide together what and how they want to build features. They can propose ideas and when they agree on an idea, they find other users with the knowledge to make that idea a reality.

Back in 2006, Wikimedia had a tightly controlled repository (SVN). There was little manpower to maintain separate access controls. Deployments were scarce (every 3-6 months). For those reasons, it was not feasible and not reasonable to maintain gadgets in SVN.

Instead we utilised the storage engine behind MediaWiki and appointed users to maintain gadgets that way. This had obvious drawbacks. No way to validate code, no testing, syntax errors, no regression testing or staging. Relying solely on users to catch issues after deployment (e.g. "saving the page"). It was also hard to maintain the code itself with no support for indentation and other IDE features (due to the HTML textarea semantics). This is why many gadget authors choose to keep their code elsewhere (e.g. on their own computer, or in Git); and merely copying it to the wiki when "deploying" the changes.

When adding a code review system of sorts in front of Gadgets, it is inevitable that that system will be a barrier of sorts. We'll do our best to make it easy to use, but there will be an inevitable barrier. The question is, will we choose a barrier in the form of a MediaWiki extension? An extension that nobody will be familiar with, that will not benefit from existing manuals, tutorials, user-friendly desktop interfaces etc. An extension that would only solve the code-review aspects and not all the other aspects (being able to use an IDE, having testing, having localisation, etc.)

Or we can enter the realm of Git. A small barrier that is actually quire //relevant// to software developers. I've encountered plenty of competent hobby programmers with years of experience that hadn't used Git before. It's something new, and yeah, that can be scary. But I doubt it's too complex for someone we expect to be writing code. Especially with all the existing GUI applications for Git.