Hi Gabriel, On 2026-03-26 at 00:28+09:00, Nguyễn Gia Phong wrote: > On 2026-03-25 at 15:01+01:00, Gabriel Wicki wrote: > > Don't be shy! We're still in the exploration phase. There are no > > /wrong/ opinions or ideas (at least not for all I care). > > Thanks, I'll do the homework on this, pinky promised!
I'm doing this through email because I can't figure out how to make review context on Forgejo longer than 4 lines. > - Teams are founded after proposing the creation on the > `[email protected]` mailing list and pushing a commit adding the > team to `etc/teams.scm` with its initial members. > > #### Responsibilities and scope > > - Teams take responsibility for specific aspects of the GNU Guix > Project. They define the scope of their responsibilities (which > packages, modules or other aspects of the project) collectively. > Teams organize their work autonomously. Am I having the correct understanding that a team's scope is to be peer-reviewed by all contributor when a team is created (pushing a commit to master), but only by the team's member (autonomously) after the creation? If this is the case, why would teams not exist outside of the Guix project? So far, it seems packaging teams exists for practical reasons, e.g. notifications and staging branches. Because these facilities are tightly coupled with Guix infrastructure, the teams have to be defined there, and since teams make use of these common resources, there are also external expectation to their scope IMHO. I don't think, say, team GNOME can silently drop GLib from its scope without any transitional period for another (new) team to adopt it. > #### Reachability > > - Teams are expected to be reachable and respond to communications > both from within as well as from outside of the project. Perhaps I misunderstood the wording, but I definitely do not like having to be reachable outside of the project. Being part of a team shouldn't mean I have to answer the door to someone coming to my home to talk about Guix. Or email addresses and social media accounts I use for other purposes. I do like being reached out to, I just do not want it to be come a responsibility across all my communication channels. May I suggest narrowing this down to communication channels registered for the project? > This includes email as well as Codeberg, through their team's label. Nitpick: what Forgejo calls label does not ping people, though I'm not sure what the terminology it uses for the @guix/... thing. > - Passive committers are people that currently hold commit rights but > are unreachable or otherwise unavailable to use their > responsibility. I prefer to not have this classification as the difference between passive and inactive is unclear, but rather a process for committers to be unreachable. I suggest committers to announce their unavailability period in the teams file, either directly or through other commiters (e.g. their absence is due to being AFK). This information is invaluable to other contributors so they know who to ping. > - The commiter's OpenPGP fingerprint is added to the > .guix-authorizations file of the branch(es) you will commit to. Is this leaking the idea of explicit commit access to each branch? I think that is a new thing by itself and not described in this GCD. Either way, I think this risks merging commit rights accidentally, e.g. from a staging branch to master. Please also look for other instances of you/we/our/us in this document and see if they refer to the right people; in this particular case, maybe: -you will commit to. +to be committed on. > - [...] Altough most (if not all) possible mistakes can > be reverted, a single, malicious commit to `master` could > jeopardize our means of computation, destroy our reputation and > mean a factual end to this endeavor. Another typo for _Although_, and I think the malicious part can be omitted, unless there's a suggestion for a remedy. (_Committers MUST NOT commit malicious stuff_ could be it, though it's not very useful.) On 2026-03-25 at 18:35+01:00, Gabriel Wicki wrote: > On Thu, Mar 26, 2026 at 12:28:27AM +0900, Nguyễn Gia Phong wrote: > > Full disclosure: I want this GCD to go forward solely for there to be > > an updated list of maintainers, > > I don't think updating the list of members in the maintainer's > collective is part of this GCD. It effectively is, as a result of the creation of a team of maintainers, and the following. > - Teams and their memberships are defined and described in our > main source code repository in the etc/teams.scm script. Cheers, Phong
