Hi, Maxim Cournoyer skribis: > It sounds reasonable and a good change "on paper", but in practice I > think it may be too soon to formalize teams that way. Teams are a > nascent concept which hasn't reached a point we can rely on it, in my > opinion. We are still ironing out kinks in the tools [0] :-). I'd > prefer we stay as nimble/agile as we can and maximize the potential of > our large committers pool for now, at the expense of sometimes having to > retroactively discussing/fixing up or reverting some change that wasn't > up to par, that could have possibly been caught by a more focused team. I think formalizing collaboration would be the way to “maximize the potential of our large committer pool”: by having clear rules, we make it easier to work together, not harder. Retroactively fixing, reverting, or discussing often causes unnecessary friction and puts pressure on the collective. Discussion should always happen before the fact. We’ve reached the point where the code base is large and the experiences of individual contributors vary. To cope with that, I think we need to communicate and coordinate more to have a shared understanding of the code, of our goals, of our needs and expectations. We can no longer rely on implicitness and the idea that silence is consent. This proposal is one possible step in that direction, but I’m open to other approaches. Ludo’.