The Quality team currently works cross-functionally and our task ownership spans multiple projects.
Upon joining the Quality department, team members are granted either developer, maintainer, or owner access to a variety of core projects. For projects where only developer access is initially granted, there are some criteria that should be met before maintainer access is granted.
For general information, please see the engineering workflow page about how to become a maintainer.
Our team's Quality: Development board (top level board) can span 10k+ issues and it's not easy to work on that level. As a result, it's only meant to capture the current workload of the team. The board shows who currently owns what in the entire GitLab.org space.
The board is meant to be read-only. We don't manage the project on that level.
We have sub-boards at the project level that are used for project management, triaging and scheduling issues.
Each project has 3 boards each for a given dimension of the project management component:
This board shows the current ownership of workload / issues with assignees as the dimension.
This board is for prioritization with priorities as the dimension (
Most important is left most and gradually moves to least urgent.
This board is for scheduling with milestones as the dimension.
Earliest milestone is left most and gradually moves into later milestones.
Each project planning, scheduling and triaging process will happen in the projects' boards.
The boards are using a consistent configuration and is the same across all of our projects. This means that anyone on the team can work using the same set of tools everywhere.
Think of all these projects as different class of objects with stable interface methods that is consistent and cross-compatible.
This also ensures that the data rolled up to the top level board is consistent.