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

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


Video


Slides


 Content

 
 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.

https://about.gitlab.com/handbook/people-group/directly-responsible-individuals/

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.

https://about.gitlab.com/handbook/values/#transparency

 

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 (https://about.gitlab.com/handbook/values/#iteration)

    After approval, a bot determines if the change requires 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.


https://about.gitlab.com/handbook/engineering/workflow/code-review/

 

We incentivize changes across internal teams and the public via our concept of “everyone can contribute” : https://about.gitlab.com/company/mission/#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 see 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: https://about.gitlab.com/community/heroes/




Comments