• Processes
  • Development guidelines review
    • Broader changes
    • Technical writing reviews
  • Reviewer values
• Language-specific guides
  • Go guides
  • Shell Scripting guides
• Clear written communication

Development processes

Consult these topics for information on development processes for contributing to GitLab.

Processes

Must-reads:

• Guide on adapting existing and introducing new components
• Code review guidelines for reviewing code and having code reviewed
• Database review guidelines for reviewing database-related changes and complex SQL queries, and having them reviewed
• Secure coding guidelines
• Pipelines for the GitLab project

Complementary reads:

• Avoiding required stops
• Contribute to GitLab
• Security process for developers
• Patch release process for developers
• Guidelines for implementing Enterprise Edition features
• Adding a new service component to GitLab
• Guidelines for changelogs
• Dependencies
• Danger bot
• Requesting access to ChatOps on GitLab.com (for GitLab team members)

Development guidelines review

For changes to development guidelines, request review and approval from an experienced GitLab Team Member.

For example, if you’re documenting a new internal API used exclusively by a given group, request an engineering review from one of the group’s members.

Small fixes, like typos, can be merged by any user with at least the Maintainer role.

Broader changes

Some changes affect more than one group. For example:

• Changes to code review guidelines.
• Changes to commit message guidelines.
• Changes to guidelines in feature flags in development of GitLab.
• Changes to feature flags documentation guidelines.

In these cases, use the following workflow:

1. Request a peer review from a member of your team.

2. Request a review and approval of an Engineering Manager (EM) or Staff Engineer who’s responsible for the area in question:

   • Frontend
   • Backend
   • Database
   • User Experience (UX)
   • Security
   • Quality
     • Engineering Productivity
   • Infrastructure

   You can skip this step for MRs authored by EMs or Staff Engineers responsible for their area.

   If there are several affected groups, you may need approvals at the EM/Staff Engineer level from each affected area.

3. After completing the reviews, consult with the EM/Staff Engineer author / approver of the MR.

   If this is a significant change across multiple areas, request final review and approval from the VP of Development, who is the DRI for development guidelines.

Any Maintainer can merge the MR.

Technical writing reviews

If you would like a review by a technical writer, post a message in the #docs Slack channel. Technical writers do not need to review the content, however, and any Maintainer other than the MR author can merge.

Reviewer values

As a reviewer or as a reviewee, make sure to familiarize yourself with the reviewer values we strive for at GitLab.

Also, any doc content should follow the Documentation Style Guide.

Language-specific guides

Go guides

• Go Guidelines

Shell Scripting guides

• Shell scripting standards and style guidelines

Clear written communication

While writing any comment in an issue or merge request or any other mode of communication, follow IETF standard while using terms like “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”,”RECOMMENDED”, “MAY”, and “OPTIONAL”.

This ensures that different team members from different cultures have a clear understanding of the terms being used.