User:Novem Linguae/Essays/Pros and cons of moving a gadget to a repo

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.

Recommendation

 * 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.

Pros

 * 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

Cons

 * 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.

Has issue tracker AND pull requests

 * 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)

Has pull requests only

 * https://gitlab.wikimedia.org/repos/gadgets now also exists
 * 7 members
 * 0 repos
 * Per policy, the issue tracker should not be here. It should be on Phabricator instead, and GitLab only used for pull requests.
 * Has a unique CI language that is different than GitHub Actions
 * 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.

Has issue tracker only

 * Phabricator

If using GitHub for patches, should we use Phabricator for issue tracking?
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.

Bots that post pull request activity on Phabricator

 * Gerrit - gerritbot
 * GitLab - CodeReviewBot
 * GitHub - github-toolforge-bot