This is the fourth post in our GitLab issue migration series. The earlier posts focused on what is changing and how maintainers should set up their projects. This one is for the rest of us — the people who file bugs, review code, push fixes, and triage queues without wearing a maintainer hat. If your favorite contrib project has just moved its issues to git.drupalcode.org, here's what you need to know.
What's changed at a glance
When a project's issues are migrated, they move from www.drupal.org/project/{name}/issues to git.drupalcode.org/project/{name}/-/work_items. Old URLs redirect to the new ones, and issue numbers (NIDs) are preserved as GitLab IIDs — so an #3409678: Opt-in GitLab issues you find in a commit message will still resolve to the same issue.
In GitLab, "issues" are technically a subtype of "work items," but the term issue still applies, and you'll see it throughout the UI. If you've worked on any GitHub or GitLab project before, the experience will feel familiar.
What still works the way you're used to
A lot has not changed:
- You can still create issues without any special role.
- The contribution credit system is unchanged. Every comment you make on a GitLab issue still syncs to its contribution record automatically. The credit UI itself still lives on drupal.org.
- Shared issue forks are still the way to collaborate (on code). Drupal still doesn't use personal forks; collaboration on a single fork remains the model. The fork management UI also still lives on drupal.org.
- The familiar workflow conventions can still apply — Needs work, Needs review, RTBC, priority levels, and so on. They were migrated as scoped labels (more on this below).
- GitLab CI still runs your tests the same way it has for the past few years.
- Your Drupal.org login still works. Single sign-on means no extra account to manage.
- Cross-references and parent/child relationships still exist, just with slightly different syntax (more on that below).
Some things actually got better
It's worth naming a few real wins for contributors:
- A modern issue editor with proper markdown, real code blocks, syntax highlighting, image paste, and a mobile-friendly UI.
- Issues and merge requests now live alongside the code, pipelines, and CI logs on git.drupalcode.org — far less context-switching during code review.
- Much better filtering, search, and saved queries on issue lists.
- Issue boards (Kanban-style) are available for projects that want them.
Who can edit what
A few permission details are worth knowing up front, because they're tighter than what you may be used to on the old issue queue:
- Anyone can comment on an issue.
- Only the original author or project maintainers can edit the issue description. This is a real change — on drupal.org, any logged-in user could edit an issue summary. If you'd like a description updated and you're not the author, leave a comment with the suggested wording so the author or a maintainer can apply it.
- Labels and other metadata (priority, version, category, component, tags) can only be edited by users with a Planner role or higher on the GitLab project.
That last point is real friction for contributors who triage and label issues, and we're addressing it directly. #3559846: Allow changing GitLab issues labels for all contributors is building a label-management UI that will live on drupal.org, alongside the existing contribution credit and issue fork management screens. Once it ships, any contributor will be able to manage labels on any issue without needing a project role on GitLab. This is also an upstream issue, but it doesn't seem to be worked on.
Until then, if metadata needs updating, leave a comment noting what should change. Maintainers and other contributors with the role can apply it.
Old workflow conventions can still apply
Good news for anyone with muscle memory for Drupal's NW / NR / RTBC dance: the conventions weren't dropped in the migration. They were preserved as scoped labels on GitLab issues — state::rtbc, the equivalent state labels for needs-work and needs-review, priority labels, and so on. Each project's setup may vary, but the familiar conventions carried over, and contributors can keep using them.
| Convention | Now |
|---|---|
| Needs work | state::needsWork label (alternative: MR set to Draft) |
| Needs review | state::needsReview label (alternative: MR set to Ready) |
| RTBC | state::rtbc label (alternative: MR approval) |
| Needs reroll | Push a rebase to the issue fork branch |
Two notes:
- Applying these labels yourself currently requires the Planner+ role on the project, until #3559846 ships the contributor label UI. In the meantime, a comment indicating the status you'd assign is the right move.
- Merge request states are a useful parallel signal: an MR's Draft / Ready toggle and approval status reflect the actual code change being reviewed, which often communicates more clearly than a label on the parent issue. Some projects lean heavily on MR state, some on labels, some use both — there's no single right answer.
Day-to-day: how to do common things
Create an issue
Navigate to the project, click Issues in the left sidebar, then New issue. The form is just a title and description; labels and metadata are added afterwards by users with the appropriate role. If a project has set up issue templates (markdown files in the repo), you'll see them in a dropdown.
The first auto-generated comment
The first comment on every new issue is posted by DrupalBot. It's the bridge to the things that still live on drupal.org:
- A link to the contribution record (where credit is tracked).
- A link to the fork management page, where you can create or request access to a shared fork, view existing MRs, and open a new one.
- Once #3559846 ships, a link to the contributor label management UI.
Forks and merge requests
The fork management screen on drupal.org works the same way for GitLab issues as it has for Drupal.org issues. From there, you can create a shared issue fork, request access if one already exists, push a branch, and open an MR. Branching and merging happen in GitLab's native UI, where they're already optimized.
Linking issues across systems
During the transition, contributors will be working with both Drupal.org issues and GitLab issues, sometimes in the same comment. The syntax differs by direction:
- Drupal.org → Drupal.org issue Brackets around the issue number (without spaces):
[ #123456 ](unchanged) - GitLab → GitLab issue (same project):
#123456(no brackets) - Cross-platform (either direction): paste the full URL
For "related issues" entries on Drupal.org, always use the full URL when pointing at a GitLab issue.
Things you might notice on migrated issues
A few oddities are worth flagging if you're working through historical issues:
- DrupalBot is listed as the author on every migrated issue. (Issues created after migration correctly show their actual creator.) The GitLab API forced a tradeoff between preserving the original author and preserving the issue ID. We chose to preserve the ID so that
#123456still maps to the same issue. The original author's name is preserved in the first line of the issue description. - Old drupal.org issue URLs redirect to their GitLab equivalents, so existing links in commit messages, blog posts, and external references continue to work.
Reporting bugs and getting help
Found a bug in the migration itself or in the integration between Drupal.org and GitLab? Please file it in the Drupal.org customizations issue queue.
Have a question, or want to share feedback on the new workflow? Join the #gitlab-issues-feedback channel on the Drupal community Slack.
We're actively iterating on this transition based on what we hear from contributors and maintainers in opted-in projects. The more feedback we get now — while we're still in the opt-in phase — the better the experience will be when the rest of contrib gets batch-migrated.
Reference: GitLab documentation
For more detail on any of the GitLab features mentioned in this post, the official GitLab documentation is the canonical source.
Issues and work items
Labels and permissions
Merge requests
Markdown
Related blog posts in this series:
- GitLab issue migration: immediate changes
- GitLab issue migration: the new workflow for migrated projects
- GitLab issue migration: how to use the new workflow
- GitLab issue migration: a contributor's perspective (this one)
Related issues
- Opt-in your project for migration to GitLab Issues. Eventually, all projects will be migrated.
- Provide feedback on the GitLab issue migration.
- General issue for the GitLab migration.
* We used Claude AI to refine our first draft and help link related materials like the GitLab documentation.