GitLab project configuration (labels, boards, approvals, notifications)

Goal

Configure this project's GitLab-native issue tracker per Drupal.org's "GitLab issues for Drupal.org projects" guidance. Most items are self-service (project maintainer). Checklist below.

Labels & metadata

  • Scoped-label taxonomy: category::, priority::, component::, state::, version, tags — one label per scope. (The real GDO issues already carry category::/priority::/component:: labels, so align with the existing set.)
  • Workflow-state labels: state::needsWork, state::needsReview, state::rtbc, state::needsReroll.
  • Milestones for release/version grouping.
  • Saved queries / filters for common team issue views.

Templates

  • Issue / description templates (bug / feature / task) — surface in the create-issue dropdown.
  • Merge-request template (if standardizing the MR procedure).

Boards & workflow

  • Configure issue board(s) — simple Open/Closed, or columns by scoped label (e.g. state::rtbc). Maintainer-configured.
  • Convention: always use the Issue work-item type (not Task/Incident) — documented in CONTRIBUTING.md (#3578751 (closed)).

Review & merge

  • MR approval rules — enforce the review / RTBC gate.
  • Grant merge access to core devs (drupal.org → Maintainers → "Write to VCS" → GitLab Developer). Model documented in #3578751 (closed).
  • Set default branch to 1.x — DONE (verified default_branch=1.x). Fixes Closes # auto-close (only fires on merges into the default branch).
  • Protect 1.x — DEFERRED (decided 2026-07-04). For now the fork→MR workflow is enforced by prompt/guidance — the CLAUDE.md/AGENTS.md guardrails from #3578751 (closed), trusting the agent to follow them. We are deliberately NOT applying a blanket hard lock now: push = No one would bind the maintainer too, and André wants to keep a fast maintainer path. - Future hard enforcement = the bot (Option C), not a blanket lock. A dedicated least-privilege bot identity (Developer-role project access token — verified enabled on this project) gets server-blocked from 1.x while the human maintainer keeps direct push. Needs DA approval — batched in the DA-requests bundle (Infrastructure project, tag gitlab api). - When the bot lands, set the Branch Rule (self-serve; Settings → Repository → Branch rules on 1.x): push = Maintainers, merge = maintainers, force-push = off — so the Developer-bot is blocked from trunk but the maintainer is not. (Self-serve via the UI; the REST API 301s.) - Optional accidental-direct-push CI guard allowlist: 1.x, {major}.x, {major}.{minor}.x, legacy 6.x-1.x / 7.x-1.x.
  • Correct docs/src/content/docs/gitlab-operations.md — the "Set protected branches / push rules" row wrongly says these need a drupal.org site admin (beyond a project maintainer). Reality: the API is blocked (301), but the Branch Rules UI is self-serve for a maintainer. Fix that row + the "What's blocked and why" note. (Folded into this issue — same discovery. Lands via fork → MR.)

Automation

  • Confirm DrupalBot quick commands: /do:fork, /do:access, /do:label, /do:assign (verify the exact set against the doc).
  • CI runs on drupal.org's runners — no change from classic (Pages job already added under #3578755 (closed)).

People & notifications

  • Assign roles: Planner (triage/labels directly in GitLab), Reporter (trusted triage assist).
  • Team sets GitLab notification preferences; share the email-filter headers (X-GitLab-Project, List-Id, X-GitLab-NotificationReason).
  • Optional: Slack notifications via the Drupal Slack workspace.

Credit & commits

  • Contribution records: review contributions and grant credit; use the generated commit message on merge.
  • Adopt Conventional Commits format (confirm the exact spec node on the doc).

Caveats

  • A few specifics (exact /do: command set, the Conventional-Commits node number) come from a doc-fetch summary and should be confirmed on the source page before relying on them; the categories are solid.
  • Overlap: the contribution workflow + merge-authority model are documented in #3578751 (closed) (CONTRIBUTING.md). This issue is the GitLab settings/metadata configuration, not the docs.

References

Edited by André Angelantoni