Hey again!
Andreas Enge <[email protected]> writes: > Replying to guix-devel again, as this is much easier to handle I think. > (I wonder if we need to change the GCD process in this sense, a > discussion on the web interface of Codeberg is complicated.) Please refrain from this practice, as it makes it harder for me to respond and others to follow the discussion. But thank you for your input nevertheless! > Maybe this has become clear from my mail to guix-devel yesterday. > I still have trouble understanding what this distinction would mean in > practice. So "active" committers are expected to react quickly, > "passive" ones not? How is this determined and by whom? So when a > committer is ill or wandering Antarctica, it is okay if they do not react; > if they are just lazy it is not okay? Are they supposed to declare a > state of justified passiveness, and who will agree or disagree that this > is acceptable? See my answers in the previous email (from some minutes ago). >> Please note that the "removal of revocation provisions" is not part of the >> current version of this GCD. As of your suggestion(s) I added the relevant >> bullet-points to the Committers section. > > Hm, I do not see this in your just pushed commit > "007: Refine wording."; is it not yet pushed? Maybe I misunderstood. Is this about more/something else than --8<---------------cut here---------------start------------->8--- - Committers can lose their commit access when they violate their responsibilities or are inactive for several months. --8<---------------cut here---------------end--------------->8--- I think this bullet-point was missing when the comment on the code was first made (but I may well be mistaken, this all grew quite a bit over my head). >> But since this seems to be a source of confusion: IMO this GCD is not >> supposed to include any and all rulings WRT roles and memberships but >> to adequately and generally define what roles exist and how they >> interact with the project and each other. I am deliberately lax with >> the specific "rulings", since rules are subject to change and the GCD >> process is relatively slow and (if I may add) exhausting. I don't it >> would be grave mistake to specify things here only to lack work-force >> to change details in a future GCD. > > I think I also replied to this in my mail yesterday; Please understand that I do not always find the time to answer to all of you at the same time. I answered Ludo's answers first and only just now found the time to reply to the rest of you. > it appears we have very (fundamentally?) different understandings of > the roles of GCDs. This may be (though I doubt it), but it seems out-of-scope for this GCD. > I think they should contain precise stipulations and rules and not > just wishlist items of what people should do in their different > roles. That (precice rules vs. wishlist items) is not the distinction I am trying to make, here. I am trying to formulate exact rules that we can collaborate by for as long as possible. Think constitution vs. laws. Exact rulings are based on general agreements. To me, the GCD process is a consensus finding for the whole project to general agreements: precise "laws" can change and vary. Hence my sometimes "not as sharp" but still more universally valid formulations. Wouldn't you agree this makes much more sense that writing down each and every detail into a GCD that is supposed to take months to change? What if there is need to shorten revokation of commit access due to inactivity? What if we need to change some other (minor) aspect? > Since it is a slow and exhausting process, it is even more > important to make tangible progress on our governance (which this GCD > also does, for instance it contains new rules on the maintainer > team). I am not sure how to bridge this! Maybe it would be helpful if > other people chimed in. I think we agree? And yeah: Please, all people, read the GCD and chime in! Thanks for your time and comments and enjoy your weekend! gabber
