- T71445: Implement a proper code-review process for MediaWiki JS/CSS pages on Wikimedia sites: there is no code review process, which is both a security nightmare and a barrier to creating maintainer communities around scripts. Also no good way to test code changes before applying them.
- T121470: Central Global Repository for Templates, Lua modules, and Gadgets: there is no good way of sharing the same resources between multiple sites (or, in the case of long-tail scripts that are not popular enough to become site scripts or gadgets, sharing between multiple users) - resulting in either outdated copies or performance-degrading sharing methods.
Moving the code to some external version control platform should be a good solution for some of these issues and at least a foundation for a good solution for the rest:
- code sharing would be trivial and easy to track
- many public code repositories (most notably Github) also serve as development platforms and provide excellent code review and continuous integration support (and issue management and various other things)
- while testing/debugging support would still have to be implemented on the MediaWiki side, pull requests / feature branches at least provide a sane basis for it (as opposed to the current state of the art for code review, which is pasting suggested changes to the talk page)
(frwiki is already working on moving their gadget code to git and might be interested in this. The 2018 Montpellier pre-hackathon also has a related theme.)
- Provide a configuration setting to associate a wiki with a list of repository providers.
- Provide a web configuration interface for associating wiki pages (MediaWiki:*.js/css/json, maybe User:*.js/css/json) with files in a git repository (on some specified branch/tag).
- Lock those pages from editing.
- Modify the appearance of these pages to give some hint of what's going on.
- Provide some kind of form for updating the pages associated to a certain repository to the latest version. This would work much like a normal edit (appear in recent changes etc.) so monitoring such code with the usual set of wiki tools would still be possible.
- Optionally, provide a webhook for listening to updates; when the code is updated in git, notify the maintainers (how would they be identified though)? Or even update automatically, although that might be a bad security-convenience tradeoff.
- Provide some TemplateSandbox-like tool to override which branch the files are loaded from (for the purposes of testing pull requests). gerrit 340768 will make this fairly easy.
- Probably provide some sort of monitoring/reporting so that security engineers can get an easy overview of what repos to watch.