Hi Ludovic, Ludovic Courtès writes: > Hello Maxim and all! > > Maxim Cournoyer skribis: > >>> 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. >> >> In other words, to give teams the power to gate the changes touching >> their scope. That's reasonable, if we have functional teams. I'd argue >> we aren't there yet. > > I kinda agree; bootstrapping issue then? Bootstrapping, yes, but also tooling, and people not yet catching up. As I've pointed before, we've had the doc mentioning a command which doesn't work to notify teams since at least October of last year [0] and it seems few people even noticed (I think you only did recently :-)), which tells me it's not a very well-trodden path yet! [0] https://issues.guix.gnu.org/58813 > I hope the maintainer team can help make teams “more functional”, > whatever that teams. It’s really what maintainership is about in Guix; > it’s not about writing code. I'm happy to help with the effort, but I don't think it's particularly relevant to Guix co-maintainers more than anyone else interested in advancing/contributing to Guix, and I find it great that it's this way (not out of laziness, but because the talent pool of the whole Guix community is much larger that that of us 4 co-maintainers). Per what we co-maintainers signed up for in [1], the co-maintainers three primary duties are: Enforcing GNU and Guix policies, such as the project’s commitment to be released under a copyleft free software license (GPLv3+) and to follow the Free System Distribution Guideline (FSDG). Enforcing our code of conduct: maintainers are the contact point for anyone who wants to report abuse. Making decisions, about code or anything, when consensus cannot be reached. We’ve probably never encountered such a situation before, though! [1] https://guix.gnu.org/en/blog/2019/gnu-guix-maintainer-collective-expands/ >> And also: >>> I think it avoids the unavoidable misunderstandings that can arise in >>> a growing group and help pacify day-to-day collaboration. >> >> Again, "pacify" irks me a bit in this sentence, given I consider >> collaboration has and continues to be cordial in our community, unless >> I've been living under a rock. > > “Pacify” in the sense that, by being explicit, we avoid > misunderstandings that could turn into unpleasant experiences. > > Like you I’m glad collaboration is nice and friendly; yet, over the past > few months I’ve experienced misunderstandings that seemingly broke the > consensus-based process that has always prevailed. I'm sorry that you feel that way. I don't think consensus was willfully broken, and perhaps by studying some actual examples of these occurrences we can better understand what went wrong and how the new suggested policy would have helped or could be modified to help avoid such problems in the future. It's also worth noting that this consensus-based process has always been implicit; for example, it is not defined/mentioned anywhere in our documentation. Perhaps it should? > In a way, that’s probably bound to happen as the group grows, and I > think that’s why we must be explicit about what the process is and about > whether one is expressing consent or dissent. > > With so many things happening in Guix (yay!), it’s also easy to overlook > a change and realize when it’s too late. By having a rule that at least > one other person on the team must approve (consent to) a change, we > reduce that risk. > > Being on a team, then, is a way to express interest on a topic and to be > “in the loop”. That's already what teams can do! I'd argue giving them the extra powers that would be conferred to teams in this is not needed/desirable. Some committer not a regular member of X team may still be confident enough to push a patch sitting on the tracker, and I think they should be able to. > It is not about asserting power or building a hierarchy; > it’s about formalizing existing relations and processes. OK; I think in practice it would amount to that though (building a hierarchy which has some form power). > I hope this clarifies my position! Yes, it does. Thanks for taking the time to field some of the questions! -- Thanks, Maxim