Issue Labels & Workflow
Drupal.org tracks all issue metadata — type, priority, component, and workflow status — with scoped GitLab labels. This replaces the classic issue “Status” dropdown, and it is not the same as GitLab’s own native Status field (see below). This page explains the model and how to set them.
One label per scope
Section titled “One label per scope”A scope is the prefix before ::. An issue carries at most one label per scope, and
scoped labels enforce it — adding a new label in a scope automatically removes the previous one.
The four scopes we use:
| Scope | Answers | Values |
|---|---|---|
category:: | what kind of issue | bug, feature, task, support, plan |
priority:: | how urgent | critical, major, normal, minor |
component:: | which part of the project | code, documentation, … |
state:: | where it is in the workflow | accepted, needsWork, needsReview, rtbc, postponed, toBePorted |
Non-scoped free-form tags may also be added; those are not limited to one.
state:: is the workflow status
Section titled “state:: is the workflow status”The old Drupal.org Status field (Active, Needs work, Needs review, RTBC, …) migrated into the
state:: label. You move an issue through the workflow by changing its state:: label:
| Old Drupal status | state:: label |
|---|---|
| Active / accepted | state::accepted |
| Needs work | state::needsWork |
| Needs review | state::needsReview |
| Reviewed & tested (RTBC) | state::rtbc |
| Postponed | state::postponed |
| Patch to be ported | state::toBePorted |
| Fixed | close the issue (usually on MR merge) |
There is no state::inProgress — the “actively being worked” state is state::accepted.
Not the native GitLab Status field
Section titled “Not the native GitLab Status field”GitLab also exposes a native Status field (Triage / In Progress / Done). We do not use it as
the source of truth. Drupal.org’s tooling — DrupalBot, the project dashboards, and the
label-management page — all read the state:: label, not the native field. Setting the native
Status has no effect on Drupal-side workflow, so to avoid two statuses drifting apart, treat
state:: as the status of record and leave the native field alone.
The merge request is a parallel signal
Section titled “The merge request is a parallel signal”For issues with code, the MR’s own state often communicates progress more clearly than a label:
- Draft MR ≈ needs work
- Ready MR ≈ needs review
- Approved MR ≈ RTBC
Keep the state:: label and the MR state roughly in sync; for reviewers, the MR state is usually
the more reliable signal.
Who can set labels, and how
Section titled “Who can set labels, and how”- Planner role or higher can add or change labels directly in the GitLab UI (project maintainers have this).
- Anyone else can set them without a GitLab role via:
- the DrupalBot comment commands
/do:label,/do:unlabel,/do:relabel, or - the Labels management page on drupal.org, linked from DrupalBot’s automated comment on every issue.
- the DrupalBot comment commands
- Maintainers can grant the Reporter role to trusted contributors so they can edit metadata.
Boards
Section titled “Boards”Maintainers can build Kanban issue boards with columns keyed on scoped labels (for example a
state::needsReview column and a state::rtbc column) to visualize the workflow.
Reference: GitLab issues for Drupal.org projects, Drupal.org issues to GitLab issues cheatsheet.
Groups Initiative — Rebuilding Drupal's community Groups platform on Modern Drupal.