Hi Allan, Too many things are being touched on here, and it's become a stagnant discussion where little progress has been made. Firstly, you are correct that the current GitLab login requires you to accept the CoC. In an attempt to remedy this situation, given the current software constraints and the risk of being seen as condescending (although that is not my intention), let's try the following. I've gone ahead and downloaded a copy of the latest-to-date version of the CoC RFC and the CoC documents and attached them to this email. I'm sure you are aware that you should be able to prepare specific comments and then use `git format-patch` to sign any patch you wish applied, then submit them over email. The patches could later be applied with your signature to the git repo. All of which can be done without interacting with GitLab. I do not believe there are any other relevant outstanding technological hurdles in your way at the moment. Thus, ensuring that no one is trying to stifle any objections to anyone's proposal. As for the lengths of some CoC sections you disagree with, I believe the above method will suffice in proposing their amendment in detail. Please, keep in mind that the CoC RFC is not about amending the current CoC but towards its distribution-wide adoption. That simply means that the new and amended version after your MR is the one that is going to be enforced distribution-wide.
Note the currently proposed Code of Conduct would directly violate the CoC from my MR that contains the following:
Use concise and clear language The current CoC RFC only links to the current CoC document and adopts it across the distribution. In no way can this be considered that the current CoC is violating any potential future version of itself. Nor can it be interpreted that the current CoC RFC is somehow preventing future amendments to the CoC.
The RFC does not give the option of an edited version of the Code of Conduct being adopted. The RFC states that the Code of Conduct "is hereby officially adopted in its current form". Hence the RFC is about adopting the *current* version of the Code of Conduct, which I object to. Furthermore, having the sentence "is hereby officially adopted in its current form" in the RFC means that when the RFC is merged, that would be the act of adopting it. It does not make it impossible to amend the CoC document itself. Nor does it prevent other documents from superseding it at a later date. It could just as easily be updated in place, replaced or retired by a follow-up RFC. I think that's the whole point of RFCs.
To me, this completely resolves the situation by arriving at the same outcome that you desire but perhaps not in the chronological order you intend. I do feel that the chronological order is of little importance to the end goal of having a distribution-wide CoC. However, I do fully believe the CoC can be improved upon. But I do not think filibustering its adoption will accomplish that. We have to start somewhere. I think a lot of people share the opinion that this RFC CoC is the place to start. And the act of adopting distribution wide it will also stimulate more people into making it better. Finally, and I would really like to avoid a quarrel over this, about your last argument:> If only one person in a team of dozens sees this as important enough to
work on, perhaps it is not important.
I'm sure you know better than most that Arch Linux comprises a relatively small set of people working on multiple projects each. Statistically, that would leave many people being the only person working on any one thing. I'd hate to learn that you are of the opinion that such work is not important. I'd assume you meant something else. That is, of course, not mentioning the self-defeating nature of that argument, given you are, to my knowledge, the only person working at the moment to prevent the RFC in question from being adopted. I'd like to say, and I'm sure many will agree, that yours and David's work is truly important and the number of people doing it should not diminish it. In this light, I hope we can come to a compromise that would get things moving again in a constructive direction towards us having a distribution-wide CoC. -- Regards, Konstantin P.S.: About the CoC itself, "concise" and "clear" are not synonyms and when it comes to communication they are very hard to attain together lots of times. In fact, it is precisely because Arch Linux reaches so many people with different backgrounds and understanding of English around the world that the balance between concise and clear is not so straightforward to achieve. If we went the route of putting too much emphasis on being concise, we would lose a lot of clarity as we would depend on many different people understanding a tiny subset of terms and their specific English connotations and interactions. So I think being a bit more verbose will help more people actually truly understand the core intention and meaning of the CoC better. BUt that is a different discussion altogether.