Replying to gabber's comments on Codeberg, since I find it easier to do so by mail (unfortunately I already deleted the notification, so will have to quote by copy-pasting; ">>" is me, ">" is gabber).
>> (expectations to review other people's work, > We are talking about team members here, right? Team members of > source-code-related teams, right? Yes, for instance in the current manual: "A team’s primary mission is to coordinate and review the work of individuals in its scope (see Reviewing the Work of Others);" > The reason why I stayed (deliberately) vague with phrasing is that, with the > example of commit access revoked by the maintainers, it is a policy and this > (probably) will change in the future > Writing down in this GCD how many weeks/months/years some process takes is > IMO out of scope and should (if need be) discussed elsewhere. Hm, this is where apparently we disagree on the roles of GCDs. To me it is akin to a legal document, where precise and actionable decisions are taken, and where our policy is defined. It can change in the future, of course, but this requires a new consensus seeking process and thus another GCD. >> I agree with @civodul's suggestions and would like to see them applied; > All of them? Without discussion? Interesting This is not only sarcastic, but also a non sequitur. You spent a lot of work in drafting the GCD, I (and others) spent work in reading and commenting it; I did not feel it a good use of our time to repeat the same arguments and add +1s. And where do you see the lack of dicussion? I precisely contributed to it by saying that I agree with Ludovic's points; I will go through them again: - Be precise on termination of roles. - Do not distinguish between active and passive committers. - Obligation/incentive to review other people's work. - "For one year" instead of "for several months". - Problem with "we" (I have more problems with "you" and "one" and so on as stated in my previous contribution, it is not always clear who these people are). So I may have missed some when going through them again, but indeed I find that apparently I agree with all of Ludovic's comments. >> No need to define "passive committers", since the term does not appear later >> on. > Well, we could only define active committers (which do appear later on) but > that would not make much sense, now, would it? >> The only speciality of passive committers is that they ought to be removed >> :-) > That is neither how passive committers are defined nor how the removal of > commit access is supposed to work. Maybe you want to allow this section to > grant you some more insight by reading it again? I have read the section on active and passive committers again. The word "passive" appears only once in the document. I assume that the idea is to have a partition of the set of committers, that they are either active or passive (strictly logically speaking they could be both: "able and willing to push changes" and "unreachable", for instance). In any case, there is not a single sentence in the document that applies to passive committers apart from their definition; so the definition can clearly be dropped. The word "inactive" is used as a reason to lose commit rights; is "inactive" the same as "passive"? It makes sense to assume so, but is not 100% clear. Later distinctions make little sense to me. "Active committers should try (...) to be reachable by email" So a committer can be passive and then nobody will reproach to them that they are not responding to email? Actually this is a tautology, since passive committers were defined as not being reachable. It would be enough to ask of (all) committers to be reachable. Actually, one should ask of committers to be active! Other committers are without interest to the project (unless they change from passive to active status again). "Active committers should be informed about ongoing discussions with a frequency of at least 7 days." This is a completely unclear sentence due to the passive voice. Who should inform them? People starting the discussions? Or is it a duty of committers to actively follow the discussions (I presume that this is meant, actually). So I stand by me comment, there is no need to define active and passive committers. Committers are people with commit rights, and the document should define what the project expects from them, and under which conditions the commit rights are revoked (because the committer does not meet the project expectations). >> I would replace "GNU Guix" by "Guix". Our goal is to set our own rules, >> independently of whether we are part of some form of GNU. > And it has always been like this. I would really love all of you that get so > offended by the appearance of the GNU in this GCD to at least try to > formulate a separate GCD This is your interpretation. I am not offended by the use of "GNU Guix", but for the sake of clarity I would prefer to just use "Guix". In case that for one reason or another we stop being "GNU" at some point in time, will this GCD still be valid, or did it only apply to "GNU Guix" and not to "Guix"? (I admit this is a somewhat sophistic argument; a sensible approach would be to consider the GCDs still applicable.) >> That being said, if you (or anyone else) will disapprove of this GCD only >> because I write the name of our project like it is currently written on our >> website, in our manual and in many other places, I will see myself forced to >> change this. This is again your interpretation. So far I have advanced arguments and formulated preferences, but not given a hint at whether I will approve this GCD or not. But if you want to, I can: I think the distinction of passive and active committers is awkward bordering nonsensical; I would prefer "Guix" to "GNU Guix" in a GCD; but I do not see myself vetoeing a GCD because of this. However, I might do so in case the GCD falls back behind the current manual on formulating expectations and consequences and thus effectively remove them (for instance, the one year rule). Andreas
