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.
The following guidelines will help you to become a maintainer. Remember that there is no specific timeline on this, and that you should work together with your manager and current maintainers.
To start the process of becoming a maintainer, see the maintainer section of the code review guidelines.
In general, you're required to author and review 3 - 10 MRs that demonstrate good overall understanding
of the existing codebase and framework. See the section above for further details of the requirements.
You can seek out more opportunities to work on framework improvements by asking on the #quality Slack channel.
Your reviews should aim to cover maintainer responsibilities as well as reviewer responsibilities. Your approval means you think it is ready to merge.
It is your responsibility to set up any necessary meetings to discuss your progress with current maintainers, as well as your manager. These can be at any frequency that is right for you.
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: Development, Prioritization, and Scheduling
This board shows the current ownership of workload / issues with assignees as the dimension.
This board is for prioritization with priorities as the dimension (~priority::1 ~priority::2 ~priority::3 ~priority::4).
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.
~Quality