An off-wiki code repository such as GitHub can be a big efficiency for software engineers. But it also comes with increased overhead. Here are the pros and cons as I see them.
- For small gadgets with no activity, stay on wiki. Not worth the overhead of moving off-wiki
- For big gadgets with multiple developers, needing automated tests, automated linting, etc, use GitHub for both issue tracking and pull requests.
- The advantage of keeping the issue tracker and pull requests under the same roof is significant. Cross-linking, auto-closing tickets, etc.
- split a big gadget file into individual files (to be recompiled later)
- linter
- test suite
- continuous integration
- issue tracker
- pull requests
- Code review is easier. There is a system to leave comments regarding specific lines, mark them as resolved, etc.
- Edit conflicts / rebase issues are handled more easily on an offsite repo. If using a wiki talk page to handle pull requests, and multiple people submit edit requests at once, it can be tricky to make sure changes don't get overwritten.
- Git Blame - see who last touched a line of code
- clearer who authored each patch, from a copyright and attribution perspective
- Spinning up a test environment may require a custom script.
- Examples of custom scripts: Twinkle (Node.js). AFC helper script (Node.js).
- Deploying requires a custom script. Cannot be easily integrated into CI because all the GitHub Actions IPs are blocked as open proxies.
- Examples of custom scripts: Twinkle (Perl). AFC helper script (Python). Novem Linguae user scripts (PHP). Everybody seems to write their own, in different back end languages, and then they rot. Should probably try to standardize these.
- Danger of the off site repo getting out of sync with the onwiki code.
- Less visibility. Can't put the repo on a wiki watchlist. Pull requests more likely to sit without getting reviews.
- Non-developers rarely use issue trackers. They make all their posts to the talk page. So a developer has to transcribe them to the issue tracker, creating double work.
- WMF devs, intadmins, and global intadmins that do mass refactoring of user scripts and gadgets will no longer be able to do this, since all code changes need to go through the offsite repo.
-
https://github.com/wikimedia-gadgets is a good fit for popular and complex enwiki gadgets.
- It currently has 15 "Members" that are able to +2 on any wikimedia-gadgets repo.
- Folks that work on a specific gadget frequently can be added as a "Contributor".
- Repos include AFC helper script, Twinkle, MoreMenu, shortdesc-helper, JWB, RedWarn, and XFDcloser.
- Random open source devs are likely to be familiar with GitHub and GitHub Actions (CI)
- https://gitlab.wikimedia.org/repos/gadgets now also exists
-
https://gerrit.wikimedia.org/r/dashboard/self is not really recommended for user scripts and gadgets. Wikimedia Gerrit is a better fit for MediaWiki core, extensions, and skins.
- Benefits of gerrit is you can chain patches together, and the attention flag.
- Drawbacks of gerrit include terrible email settings, difficult to configure CI, and big learning curve for non-wikimedia devs.
- Phabricator
This also has pros and cons.
- Pros of Phabricator
- Single sign on. Wikipedia folks do not need to create a new account.
- Phabricator kanban workboards have more features than GitHub Project Boards
- Pros of GitHub Issues
- Can easily link issues to pull requests. So for example, merging a PR will close the corresponding issue.
- Gerrit - gerritbot
- GitLab - CodeReviewBot
- GitHub - github-toolforge-bot
- Wikipedia:Wiki-to-Git can be used to do the initial commits in the repo, preserving some of the history.