#development , #frontend, #infrastructure, 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:
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 CoffeeScript/JavaScript to enable a new UI element.
We do need to maintain code quality and standards. There are a few guidelines for collaboration:
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:
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.
Here is the upcoming and current list of release managers.