On this page

GitLab Repositories

GitLab consists of many subprojects. A curated list of GitLab Repositories can be found at the GitLab Engineering Projects page.

When adding a repository please follow these steps:

  1. Ensure the project is under the gitlab-org namespace for anything related to the application or gitlab-com for anything strictly company related.
  2. Add the project to the list of GitLab Repositories
  3. Add MIT license to the repository. See MIT License Example.
  4. Add Contribution Guide. See Contribution Example.

Engineering Groups


To maintain our rapid cadence of shipping a new release every month, we must keep the barrier low to getting things done. Since our team is distributed around the world and therefore working at different times, we need to work in parallel and asynchronously as much as possible. That means that if you are implementing a new feature, you should feel empowered to work on the entire stack if it is most efficient for you to do so. For example, if you are a frontend developer, you should feel free to tackle the Ruby code necessary to support a new feature. Likewise, a backend developer should feel empowered to write the necessary JavaScript to enable a new UI element.

We do need to maintain code quality and standards. There are a few guidelines for collaboration:

  1. If you are working on an issue that touches on areas outside of your expertise, be sure to mention someone in the other group(s) as you soon as you start working on it. This allows others to give you early feedback, which should save you time in the long run.
  2. Security: If a frontend developer needs to touch controller code, a backend developer / reviewer / maintainer should do a thorough review.
  3. Big features/moonshots: If we do something ambitious where there are no previous examples and requires a high degree of complexity in both frontend and backend, form a team upfront that has UX designers, frontend, and backend engineers.
  4. Final review: A final review of a merge request should be made by a maintainer. If it is mainly frontend code it should be reviewed by a frontend maintainer, and if it is mainly backend code it should be reviewed by a backend maintainer. For more specific review guidelines, please read through the code review guidelines

Developers on Support Team Rotation

See the fix4all description.

Release Managers

The release-tools repository contains useful information about the responsibilities and tasks performed by a release manager.

Because of the volume of work required to get a release out the door, there will be two primary release managers:

  1. One in the America time zones
  2. One in Europe/Middle East/Africa (EMEA) or Asia Pacific (APAC)

Trained release managers, one in Americas and one on EMEA/APAC, will ultimately be in charge of making sure the release candidates (RCs) get created and deployed.

Here is the upcoming and current list of release managers.