As we mentioned in our last blog post GitLab issue migration: immediate changes, we will continue to migrate more and more projects.
We gathered a list of projects where their maintainers agreed to help us test the migration process at #3409678: Opt-in GitLab issues. What does it mean if your project is being migrated or if you are collaborating in one of those migrated projects?
Changes to issue management
If your project has been migrated to GitLab, you will now manage all your issues via GitLab issue listing and/or issue boards. As maintainers, you will be able to set up issue boards to follow the workflow that makes the most sense for your project. Some projects might just have "Open" and "Closed" columns (default setup), some projects might want to add a "RTBC" column based on the existing "state::rtbc" label, some projects might want to define more complex issue transitions. This is something similar to what we did on the transition to GitLab CI, where we provide defaults for all projects, but then each maintainer can configure their own ways of managing their issues.
As with other open source projects, only maintainers will be able to configure the issue boards, set labels for the issues or even change issue status. This is a big workflow change from what we have now, but it aligns with how many other projects are managed.
All labels (tags, version, priority, etc) are now project-specific, giving maintainers full freedom to choose the ones that make the most sense for their projects.
Fork management
Whilst using GitLab issues brings us closer to workflows in other communities, our forking model remains the same as it was until now, which is collaborative by default. We believe that this is the easiest way to work together as a community.
This means that we will not have personal forks (we never have), and we will continue having shared forks (we always have). GitLab does not support this forking model out of the box, so we needed to implement this capability in the new system. As we did so, we used the opportunity to simplify the process compared to that of Drupal.org issues.
We will have a new place to create forks and request access, which will be a new tab available when viewing the contribution record for the issue. This new tab will read 100% of its information from GitLab via Ajax. You can do the same things as you can now on Drupal.org issues: create forks and request access. You can even do some of these things from the issue page (more about this below).
Actions like creating branches or merge requests will be just links to GitLab, as that's something that can already be done there.
Automated messages
We understand that the above includes a new step in the workflow, which we had before within the issue page. In order to make the workflow easier, we are adding automated messages to issues that will take you back and forth between the pages, that will inform about forks created, etc.
What's not changing?
The contribution records system that we deployed a few months ago will not change, it will remain exactly the same as it is today. You will have links to go back and forth between the issues and their contribution record, the same way as you have right now with Drupal.org issues.
What's next?
The roadmap remains unchanged, and still is (in each iteration, we will address feedback, fix bugs...):
- Migrate projects that opted in (we are here now)
- Make this the default for new projects
- Migrate low-risk, low-usage, and/or sandbox projects
- Migrate remaining projects, excluding a few selected high-volume, high-risk
- Migrate the rest of the projects, including core