Contributing and the Drupal Community

This content was generated with the assistance of AI and should be verified against the official Drupal documentation before being relied on in production.

This sub-section’s Drupal bibliography lists the reference material consulted while preparing these pages.

Drupal is not only software: it is a project whose code, documentation, translations and events are produced by a community that works through one shared platform, drupal.org. This page explains how that platform is organised, how a site builder or developer takes a fix from "my site is broken" to "it is in a release", what the security advisory coverage opt-in means for a module you publish, how contribution credit works, and which organisations and events surround the project. It was checked on 2026-10-30 against Drupal 11.4.x, Drush 13 and 14, and PHP 8.3 or later.

The running example is the Meridian Museum. Its custom module meridian_collection started as private code. After a year the museum decides to publish it on drupal.org and, along the way, finds a bug in a contributed module that it fixes upstream instead of patching privately.

Who contributes and why

A contribution is anything that improves the project, not only code. The Contributor Guide organises the work by role, task, skill and area (documentation, core, event planning and others), and it lists tasks of a few minutes for newcomers. For a site builder the most useful contributions are a good bug report with steps to reproduce, a review that confirms a fix works, a documentation correction or a translation. For a developer they are merge requests against core or contributed projects, or a new contributed project.

Contributing is also a practical strategy. A fix kept in a private patch has to be re-applied and re-tested at every update (see Updates, Composer and Security Advisories); a fix merged upstream is maintained by everyone. The Contributor Guide has a "Getting Started Contributing" sequence and the Drupal mentoring team runs a first-time contributor workshop at each DrupalCon.

drupal.org projects

