Hi Ludovic, Ludovic Courtès <l...@gnu.org> writes:
> Hello Guix! > > The project has been steadily gaining new contributors, which is great, > and I think we need to adjust our processes accordingly. > > Currently teams are described mostly as pools of people who can mentor > contributors in a particular area and who can review patches in that > area. My proposal is to give teams formal approval power over changes > to code in their area. > > This is sorta happening already, but informally: if a non-committer > sends a patch, someone from the team eventually “approves” it by pushing > it. Within a team, the situation is different: people usually discuss > changes, and the submitter (also committer) eventually pushes them; > sometimes, the submitter pushes changes without getting approval (or > feedback) from others on the team. > > With the proposed policy, members of a team would also have to review > and approve each other’s work. Formal approval means getting an > explicit “LGTM” (or similar) from at least one other team member. > > This is similar to the review thresholds found on GitLab & co., where > project admins can specify a minimum number of approvals required before > a change is marked as ready. I think it avoids the unavoidable > misunderstandings that can arise in a growing group and help pacify > day-to-day collaboration. > > Below is a suggested change. > > What do people think? > > Ludo’. 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. [0] https://issues.guix.gnu.org/58813 -- Thanks, Maxim
