The m3api library (introductory blog post) should, for ideological reasons, migrate to Wikimedia GitLab sooner or later. (Or other Wikimedia hosting, but GitLab seems like the best option for now. I don’t think a Gerrit workflow makes sense for the library at the moment.) It seems sensible to do this now, before I create more extension packages that will then have to be migrated.

This will take some work, including but perhaps not limited to:

• Moving issue tracking from GitHub issues to Phabricator. This will require a Phabricator project for m3api, and that should probably be the first thing done, so that all other tasks for the migration (including this one) can be tracked appropriately. ⇒ T392291: Create project tag for m3api
  
  In general, having the issues on Phabricator will probably be nicer than on GitHub. It makes it easier to cross-reference other Wikimedia tasks, and it also could reduce the confusion related to issues that are related to more than one m3api package (such as m3api-oauth2#3, which affected m3api-oauth2 but had to be fixed by a code change in m3api; or m3api#9 and m3api#27, which were created in m3api but resulted in the creation of separate repositories) – though that will depend on some extent on how we manage projects / tags for individual m3api packages (because of how Phabricator handles subprojects).
  
  I don’t think it will be necessary to migrate already-closed tasks to Phabricator.

• Moving the source code to GitLab. I’ll probably request an m3api organization, so that the individual repositories can be e.g. m3api/m3api, m3api/m3api-oauth2 and so on, rather than living under the lucaswerkmeister/ namespace. (Or should it be repos/m3api/m3api etc.? I’m not sure.) The duplication of “m3api” in the organization and individual repos is a bit annoying, but I think I’d rather have that than e.g. m3api/core, m3api/oauth2 and so on. ⇒ T392323: Create new GitLab project group: m3api

• Recreating all the GitHub releases on GitLab. Just a bit of manual busywork. (Notably, GitLab releases let you set the release date, so it should be possible to reflect the original release date. Yay!)

• Migrating the regular CI. For most of the packages, this should be relatively straightforward. It’ll be somewhat annoying for m3api-oauth2 – I’ll have to build a GitLab CI version of my setup-mediawiki action (unless one already exists), to run CI against a wiki with an artificially lowered $wgOAuth2GrantExpirationInterval (compare T374562). ⇒ T402700: Migrate m3api CI from GitHub Actions to GitLab CI

• Migrating the release CI. Publishing to npm should be very straightforward. The documentation step will be more involved – see below. ⇒ T402700: Migrate m3api CI from GitHub Actions to GitLab CI (or possibly a separate task if needed, but I think it won’t be necessary)

• Moving the existing documentation to doc.wikimedia.org and updating the release CI to publish new documentation there. (See also this Mastodon thread for some discussion.) ⇒ T392716: Host m3api documentation on doc.wikimedia.org

• Get the GitLab repositories indexed by VPS-project-Codesearch. ⇒ T404517: Index m3api repositories in Codesearch