#development , #frontend, #infrastructure, #ci-cd, and #support chat channels for questions that don't seem appropriate to use the issue tracker or the internal email address for.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:
CONTRIBUTING.md from the project's README.mdTo 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 also 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.
We need to maintain code quality and standards. It's very important that you are familiar with the Development Guides in general, and the ones that relates to your group in particular:
Code reviews are mandatory for every merge request, you should get familiar and follow our Code Review Guidelines.
The release-tools repository contains useful information about the responsibilities and tasks performed by a release manager. Here is the upcoming and current list of release managers.
Because of the volume of work required to get a release out the door, there will be two primary release managers:
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.
These release managers need to be very vocal if they need help or something is blocking the release candidate (RC)
Trainee release managers will do most of the hands-on work (e.g. cherry-picking, creating RCs, deploying, etc.).
Trainers should allow trainees to do the work, but like a pilot of an airplane they can take over when time becomes critical.