[arch-dev-public] RFC Final Comment Period: Adoption of a distribution-wide Code of Conduct

Konstantin Gizdov arch at kge.pw
Fri Oct 8 11:39:34 UTC 2021

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.


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0006-code-of-conduct.rst
Type: text/x-rst
Size: 4459 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20211008/98d55a29/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: code-of-conduct.md
Type: text/markdown
Size: 14626 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20211008/98d55a29/attachment-0001.md>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20211008/98d55a29/attachment-0001.sig>

More information about the arch-dev-public mailing list