@Quiddity and @Qgil casually responded in an email thread about "What does a pipeline for community software experiments look like?", and the answers were interesting. They could constitute the beginning of a draft in mediawiki.org about this topic. No specific plan at the moment, but let's just not lose those thoughts in those emails.

The quite raw replies:

I wonder whether our discussions about community/distributed innovation would benefit from some technical background to understand how "distributed innovation" actually works in Wikimedia, and how we could improve it. I'm saying this because nowadays a lot of that innovation doesn't "get into trunk", and getting into trunk happens quite often without any WMF Product involvement at all. Meanwhile, when a developer does want to get something into trunk following the processes defined by the WMF, chances are that they will get stuck in under-resourced queues.

Usually everything starts with a gadget, a template, a bot, or a tool scratching someone's itch. These are pieces of software that a single developer can write and deploy without needing any review or permissions.

Usually the next step is promotion in the channels of the project(s) where the piece of software is being deployed. For many developers this step takes more effort and is more likely to fail than actually writing the piece of software.

In some cases, adoption will eventually arrive (might take months, or years). In some cases, when the curve of adoption really hits, the original author is long gone, posing a problem of maintenance...

The community-originated software projects that reach a point of popularity and want to enter a consolidation phase, face then a hard problem:

• If the software is meant to stay as a gadget or a template, the lack of a centralized repository makes it very hard to maintain and improve, since every wiki has its own copy with its own version, language, and local hacks. Our architects know about this problem, but when it comes to plan quarterly goals, we basically keep pushing it forward T1238: Central Code Repository for code used on wikis (Templates, Lua modules, Gadgets)

• If the functionality is meant to become part of MediaWiki core or an existing / new extension, then we hit the problem of WMF teams busy on our own priorities, not dedicating much time for product review, design review, security review, and code review for projects that we are not starting and are not part of our committed plans. See https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment, T33235: [DO NOT USE] Extensions awaiting code review to be deployed on Wikimedia wikis (tracking) [superseded by #wikimedia-extension-review-queue], or http://korma.wmflabs.org/browser/gerrit_review_queue.html to get an idea about this problem.

Our team is in a good position to help discovering interesting community innovations, and helping them on basic improvements of quality, promotion, and definition of a long term plan. However, there is so much we can do if WMF Product and Technology doesn't provide a better infrastructure for community innovation (a centralized catalog to discover and host gadgets, templates, bots, tools is basically the required start), and a percentage of their resources to help productizing those innovations that need to "get into trunk" in order to flourish.

...

See also/especially T71445: Implement a sane code-review process for MediaWiki JS/CSS pages on Wikimedia sites wherein the developers are discussing a code-review system for gadgets
Plus T31272: Implement Gadgets 2.0

The other problem here, is that moving onwiki-tools into extensions/core, makes it a lot harder for most of the gadget/script/bot authors to actively help with it (because git/gerrit is more complicated than just editing a wikipage), and also for everyone (dev and non-dev) to keep track of changes (because then it is no longer built into their usual watchlist workflow).

Additionally, when a gadget is converted into an extension with an expectation of greater scaling/performance, it might need to be rewritten entirely, and possibly in a different language (eg. javascript into php). This further complicates the original authors participating. E.g. hotcat would basically need to be rewritten entirely, in order to be turned into an extension, according to one dev.