Drupal
Drupal is finally moving project issue management from the custom-built Drupal.org queue to GitLab issues. This is one of the biggest infrastructure shifts the project has made in years, and it was overdue.
The Shift: From Fields to Labels
The most visible change in the new workflow is how issue metadata is handled. On Drupal.org, we had fixed fields for Status, Priority, Category, and Version. In GitLab, these are replaced by a flexible, maintainer-controlled system of labels.
Mapping the Workflow
Migrated projects now use labels like Status: Active, Priority: Normal, or Category: Task. This gives maintainers more autonomy to define their own workflows while keeping a recognizable structure for the community.
- Drupal.org (Legacy)
- GitLab (New)
- Status: Dropdown (Active, Needs Work, RTBC, etc.)
- Priority: Dropdown (Critical, Normal, etc.)
- Tags: Free-text comma-separated
- Status: Label (
Status: Active,Status: Needs Work) - Priority: Label (
Priority: Normal,Priority: Critical) - Labels: Integrated GitLab label system
Why This Matters
- Issue Boards: Maintainers can now use GitLab's native Issue Boards to visualize their pipeline, dragging issues from "Needs Work" to "Needs Review."
- Unified Experience: Contributors no longer need to jump between a custom issue UI and the code hosting platform. Forks and Merge Requests (MRs) are now more tightly integrated.
- Extensibility: Because it's "just GitLab," projects can use external integrations, webhooks, and automation tools that were previously impossible with the custom Drupal.org system.
What I Learned
- Modernization is Iterative: The Drupal Association is rolling this out in phases. Some projects are opted-in, while others (including Core) still use the legacy queue.
- Labels are Powerful: Moving from rigid database fields to labels allows for more nuanced workflows without requiring custom code on the hosting platform.
- API-First Contribution: With issues now accessible via the standard GitLab API, building tools for the Drupal ecosystem just got a lot easier.
Why this matters for Drupal and WordPress
Drupal module maintainers now get native GitLab issue boards, merge request integration, and API access for automation — tools that WordPress plugin developers have had through GitHub/Trac workflows. For developers contributing to both ecosystems, the move to GitLab standardizes Drupal's contribution workflow on a platform they already know, lowering the barrier for WordPress developers who want to contribute Drupal patches or maintain cross-CMS modules. Agencies with teams spanning both platforms benefit from a unified DevOps toolchain where issue tracking, CI, and code review use the same GitLab primitives.
References
- Drupal.org: GitLab Issue Migration Documentation
- GitLab Issues Transition: FAQ for Maintainers
- Blog: Modernizing Drupal Contribution with GitLab
Looking for an Architect who doesn't just write code, but builds the AI systems that multiply your team's output? View my enterprise CMS case studies at victorjimenezdev.github.io or connect with me on LinkedIn.
