As both an active gadget writer (on pl.wikipedia) and a core developer, let me say that
while I would *love* to have a somewhat formalized code-review process for gadgets, it is
pretty much not possible, and the reason is twofold.
First, code-review is, apart from spotting bugs, about getting the code to adhere to
certain formal standards and code conventions. We have lots of such standards and
conventions in core, for example, and while almost all of them are useful or (at least not
troublesome) to a seasoned developer working in a team of a few dozen people, every single
one is also *damned boring* – and if we make writing gadgets not enjoyable, people will
stop writing them.
When you're a single person working on a 200-line script, who the hell cares if you
use == or ===, or if you use multiple `var` declarations in a function, or if you use
`alert()` to notify the user that something went very wrong? In most cases this does not
matter, and if the code works, that's all good. Unfortunately writing code for core is
largely about petty things like this; if you're a biologist who learned to program for
fun and wrote a tool in JS to scratch your own itch, code style matters very little, both
for you and for other people who enjoy using your toy.
Second, en.wp might be an exception, but most communities simply don't have enough
active people. On pl.wp (ninth largest Wikipedia), I am currently the only active
JavaScript person; who do I ask for review? Even if core developers or people from other
wikis volunteered, they'd surely not be able to understand the "domain",
especially due to the language barrier. And my core experiences say that the slowest part
of code-review is getting someone to do it (I have 30+ unreviewed or +1'd patches
pending right now).
And as Brad mentioned, informal code review happens; people watch gadgets' pages and
look at the changes, non-admins have to ask admins to have their gadget code
"merged", admins are generally responsible people anyway, and even *if*
something bad does happen (which I feel happens less often than with MW deployments,
really), reverting or fixing the change takes one click instead of a multi-hour deployment
process.
I really liked what Jon said at the beginning, and what has apparently been lost in the
discussions already – "Keep gadgets for experiment, but ensure global gadgets are
held to a higher standard of quality and made more visible to a wider audience.".
Proper global gadgets still don't exist, but when they finally happen, experienced
coders who do this for a living should take them under their wings (to clean up existing
code, to check new contributions – but a "post-merge" code-review might still be
more appropriate); but local gadgets should stay the safe haven of innovation they are
now.
--
Matma Rex