Team-centered collaboration

Problem

For historical reasons, the collaboration model in GitLab has followed a repo-centered approach. A GitLab project is essentially a wrapper around a single repo, and all the powerful collaboration features are based within that project. This is great for teams that work within a small number of repos. A typical use case is that there is an idea, and somebody creates an issue with respect to that project-repo. This provides powerful integration features with code review / merge requests, and the CI/CD process at the tail end. However, there currently is a gap in GitLab where many organizations have a team-centered or product-centered approach that spans many repos. We ourselves experience this problem as a slight annoyance with CE+EE. For many of our customers, this is more pronounced and they have been requesting features to alleviate the pain. So far, our response is to offer the Group paradigm to mash projects together. But this is not sufficient, because it still forces our users to think in projects/repos, when software product development should start at the user (not at the technology stack). Since our vision is getting ideas and shipping them to production quickly, we need a strong team-centered / product-centered approach to collaboration.

Scope

The scope of this issue is to have a high-level discussion of the problem. And then to think about our strategy to tackle it. It may involve some major changes to GitLab as a whole, or introduce some radical new paradigms. Or perhaps is there an iterative path to get us to a stage that can solve team-centered use cases? And do we want to abandon / sunset or at least reduce the promotion of a repo-focused workflow? The output of this issue should be a set of principles and common use cases of folks using GitLab from end-to-end. We should also have a direction and strategy, and commentary from our engineering team on if/when and how to execute any major technical hurdles.

Strategic opportunity

As we scale up and truly build end-to-end tools for our customers, this is a very critical time to nail down the right paradigms. In particular, issue boards are just ramping up. The board paradigm is extremely powerful and will allow us to majorly disrupt other issue management trackers in the project management space. So it's important that we introduce the right concepts to our customers, so that they can truly abandon JIRA, Trello, etc., and use GitLab as a single solution.

Typical scenarios

These are typical scenarios in enterprises which highlight the existing gaps of GitLab. One salient observation is that the software industry is moving away from monolithic systems and toward microservices. Many organizations are breaking apart their big systems into many many small microservices, sometimes even over 100 to support a business with many different offerings. (This may be a blind spot for us here in GitLab, where we ship a single, installable product.) It would not be strange for an organization to have over 100 repos, each for a single microservice.

Platform team

In this scenario, there is one (fairly technical) product manager (PM), one engineering manager / engineering lead, and a handful of backend engineers. They are responsible for the platform stability of 5 microservices. They develop APIs. They ensure performance. They do a lot of the tech debt clean up. Because of the microservice architecture, they can run quickly and independently without interfering with other teams (as long as the API remains the same). The PM may want to ship a new feature that improves the overall performance for the entire platform of the 5 microservices. Here, the PM creates a ticket in the issue tracker. But the PM should not necessarily care or know what repos it impacts at the time of issue creation. Later on, the tech team digs into the ticket, and figures out what code needs to be written, and where. All those subsequent code changes (merge requests) should then be linked to the ticket somehow. But the ticket itself is not by itself associated with any particular repo. The tickets of this team are with respect to the team, not particular repos.

Product team

In this scenario, there is one product manager, one engineering manager / engineering lead, a handful of engineers (backend, frontend, mobile, full-stack), and maybe a few designers. The engineers do not "own" any particular codebase (as opposed to the previous scenario). Instead, they work on any piece of code (with help from the platform teams as experts). Here, again the PM and designers decide to create a new ticket to ship a feature. The PM doesn't know or care too much about the detailed technical implications. The PM just creates the ticket. Later on, the engineering team massages the ticket, offering opinions, especially technical ones, before digging into the work. It may turn out that that one particular ticket touches 10 different repos. And maybe the PM will then chop up the ticket into multiple tickets to release more strategically. But in any case, the tickets, and the entire collaboration process, is team-centered and product-centered. Only the code review and CI/CD stages are repo-centered. But these are back-integrated into the user-focused tickets themselves. It doesn't make sense to force the tickets to be associated with any repos.

Bug tracking

Tracking bugs can be especially difficult. It be first reported by a customer externally. It may be logged in a support ticket system like ZenDesk. Then the ticket may need to flow through to different teams, because the root cause cannot be determined easily. The teams could be working on entirely different technologies (operating system, middleware, app layer, etc.) (though still in software, for our initial use cases at least) throughout the organization. How do we handle this situation? Should there be a single ticket? Multiple tickets linked together?

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.