Hi Andreas and all! Thanks, once again, for taking the time to reply.
First, some general note: Getting an inbox full of text after a graveyard-shift trying to explain this GCD to you feels daunting. I know this is a me-problem (I alone should reign over my time and energy), but having this discussion in a "everyone argues against me" fashion feels wrong and wrongly exhausting. I don't imagine consensus finding like this. I took the responsibility to propose and guide us to finding consensus in the matter at hand, but I am not willing to spend days every week arguing. I hope you understand. If this goes on I will have to step back a notch and withdraw (at least my lead) from this GCD. I will try to reply to all your responses. Please—for my sanity's sake—take your time, try to understand what I am proposing in the GCD, try to help me figure out what is not (yet) clearly formulated or what you will not be able to approve of. Discussions whether we have the same understanding of what the GCD process is or is not, as well as other meta-discussions are out of scope. As much as I'd love to discuss these matters with any and all of you they are an additional, seemingly unnecessary load which I don't see me handling for much longer. I feel the need to ask you to refrain from replying with walls of text when you could imagine a misunderstanding to influence our discussions. Please remember that I work two dayjobs and answer these messages (like last time) in a graveyard shift. Please excuse if I fail to respond in an adequate manner, I still try my best here. Andreas Enge <[email protected]> writes: >>> (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 problem is that `teams' are not anymore just programming/packaging related groups. There is the `documentation' team, there will be the `community' team and, as suggested by GCD007 there should be (informal) committers and maintainer teams. That's why the section in the manual is not generally valid enough and GCD007 may feel "less exact" in some places, even though it is universally valid. >> 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. This GCD is designed to define the *social structure* of this project, so it is as universally valid for as long as possible. The more exact numbers and procedures we write down, the more work it will take to refine this GCD. I expect this GCD to be valid for the foreseeable future. In the end, what the exact rulings for team membership or commit access are is not as important as the definition on how these rules are defined and by whom they are enacted. And after all: if "Teams organize their work autonomously" (or maybe even: if teams organize themselves autonomously) should the big project define how they treat their memberships? Maybe a team member can not really take part in the daily duties of a team (e.g. PR reviews) but is important to stay within the team for their expertise? Maybe team members take part in the team's daily duties but are or become—for one reason or another—unbearable for the rest of the team? I have no answers for these questions, but would still like to decide on what we currently have, so we can build future (social) structure on top of that. >>> 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. I beg you pardon? > 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. Please realize that I can not (and will not) blindly follow the demands or wishes of any of my fellows. This is a discussion. Anyone can raise questions or hint towards shortcomings, anyone can suggest different wordings, phrasings or concepts. If you want to stress the importance of one issue or another I cordially invite you to take part in the discussion (where it actually happens). Just voicing that you agree with somebody's opinion without reading the argumentation on why specifics are infeasible, unrealistic or maybe just not that great of an ideaseems unhelpful in finding common ground. > 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. Is this about the "several months" vs. "one year" for commit access? This exact phrasing is IMHO a minor detail that I can gladly adjust. If this is about the termination of team memberships: I don't think this has been defined (anywhere, at all) and I would be quite happy for input. Who in a team decides about the membership of others? Thank you for helping me find adequate formulations. > - Do not distinguish between active and passive committers. If we want to specify expectations towards committers reading guix-devel (btw Ludo' thinks this is a good idea) this distinction is IMO necessary. Please, since this seems to having caused quite some confusion, note that this is not the same as committers whose commit access will be revoked (I thought both the need, the distinction and the process are adequately formulated in the GCD). > - Obligation/incentive to review other people's work. This is not valid for all teams, only for the subset of programming or packaging related teams. If we wrote that into the GCD we would hinder growth or exclude people doing for example social work from partaking in the GCD process. > - "For one year" instead of "for several months". Again: Minor detail that I think might hinder future development. If we write "several months" we can leave it how it currently is stated in the manual and, if we ever feel the need, lower this to 6 or 3 months. If we "ratify" (sorry, Chris) "a year" we would have to change/amend this GCD as soon as this rule were to change. I am not trying to write down all our current rules for everything in GCD007, but the important stuff WRT our social structure. These being: which roles exist, how can one take a role, how can a role be dismissed/revoked, what expectations do we (as a project) have towards the members of said roles. > - 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). Please note that in GCD006 (the one you sponsor) among others "we" appears as well. As this is another minor nitpick I would love to first clarify whether there are major issues with the essence of the proposal before prematurely optimizing formulations. Thanks for understanding > 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. That's great! What is not so great is that instead of having these discussions in one place your inquiries seem to ask me to repeat myself. I don't see myself doing that in the future. And now to your wall of text: >>> 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). >From GCD007: --8<---------------cut here---------------start------------->8--- Having commit rights does not imply 24/7 monitoring of GNU Guix activity. Hence we distinguish: [...] - Active committers should try, to the extent of their availability, to be reachable by email. This is particularly true after they push changes to the main branch. Such changes may cause breakages and their insight could be useful in repairing them. - Active committers should be informed about ongoing discussions with a frequency of at least 7 days. This 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). --8<---------------cut here---------------end--------------->8--- I am not sure why there is such a fuss around this. All I am trying to do is set up expectations towards people with commit access towards their frequency of reading guix-devel mailing list. If this is such a problem: please tell me another way to formulate this which is reasonable and realistic. > 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. No, it does not make sense to assume so. > 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? No. It is expected of people who are not currently reading up on Guix internal discussions (i.e. "passive" committers) that they will not push stuff to the master branch. I don't understand what is so hard to grasp from this. All I do is trying to formulate what the already existing expectations are. > Actually this is a tautology, No, this is at best a misunderstanding. > since passive committers were defined as not being reachable. > It would be enough to ask of (all) committers to be reachable. This is unrealistic, unreasonable and IMO unhealthy. People need brakes, whether it is due to holidays, digital detox, illness, (temprorary) blindness or natural catastrophes. Breaks exist, are necessary and ignoring their existence is naіve at best. > Actually, one should ask of committers to be active! Yes. > Other committers are without interest to the project (unless they > change from passive to active status again). Maybe your misunderstanding comes from a rigid idea of switching from one state to another. It is not such a harsh difference. Maybe you go to a music festival and partying for a prolonged weekend. Then you are (automagically) a "passive" committer, since you still have commit access, but you are busy having fun. As soon as you read up on `guix-devel` and are ready to push stuff to master again, you are (automagically!) an active committer. > "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). Should I rephrase it to "Active committers inform themselves" so it is clear that nobody is supposed to actively inform the active committers? I can gladly change that wording. > So I stand by me comment, there is no need to define active and passive > committers. Please see my explanations above. > 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). This is exactly what GCD007 does. Thank you for the reassurance. More answers follow (ASAP) in separate emails. Thank you all for participation in this process, your time and efforts! gabber
