Teams in GitLab
Problem to solve
Projects receive contributions from many teams, but we don't have a formal notion of a team within GitLab. The concept of teams is necessary if we want to provide meaningful tools for capacity planning and building a better user experience that is more context driven around what teams around working on.
When creating issues it would be good to be able to designate that those issues are part of the work of a Team of individuals future work despite not being assigned to an individual.
Intended users
Developers, project planners
Further details
- Teams are a well known concept, even within GitLab the company.
- We have subgroups, but they don't allow for things like capacity planning. Currently, engineering managers are calculating capacity manually. One of the strategies for Issue Tracking is to introduce more autonomation into the issue management so that everyone can have more time and space to focus on solving more meaningful problems.
- Teams should have a workspace that is optimized for the tasks they are trying to accomplish.
Proposal
This proposal would be converted to an epic and chunked down into MVCs. In order to understand the value of the original MVC, it's important to see how it contributes to solving a bigger need for the wider community.
Add Team Field To Issue (Original MVC)
Create a field for Team. It can be assigned only to a pre-created Group in GitLab. Future iterations could do interesting things like auto-assign Teams based on certain parameters. This might also make future searching, boards, and analytics at a team level easier to setup defaults for.
Add Teams To Groups
Our permissions model is structured such that lots of members can belong to a group. This allows those members to view things that the group has access to. Membership does not denote being a part of the team that is spending most of their time moving the goals of a given group forward.
Proposed behaviors:
- A member of a group can be assigned to a team within the group.
- A group can have more than 1 team but never sub-teams of teams. This is important as we build out capacity management and introduce first-class support for issue tasks.
Next Iterations
- Introduce capacity planning more formally into GitLab
- Creating automatically configured Issue Boards within the team's group scoped for the team that include burndown charts
- Report on velocity and volatility at the team level.
- Reduce our reliance on labels to solve all of our organizational problems.
- Introduce the ability to roll up team level reports from a sub-group to a parent group.
Permissions and Security
- There are some things we need to pay particular attention to. Specifically, how to handle situations in which a team member within a group does not have access to the project where the issue assigned to the group lives.
Documentation
- We will certainly be needing a lot of documentation for this.
Testing
- We should have sufficient e2e and unit test coverage for this feature.
What does success look like, and how can we measure that?
Success Criteria
- To be determined during problem validation.
Acceptance Criteria
- To be determined during problem validation.
Links / references
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.