Innersource Summit - How GitLab breaks down barriers to increase collaboration during the software development process

Innersource Summit - How GitLab breaks down barriers leveraging open-source processes to increase collaboration during the software development process



It was a pleasure to present how GitLab breaks downs barriers at the recent InnerSource summit.


 DRI (Directly responsible individual): Priorities for engineering teams are primarily set by product managers as the DRI in conjunction with their stakeholders including the engineering managers, sales, support, etc.

The backlog is actively managed by the product manager and engineering manager.

Transparency: Any employee can comment on any of the epics and the issues they break down into.  The general public can also do this for a significant portion of them.

The author of a change can be an employee who is on a team responsible for a section of code, an employee from another team, or also the general public.

    The author creates and tests the change both manually and by observing the results of the automated test cases and security scanning.

    The author then labels the change for the appropriate team responsible for that section of the code.

    Someone on that team reviews it and gives feedback.  This includes confirming the change is a Minimal Viable Change (MVC) so we can leverage our value of iteration

    After approval, a bot determines if the change requires a maintainer review one or more of developers with these disciplines:

  •         Frontend
  •         Backend
  •         Database

    After approval by the appropriate maintainers, the code is merged and later deployed to the SaaS service. The change is included for self-hosted users in the next monthly release.
We incentivize changes across internal teams and the public via our concept of “everyone can contribute”

Why do they do this?

    Teams don’t need to wait on other teams to change “the other team’s code” for their team to succeed.

    If someone sees something they don’t like, they can put in an MR (merge request) to change it.

    Free and paid users can improve the product and the company handbook.

    Celebration of open-source contributors via the GitLab Heroes program