Everything that can be installed through Composer from drupal/* is a project on drupal.org: core, modules, themes, distributions, recipes, profiles and translations. Each project has:

a project page with description, releases, maintainers and usage statistics
an issue queue for bugs, tasks, feature requests and support requests
a Git repository on the Drupal GitLab instance, git.drupalcode.org
a machine name that is also the Composer package name, drupal/<machine_name>

There are two kinds of project. A sandbox project is an experimental repository that any user with a Git access account can create, with no review: it cannot make stable releases and is not covered by the security advisory policy. A full project has a short machine name, can publish releases and can opt in to security coverage (below). Sandbox projects are the right place for meridian_collection to live until its API settles.

Project releases follow semantic versioning with a core compatibility declaration in *.info.yml, as described in Module Anatomy and info.yml and Drupal Versions, Release Cycle and Support. Maintainers tag releases from branches (1.0.x, 1.1.x) and drupal.org builds the release node and Composer metadata from the tag. The core development branch is named main; the version filter of the queue shows main together with the branch groups 12., 11. and 10.*.

GitLab at git.drupalcode.org

Drupal uses GitLab as the web front end to Git. The Git hosting documentation covers, in order: an introduction, setting up Git and GitLab access, using Git to contribute, using GitLab to contribute (issue forks, merge requests, rebasing, reviewing, CI), Git for project maintainers (commit message format, release types, security releases, branch moves), the common development workflow, and branching strategies for several developers.

Authentication and policy points that cause most first-day errors:

A drupal.org password cannot be used for Git authentication. Add an SSH public key under "Git access" in your drupal.org account, or generate an HTTPS token there if SSH is not possible.
Only the person who opened a merge request (and possibly core committers) can resolve its discussion threads.
Third-party integrations are generally not allowed, with exceptions such as Slack and the CI integration.
An old Git client can fail on redirects or with "remote end hung up unexpectedly"; update Git first.
A REMOTE HOST IDENTIFICATION HAS CHANGED warning is fixed by removing the stale entry from ~/.ssh/known_hosts.
Old cgit "rawdiff" URLs return 404 and have no GitLab equivalent.

Problems with the infrastructure itself are reported in the Drupal.org infrastructure issue queue.

Issue queues

Every project’s issue queue is the single place where work is discussed and tracked. Each issue has a category (bug report, task, feature request, support request, plan), a priority (critical, major, normal, minor), a version (the branch the fix targets), a component (for core: a subsystem such as the forms system or layout_builder.module) and a status. The statuses form a workflow:

Status	Meaning
Active	Reported, nobody has a fix yet.
Needs work	A reviewer found a problem; the author must update the change.
Needs review	A change (a merge request) is ready for someone else to test.
Reviewed & tested by the community (RTBC)	A reviewer other than the author confirmed the change works and follows the standards. Maintainers or committers then act.
Fixed	Committed. That issue closes automatically after a period and credit is recorded.
Postponed, Postponed (maintainer needs more info)	Blocked on another issue or on missing information.
Closed (duplicate), Closed (won’t fix), Closed (works as designed), Closed (cannot reproduce), Closed (outdated)	Closed without a change.

Status

Meaning

Active

Reported, nobody has a fix yet.

Needs work

A reviewer found a problem; the author must update the change.

Needs review

A change (a merge request) is ready for someone else to test.

Reviewed & tested by the community (RTBC)

A reviewer other than the author confirmed the change works and follows the standards. Maintainers or committers then act.

Fixed

Committed. That issue closes automatically after a period and credit is recorded.

Postponed, Postponed (maintainer needs more info)

Blocked on another issue or on missing information.

Closed (duplicate), Closed (won’t fix), Closed (works as designed), Closed (cannot reproduce), Closed (outdated)

Closed without a change.

Good etiquette is documented on the docs page titled Issue Queue Etiquette: search for duplicates first, write the issue summary (problem, steps to reproduce, proposed resolution, remaining tasks) so that it stays current, keep comments factual, and never set your own change to RTBC. Issues tagged "Novice" are a curated list of beginner-friendly work. Support requests for a site like Meridian’s are usually better answered on community channels than in a project queue, which is meant for defects and development.

A security problem is never reported in the public queue. Reports go privately to the Drupal Security Team, which coordinates fixes and publishes security advisories (see the next sections).

Issue forks and merge requests

Since the move to GitLab, contributions to core and contributed projects are merge requests made from an issue fork. Patch files attached to issues are the older workflow; they are still downloadable from a merge request but new work should not be posted as patches. The flow is the same for every project.

flowchart LR A[Find or open a ticket] --> B[Create issue fork] B --> C[Get credentials and add remote] C --> D[Check out the ticket branch] D --> E[Commit and push] E --> F[Open merge request] F --> G{GitLab CI green?} G -- no --> D G -- yes --> H[Needs review] H --> I[Reviewers test and comment] I -- changes requested --> D I -- approved --> J[RTBC] J --> K[Maintainer merges and credits]

An issue fork is a branch namespace attached to this ticket, shared by everybody working on it, not a personal copy. The steps for the Meridian Museum fixing a bug in a contributed module, say a Views filter that ignores the on_display flag, are:

Open the ticket and use the Create issue fork button. It creates the fork at git.drupalcode.org/issue/<project>-<issue number>.
Use the shown Show commands snippet. It adds a remote named after the fork and fetches it.
Create or check out the branch (named <issue number>-<short-title>, targeting the version branch), edit, commit and push.
Use Create merge request in this ticket. Choose the target branch that matches this ticket’s version.

# Work inside the project checkout created by Composer or a normal clone
git clone git@git.drupalcode.org:project/meridian_collection.git
cd meridian_collection

# Commands shown by the "Show commands" button, for issue 3500001
git remote add meridian_collection-3500001 git@git.drupalcode.org:issue/meridian_collection-3500001.git
git fetch meridian_collection-3500001
git checkout -b 3500001-on-display-filter --track meridian_collection-3500001/3500001-on-display-filter

# ... fix, then commit with the project's message format
git commit -am "Issue #3500001: Respect the on_display flag in the object filter"
git push meridian_collection-3500001 HEAD

Source: Using GitLab to contribute

That issue number and the exact remote names above are illustrative; copy the real commands from the ticket page, because they contain your user-specific access. Commit messages for drupal.org projects start with Issue #NNNNNNN: followed by a summary; the Git for project maintainers page defines the format the maintainer uses when merging, including the credit line. After pushing, GitLab prints a link to create the merge request, or you can use the button in this ticket.

Keeping a merge request alive involves a few habits:

Rebase onto the target branch when it moves; the ticket page and the merge request show whether it is out of date. Because the fork is shared, push with --force-with-lease only when you coordinate in this ticket.
Resolve review threads only if you opened the request; reply otherwise.
Add tests: a bug fix should come with a test that fails without the change (the "test-only changes" pipeline job checks this). See Automated Testing.
Follow the coding standards, see Coding Standards and Static Analysis; the CI runs PHPCS and other linters for you.
When core and a contributed project both need a change, the Git docs describe using a ticket fork for core version compatibility fixes, so a single branch can carry the change for several core versions.

Using a merge request in a Composer site

Until a fix is released, the Meridian site can install the code from the merge request without a private patch. Composer reads the repository of the fork directly.

{
  "repositories": [
    {
      "type": "vcs",
      "url": "https://git.drupalcode.org/issue/meridian_collection-3500001.git"
    }
  ],
  "require": {
    "drupal/meridian_collection": "dev-3500001-on-display-filter"
  }
}

Source: Using GitLab to contribute

Remove the repository entry and return to a tagged release as soon as the fix ships; a dev branch has no security coverage and is not reproducible after the fork is cleaned up. The merge request page also offers a downloadable .diff patch, which is what Composer patch plugins consume. Prefer the VCS form for a short time and the patch form for a long-lived local patch, always with a link to this ticket in the patch description so that the next composer outdated review can drop it.

GitLab CI for contributed projects

Contributed projects run their tests on GitLab CI with shared templates maintained in the gitlab_templates project. The jobs are build jobs (Composer install, Drupal CMS, pages), validation jobs (composer-lint, cspell, eslint, phpcs, phpstan, secret detection, stylelint) and test jobs (nightwatch, phpunit, test-only changes and upgrade status). A project opts in with a .gitlab-ci.yml file in its root.

# .gitlab-ci.yml of meridian_collection
include:
  - remote: https://git.drupalcode.org/project/gitlab_templates/-/raw/default-ref/includes/include.drupalci.main.yml
  - remote: https://git.drupalcode.org/project/gitlab_templates/-/raw/default-ref/includes/include.drupalci.variables.yml
  - remote: https://git.drupalcode.org/project/gitlab_templates/-/raw/default-ref/includes/include.drupalci.hidden-variables.yml
  - remote: https://git.drupalcode.org/project/gitlab_templates/-/raw/default-ref/includes/include.drupalci.workflows.yml

Source: GitLab Templates: Set up

The remote form with the default-ref reference is the documented generic form; the Drupal instance may define the variables _GITLAB_TEMPLATES_REPO and _GITLAB_TEMPLATES_REF for you, in which case the .gitlab-ci.yml of a new project can be shorter. Check the Set up page for the form currently recommended, and the common tasks and variants pages to test against several core versions, PHP versions or databases.

Security coverage opt-in for contributed projects

Drupal publishes security advisories (SAs, identified like SA-CONTRIB-2026-0xx and SA-CORE-2026-0xx) only for core and for contributed projects that opted in to the security advisory coverage policy. For core, only the two most recent minor versions receive advisories. For a covered contributed project:

a grey shield and the note "Stable releases for this project are covered by the security advisory policy" appear on the project page
only stable releases of supported major branches are covered; dev, alpha, beta and release candidate versions are not
sandbox projects and projects hosted outside drupal.org are not covered
libraries a contributed module requires through Composer are not covered by the project’s SAs (libraries bundled with core are)
coverage does not depend on how many sites use the module

To opt in a project, a maintainer with write access must have applied for and received the vetted role (a review of the way the person writes secure code), the project must be a full project (not a sandbox), and it must have no known security issues and no open issues tagged "security". A new project waits ten days before opting in; the Security Team can grant exceptions rarely, for example for code copied from a covered project. Projects created before March 2017 were opted in automatically. After the opt-in a maintainer releases a stable version (1.0.0) and the project page shows the shield.

For the Meridian Museum this means the order is: sandbox, vetted role, promotion to a full project with the machine name meridian_collection, ten-day wait, opt-in, first stable release. Every site that requires the module then receives its advisories through composer audit, Drush and the status report, as described in Updates, Composer and Security Advisories. Consumers should look at the shield before depending on a module in production: an uncovered module is not reviewed and its vulnerabilities are not announced centrally.

Source: Security advisory policy

Security releases of core are scheduled for the third Wednesday of the month, as explained in Drupal Versions, Release Cycle and Support. Contributed security releases are announced at the time the maintainer and the Security Team agree. Never discuss a suspected vulnerability in a public issue, a merge request or a Slack channel: report it privately to the Security Team using the process described in the security team documentation, and wait for the advisory.

Credit system

Drupal gives credit to the people and organisations that help resolve a ticket. Credit appears on this ticket and in the commit message (the maintainer’s credit line), and organisations and customers can be attributed alongside the individual. Core committers decide credit by reviewing the activity on each issue. Credit is typically given for useful reports, patches and merge requests that move this ticket forward, resolving merge conflicts, substantial issue summary updates, thoughtful triage, mentoring, screenshots that illustrate a change, documented manual testing, design, usability and accessibility work, and non-trivial code review.

Credit is usually withheld for repeating earlier work, unchanged forks or merge requests, boilerplate approvals such as "Setting RTBC", unhelpful or unrelated comments, duplicate patches and screenshots that show nothing user-facing. Generated comments or code get no credit unless the use of AI is stated and the contributor has reviewed and tested the work locally. The policy assumes good intentions, and committers may correct credit after a commit. To dispute credit, first read the guidelines and then contact the committer who made the commit. Abuse of the credit system violates the marketplace code of conduct.

Practically: write what you did in this ticket, because committers read comments, not diffs. Document a conflict resolution with the diff in a code tag, and list the participants and the outcome when a priority changed or a discussion happened off-issue. The Meridian Museum, as a sponsor of the fix, is attributed as an organisation, which is how employers and customers get visibility for paid contribution time.

Source: Core contribution credit policy

The Drupal Association and the community

The Drupal Association is the non-profit organisation that accelerates Drupal and grows its community. It administers drupal.org (the infrastructure, the queues, the GitLab instance and the security team’s tooling) on behalf of the community and supports the project’s goal of a safe, secure and open web. Individuals can join as individual members or donate; organisations can become sustaining members or certified partners, sponsor events or advertise.

The Association is distinct from the Drupal project’s governance: core is directed by the core committers and initiative leads, and each contributed project by its maintainers. Funding from the Association pays for infrastructure, security and events; code remains community work.

DrupalCon and other events

DrupalCon is the main conference of the community. The events page counts 32 events since 2005 with roughly 3,000 attendees and 165 sessions on average. The upcoming events listed on 2026-10-30 are DrupalCon Orlando (22-25 March 2027) and DrupalCon Edinburgh (25-28 October 2027); no 2026 event is listed. A DrupalCon has keynotes and sessions for leaders, developers and end users, summits and trainings, networking and Birds of a Feather gatherings, and a Contribution Day where experienced contributors help newcomers work on real issues, usually starting with the first-time contributor workshop. Local meetups, camps and the global community channels complement the conference.

A newcomer’s plan for the Meridian developers: attend the workshop, pick a "Novice" issue, create a ticket fork, push the first merge request during Contribution Day, and get credit on the commit.

Common errors and pitfalls

Pushing to a personal fork: work belongs in the shared issue fork created from the ticket page.
Using a drupal.org password for Git: authentication requires an SSH key or an HTTPS token.
Posting patches instead of merge requests: patches are legacy, and merge requests run CI and track review.
Setting your own change to RTBC or opening an RTBC without testing, which costs credit and trust.
Depending on dev-* branches or uncovered projects in production: no advisories and no reproducibility.
Reporting a security issue in a public queue: use the private Security Team process.
Forgetting the version: a fix against the wrong branch is not mergeable and needs a retarget.
Opting in too early: a project with open "security"-tagged issues cannot be opted in.

Version notes and older material

Older books such as Drupal 10 Development Cookbook (2023) and Drupal 10 Masterclass (2023) describe contribution as it was before the full move to issue forks, with patch files attached to issues and rerolled by hand; today the merge request is the unit of work and patches are generated from it. The Masterclass lists Drupal 7 as still supported and Drupal 11 as a future release; Drupal 7 has ended its support and Drupal 10 itself ends on 2026-12-09, with Drupal 12.0.0 scheduled for the week of 2026-12-07 (scheduled, not past). Core development happens on main, and the Drupal Association and DrupalCon information above comes from the current official pages, not from those books.