Hi Vagrant, Vagrant Cascadian <[email protected]> writes:
[...] > * A serious concern is what blocks consensus, not the person Agreed. And I believe there should be no discussions after the final "deliberation" phase is done, which puts the focus on the disapproving individuals and often ask of them to explain again their rationale for doing so, while the process should have made that clear earlier already. > It is way too easy to point to the person raising a blocking concern, > but that is absolutely the worst thing you can do to build consensus. > > It should be focused on the issues raised as something to cooperatively > resolve, not the individual personalities involved. > > To this end, I would like to propose that concerns are (eventually) > raised as pull requests, patches or issues in some formalized process. Not exactly replying to the above, but related: GCDs should perhaps be *encouraged* to be mostly about technical matters? Browsing the Python PEPs [0] for example, the most "meta" or non-technical PEPs appear to be about governance or the release process. The vast majority of them is focused on technical topics. Personally, I find reasoning about technical topics much simpler, as they tend to be well defined and not overly broad/complex/diffuse, and can thus be reasoned in a more mathematical sense, which I suspect is how many of us Guix are wired to reason, which in turns facilitates consensus. My concern is that if we start with a GCD that doesn't have a clear-cut solution, then having Codeberg issues tracking, as a silly example, why someone didn't like the proposed new color for the shed, is not going to be of much help. [0] https://peps.python.org/#index-by-category [...] > * Every GCD as a separate project > > I envision each GCD as a new project for the initial draft, which is a > reference from which to submit issues and/or pull requests, and also > gives the ability to compare changes across revisions, see when a change > was merged, etc. we can track the primary author(s) of a given change > using git metadata, and use various *-by git commit traileer > conventions. > > We can keep the whole change history archive as a reference, and > possibly only merge the final result into the repository of official > policies... Yeah, that sounds like a good idea for a more structured, clear resolution of points, though even heavier than the already heavy process we currently have (which is that authors address points as they see fit and issue new revisions). > * word choices > > I think the "deliberation" phase in the current GCD process is very > confusing to me as a native English speaker, as it more commonly is a > synonym for "discussion" rather than the tallying the final results of a > decision. Inevitibly, social creatures that we are, we will want to > discuss all the way through, but at some point it should refocus. It confuses me as well, even in my native French, and probably invites the post-result discussions we've seen. Something like "Test for Agreement" would convey the stage better (that's stage 6 in [1]). [1] https://www.seedsforchange.org.uk/consensus#stages > I find "disapprove" to be far too weak of a word given the severe > implications for the process. Again, with my native English speaker hat > on, the difference between "disapprove" and "accept" is just a matter of > degree, whereas the function "disapprove" holds in the process is much > more severe than anyone's individual opinion. Not entirely sure of a > better choice, but perhaps "reject" is more honest? I wouldn't want to make disapproving even a bigger deal than it already is. While it shouldn't hopefully be a routine outcome, I believe it's part of a healthy process that disapproving is allowed/recognized/valued as a potential outcome of the process. > Also using "I accept" "I support" "I disapprove" centers "I" more than > the issues raised, which again, it should not be about the individual > community members, but about the issues and concerns raised by the > community. Good point. Another unrelated point that I'd like to emphasis, that others have mentioned in past discussions, is that we seem to not have any kind of opening out of a discussion; we jump straight to a proposed draft, that then enters a discussion/editing phase; thus the original shape or even content of the document may be far from the shape it'd need to have for it to be agreed by the community. Taking an approach where the community would be more involved into recognizing a problem and looking for a solution early, rather than being asked to review a complete proposal, would help consensus a lot here, I think. This corresponds to the stages 1: Introduce and clarify the issue, 2: Open out the discussion and 3: Explore ideas in a broad discussion of the Consensus-decision making document linked above [1] (which is also referenced in our documentation). -- Thanks, Maxim
