Hi Gabriel, On 2026-04-27 at 16:30+02:00, Gabriel Wicki wrote: > Please let me know about any minor and major issues > you still see with the proposal
I'm sorry I did not respond to your reply sooner, so here it goes: On 2026-04-03 at 15:45+02:00, Gabriel Wicki wrote: > Nguyễn Gia Phong writes: > > I do like being reached out to, I just do not want it to become > > a responsibility across all my communication channels. > > May I suggest narrowing this down to communication channels registered > > for the project? > > That is what is intended. Nobody should be reachable for the project on > channels they did not themselves add (or approve to be added) to > `etc/teams.scm`. Thanks, this section currently reads: > Team members are expected to be reachable and respond to communications > both from within as well as from outside of the project by email, > and for code-related teams Codeberg, through their team's label. I suggest rephrasing the latter part something along the line of > communications through channels registered in `etc/teams.scm`, > which at the time of writing includes email and Codeberg. Alone, _email_ could entails any other address and _communications from outside of the project_ still reads to me like stuff additional to the later listed email and Codeberg. Since the social scope of the project is not clearly defined, I think we can drop the within & outside part (which just means everyone anyway). > Active committers should be informed about ongoing discussions > with a frequency of at least 7 days. I do not think this is possible even if we only count guix-devel for the discussions. Since it's to > ensures that all active committers take note and can respect > imposed restrictions that are taken by other committers > (like a push freeze to the `master` branch prior to a release). I suggest requiring commiters to be informed of the outcome of such discussions, e.g. guix-info. There are decisions one may have no interest in discussing and just go with whatever that is decided. On 2026-04-03 at 15:45+02:00, Gabriel Wicki wrote: > Nguyễn Gia Phong writes: > > 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've tried to clarify this distinction more explicitly with the upcoming > change since it has spurred quite some confusion and disagreement. > > Nguyễn Gia Phong writes: > > 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. > > To me "passive" committers are not people on a prolonged (think: > multiple months) leave, but rather people temporarily unavailable to do > some work. I don't think it is necessary to announce single-day or > week-long absences publicly, but I can see how teamwork could use > arrangements with respect to longer absences. I'd leave that up to the > teams. Currently, the definition of passive committers is only used to require them to catch up with the state of affairs before transforming into active ones. How about > before pushing changes to protected branches, commiters must > be updated with the relevant decisions that are announced in [...] for the entire reachability section? As a team members, they need to be reachable via registered communication means anyway. On 2026-04-03 at 15:45+02:00, Gabriel Wicki wrote: > Nguyễn Gia Phong writes: > > > - 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. > > Currently this would mean only adding the fingerprint to the `master` > branch. I can gladly remove this bullet-point if it is too confusing or > does not adequately reflect our current handling of the situation. Please do, I support the idea of explicit branch access, but its execution needs to be discussed upon (later). Best wishes, Phong
signature.asc
Description: PGP signature
