Scaling-up a team is a common challenge in OpenStack. We always increase the number of projects, with more contributors and it often implies some changes in the organization. This policy is intended to document how we will address this challenge in the TripleO project.
Projects usually start from a single git repository and very often grow to dozen of repositories, doing different things. As long as a project gets some maturity, people who work together on a same topic needs some space to collaborate the open way. Currently, TripleO is acting as a single team where everyone meets on IRC once a week to talk about bugs, CI status, release management. Also, it happens very often that new contributors have hard time to find an area of where they could quickly start to contribute. Time is precious for our developers and we need to find a way to allow them to keep all focus on their area of work.
The idea of this policy is to create squads of people who work on the same topic and allow them to keep focus with low amount of external distractions.
We might need to test the idea for at least 1 or 2 months and invest some time to reflect what is working and what could be improved.
The list tends to be dynamic over the cycles, depending on which topics the team is working on.
Here’s a proposal for Ocata:
|ci||Group of people focusing on Continuous Integration tooling and system|
|ui/cli||Group of people focusing on TripleO UI and CLI|
|upgrade||Group of people focusing on TripleO upgrades|
|validations||Group of people focusing on TripleO validations tooling|
|workflows||Group of people focusing on TripleO Workflows|
|containers||Group of people focusing on TripleO deployed in containers|
|networking||Group of people focusing on networking bits in TripleO|
|integration||Group of people focusing on configuration management (eg: services)|
|python3||Group of people focusing on porting TripleO projects to Python 3.5|
Note about CI: the squad is about working together on the tooling used by OpenStack Infra to test TripleO, though every squad has in charge of maintaining the good shape of their tests.
One alternative would be to continue that way and keep a single horizontal team. As long as we try to welcome in the team and add more projects, we’ll increase the problem severity of scaling-up TripleO project. The number of people involved and the variety of topics that makes it really difficult to become able to work on everything.
This work is licensed under a Creative Commons Attribution 3.0 Unported License. http://creativecommons.org/licenses/by/3.0/legalcode