Now that some of the projects that opted-in for GitLab issues are using them, they are getting real world experience with how the issue workflow in GitLab is slightly different. More and more projects are being migrated each week so sooner or later you will probably run into the following situations.
Creating new issues
When creating issues, the form is very simple. Add a title and a description and save, that's it!
GitLab has different work items when working on projects, like "Incidents", "Tasks" and "Issues". Our matching type will always be "Issue". Maintainers might choose to use the other types, but all integrations with Drupal.org will be made against "Issue" items.
Labels (issue metadata)
As mentioned in the previous blog post GitLab issue migration: the new workflow for migrated projects, all the metadata for issues is managed via labels. Maintainers will select the labels once the issue is created.
Users without sufficient privileges cannot decide things like priority or tags to use. Maintainers can decide to grant the role "reporter" to some users to help with this metadata for the issues. Reporters will be able to add/edit metadata when adding or editing issues. We acknowledge that this is probably the biggest difference to working with Drupal.org issues. We are listening to feedback and trying to identify the real needs first (thanks to the projects that opted in), before implementing anything permanent.
Reporters will be able to add or edit labels on issue creation or edit:
So far, we have identified the biggest missing piece, the ability to mark an issue as RTBC. Bouncing between "Needs work" or "Needs review" tends to happen organically via comments among the participating contributors in the issue, but RTBC is probably what some maintainers look for to get an issue merged.
The previous are conventions that we agreed on as a community a while back. RTBC is one, NW (Needs Work) vs NR (Needs Review) is another one, so we could use this transition to GitLab issues to define the equivalent ones.
GitLab merge requests offer several choices that we could easily leverage.
- Draft vs ready could mimic "Needs work" vs "Needs review". Contributors will switch this back and forth depending on the feedback needed on the code.
- Merge request approvals could mimic "RTBC". This is something that can even be required (number of approvals or approval rules) per project, depending on the maintainer's preferences.
We encourage maintainers to look at the merge requests listing instead (like this one). Both "draft" vs. "ready" and "approved" are features you can filter by when viewing merge requests for a project.
Automated messages
There are automated messages when opening or closing issues that provide links related to fork management, fork information, and access request when creating forks, and reminders to update the contribution record links to the issue to track credit information.
Crosslinking between Drupal.org issues and GitLab issues
When referring to a Drupal.org issue from another Drupal.org issue, you can continue to use the [#123] syntax in the summary and comments, but enter the full URL in the "related issues" entry box.
When referring to a GitLab issue from another GitLab issue, use the #123 syntax, without the enclosing [ ].
For cross-platform references (Drupal to GitLab or GitLab to Drupal), you need to use the full URL.
What's next
Same as before, we want to go and review more of the already opted-in projects, collect feedback, act on it when needed, and then we will start to batch-migrate the next set: low-usage projects, projects with a low number of issues, etc.
The above should get us 80% of the way regarding the total number of projects to migrate, and once we have gathered more feedback and iterated over it, we'll be ready to target higher-volume, higher-usage projects.
Related blog posts: