Development processes

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

Processes

Must-reads:

Complementary reads:

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:

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:

    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

History

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

Shell Scripting guides

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.