On the topic of migrating the main 'CRM' project to Gitlab vs Github:
One of the main advantages of Github is that "everyone has an account", so it makes small contributions easier.
Using Github would mean that most development-related activity would be in the same space. However, it builds a strong barrier between what is "CiviCRM core" (and core extensions) and other projects (which would be scattered in other Github accounts). It also does not allow the structure to grow organically, since only a handful of people can administer the Github account.
Compared to the current JIRA workflow, Gitlab does not simplify the process by much, but does not complicate it either. Until now, many considered that using JIRA was an acceptable trade-off because it provided better issue management.
Having one big monolithic project on Github will make it very hard to triage issues. Only people with write permissions to the repo can add labels to issues. We would have to develop more bot features to simplify triage.
One proposed compromise would be to allow opening pull-requests on Github without an issue. This way we keep the barrier to entry very low for drive-by contributors. However, we would be very strict about the PR description and commit message, and we would still encourage people to open issues before spending time writing patches.
Github does not allow importing the comment history while keeping the author intact. i.e. all comments will be imported as the same user.
By controlling registration (on civicrm.org), we can keep Community Profiles and better engage with the community/developers.
Gitlab is Free Software (although Open Core, where its business model is backed by en enterprise version, but they are also very supportive of FOSS projects using Gitlab). JIRA and Github are proprietary. This goes in contraction with CiviCRM's argument that "you own your CRM/data".
Gitlab could be useful for extensions:
Vendor-neutral dev spaces (shops could still promote their consulting/support services, like they do on drupal.org, but it would not be in the canonical URL of the git repo).
Gitlab templates could potentially run civix automatically? hook into gitlab's c-i to run tests? (instead of Jenkins)
Overall, we want to consider technical and political issues. The overall with the aim is to grow the community and lower the barriers between bug reporters, developers and other community spaces (such as website, marketing/civicamps, etc).
Add the users to the destination project (preferably as 'admins' to avoid permission problems).
Users whose username has changed must be remapped.
For infra, we mapped only a few and assigned the rest to the 'legacy' user, since few issues and archives aren't really important.
The 'legacy' user is an account that was created by bgm. It should be blocked after the migration.
issue status (i.e. all issues are left open)
issue relationships (ex: "duplicates [...]" and sub-tasks)
priority, resolution, fix-version, component, label, type (bug/feature/etc)
issues created/commented by the 'legacy' user did not have the correct creation_date? ex: #660 (closed)
"security level" is ignored (!)
github bot (botdylan) cannot link issues cross-repo: "about migrating INFRA-* -- in the past, working on an infra issue might require changes in variuos repos (e.g. civicrm-core's distmaker; or civicrm-buildkit's releaser; or civicrm-infra docs; or civicrm.org website). It was nice that the bot would add links to the ticket, regardless of where the change was made."