As noted in T355150#9983278 and T355150#10005318 and seen in comments in the task, we can improve the documentation on mediawiki.org to clarify expectations up front for volunteer developers about the process and requirements for deploying an extension to WMF production.
In particular, we need to make it more understandable when/why volunteer written and maintained extensions can be deployed to production.
@Novem_Linguae has already started on this with https://www.mediawiki.org/w/index.php?title=Writing_an_extension_for_deployment&diff=prev&oldid=6846281.
In T355150: Application Security Review Request : Adiutor MediaWiki extension case, another problem is the proposed for deployment extension has much function overlap with an existing (though not feature complete and only passively maintained) extension (PageTriage). If a user propose something be deployed to Wikimedia production, we at least need to discuss whether this is the best solution for the usecase.
Or nor. This hostility is part of the problem. Why does it matter if some wikis install Auditor and others install PageTriage?
The WMF needs to stop stifling volunteers' innovation with arbitrary and hypocritical rules. Refusing to install Auditor because it's 'redundant' is another instance of the same phenomenon.
Why does it matter if some wikis install Auditor and others install PageTriage?
Multiple extension is more difficult to maintain than one, so ideally we should have only one extension encompassing both functionality. You can imagine (in extreme case) when 10 wikis installed 10 different PageTriage-like extensions.
And the people who suffer the consequences from that situation are the wikis using the extension(s). So no need to antagonize everyone by cutting them off at the gate, rather than letting those consequences manifest.
My ideal vision is for each community should be able to elect its own sysadmins, with all the consequences that entails. I'm aware that vision is nowhere near practical with the current Wikimedia infrastructure, however, and will never be done.
A lot of power and flexibility is offered for user-developed tools via ext:Gadgets and toolforge/wmcs. In most cases, those environments should likely be preferred unless they are completely unacceptable for some reason (which would be a high bar IMO). The WMF does currently have an internal working group devoted to code ownership/maintenance (in the context of Wikimedia-deployed code) but it's a very difficult problem to address and solve. We want to enable volunteers as much as possible, but are also limited by how much security and legal risk is acceptable for the WMF to absorb, since they are the primary entity that must absorb said risks.
Removing Wikimedia-Developer-Portal as that project only links to on-wiki content. The documentation that is proposed for updating is https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment.
Sadly, Gadget extension, while widely used, is unmanaged by any WMF teams for 10 years, and the current design of Gadget is not great either: T31272: Implement Gadgets 2.0
For Toolforge, I will file a new task to describe a new proposed paradigm so user can develop tools more easily.
I think the above diff I added is helpful and solves the main goal of this ticket: letting a developer know early on in the extension writing process that it is mandatory to partner with a WMF team to get an extension deployed to WMF production.
Are there any other actionables? Should the ticket be marked resolved?
IMO, that edit captures the most important piece for now. I know there is still debate as to what this might look like going forward, but I think this is a reasonable first step in the absence of any other workable suggestions.