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 down 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: Employees can comment on any 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 on a team responsible for a section of code, an employee from another team, or the general public.
The author creates and tests the change manually and by observing the results of the automated test cases and security scanning.
The author then labels the change to the appropriate team responsible for that code section.
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 to review the change with one or more of the developers with these disciplines:
The backlog is actively managed by the product manager and engineering manager.
Transparency: Employees can comment on any 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 on a team responsible for a section of code, an employee from another team, or the general public.
The author creates and tests the change manually and by observing the results of the automated test cases and security scanning.
The author then labels the change to the appropriate team responsible for that code section.
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 to review the change with one or more of the developers with these disciplines:
- Frontend
- Backend
- Database
- Security
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
Video
Slides
Comments
Post a Comment