Drupal Projects Adopting GitLab Issues: How the New Workflow Works

In the article, Fran Garcia explains that several projects that opted into GitLab issues are now operating under the new system, providing real-world experience that is shaping ongoing improvements. Additional projects are being migrated each week, making familiarity with the new workflow increasingly important for contributors and maintainers.

The post outlines the simplified process for creating new issues in GitLab. Contributors need only provide a title and description when opening an issue. While GitLab supports multiple work item types, such as “Incidents” and “Tasks,” Drupal.org integrations will standardise on the “Issue” type for consistency across projects.

Issue metadata, including priority and categorisation, is managed through labels rather than structured form fields. Maintainers apply these labels after issue creation. Contributors without sufficient privileges cannot assign metadata unless granted the “Reporter” role, which allows limited label management. Garcia notes that this represents a significant shift from the traditional Drupal.org workflow and that feedback from opted-in projects is guiding refinements.

The article highlights conventions previously used in Drupal’s contribution model, such as “Needs Work” (NW), “Needs Review” (NR), and “Reviewed & Tested by the Community” (RTBC). Since GitLab does not natively replicate these statuses, maintainers are encouraged to use existing GitLab features to approximate them. Draft versus Ready states in merge requests can reflect NW versus NR, while merge request approvals can serve as an equivalent to RTBC. GitLab’s filtering capabilities allow maintainers to review merge requests by draft status or approval state.

Automated system messages now provide contributors with links related to fork management, access requests, and contribution credit tracking. The post also clarifies how crosslinking works between Drupal.org and GitLab issues. References within Drupal.org may continue using the [#123] syntax, while GitLab references use #123 without brackets. Cross-platform references require full URLs.

Next phase of migration

Garcia explains that the next phase of the migration will focus on low-usage projects and those with smaller issue queues. This batch approach is expected to cover approximately 80 percent of projects before moving on to higher-volume repositories.

As more projects adopt GitLab issues, contributors and maintainers will need to adjust to label-based metadata management and merge-request-driven review conventions in place of the legacy Drupal.org workflow.