How to contribute

GitLab accepts both internal (GitLab employee) and community contributions. This section covers the practical mechanics — how to pick up work, the merge request process, and what reviewers will look for.

For broader contributor onboarding, see the official contribution docs.

Picking up work

• Internal contributors work from issues assigned to their group's planning board.
• Community contributors are encouraged to start with issues labelled Seeking community contributions. The community fork at https://gitlab.com/gitlab-community/gitlab-org/gitlab is the recommended place to push branches.

Merge request process

The full process is documented in doc/development/contributing/merge_request_workflow.md. The condensed flow:

1. Open an issue first if your change is non-trivial.
2. Fork (use the community fork if you're external) and create a branch off master.
3. Make focused commits. Run lint and the tests for what you touched.
4. Push the branch and open an MR against master.
5. The Danger bot comments with reviewer suggestions, missing-changelog warnings, and lint hints. Most Danger warnings are non-blocking.
6. The Reviewer Roulette assigns a reviewer and a maintainer.
7. Address review feedback, then a maintainer merges.

Definition of done

GitLab maintains an explicit "Definition of done" checklist. Before a maintainer merges, every item should be addressed:

• Tests pass (unit + relevant integration/E2E).
• Documentation updated where applicable (doc/).
• Changelog trailer added when the change is user-visible.
• Database migrations follow the migration style guide.
• Feature flags follow the feature flag process.
• Internal events tracking added for new features.
• Audit events added when affecting compliance.
• Performance reviewed when touching hot paths.

Reviewer roulette

The bot at https://gitlab-org.gitlab.io/gitlab-roulette/ picks reviewers and maintainers based on .gitlab/CODEOWNERS and reviewer status. You may explicitly request a different reviewer at any time.

Pipeline expectations

CI for this repo can run for 1-2 hours end-to-end, including:

• Static analysis (RuboCop, ESLint, Stylelint, Prettier, HAML lint, gettext, danger).
• ~600 RSpec parallelized jobs across the main, ci, sec, and EE databases.
• Jest for the frontend.
• Workhorse Go tests.
• Selective E2E (QA) tests via package-and-qa.
• Schema validation, migration validation, and migration timestamps validation.
• Markdown link checks (scripts/lint-doc.sh).

Failures are not always blocking — some jobs are flagged "allow_failure" and Danger comments are warnings. Read the job log before assuming it's a real problem.

Sub-pages

• Development workflow — branch / commit / push cycle.
• Testing — frameworks, what to test, how to run.
• Debugging — logs, common errors, performance.
• Patterns and conventions — service objects, ServiceResponse, EE prepend, error handling.
• Tooling — RuboCop, ESLint, Lefthook, Danger, Housekeeper.