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.