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

Konstantin Gizdov arch at kge.pw
Sun Oct 10 11:30:28 UTC 2021

On 09/10/2021 16:15, Allan McRae via arch-dev-public wrote:
> On 9/10/21 10:07 pm, Alexander Epaneshnikov wrote:
>> On Sat, Oct 09, 2021 at 09:17:05PM +1000, Allan McRae via arch-dev-public wrote:
>>> I am objecting to this RFC being accepted, as that would mean adopting a
>>> CoC I consider substandard to the point of being unacceptable.  The
>>> ability to update it after does not change this situation.
>> as far as I know the current version of CoC has been applied to other parts
>> of the distribution for a long time.
>> this rfc only makes this application visible and official.
> I do not consider "it has been used elsewhere" a justifiable reason to
> officially adopt a policy document.  If the document can not stand on
> its own merits, it should not be adopted.
I have not seen anyone else agreeing with you on the point that the
document cannot stand on its own merits. Correct me if I'm wrong. (more
on this point at the bottom of my email)
>> thus, I think that the correct option is to separate the concept of consent
>> to the use of CoC and the text of the CoC itself.
> The RFC does not separate these. The RFC specifically states what CoC
> will be adopted on acceptance.  The proposed CoC text is explicitly tied
> to the RFC.  Hence my objection.
Correct. And this is why we've all taken to heart your input and
arguments, and tried to accommodate you with reasonable and actionable
compromises. You've refused all of them.
>>> If it is agreed that an edited CoC is needed for this RFC to be
>>> accepted, I can prioritise finishing my suggested edit, or equally help
>>> edit any other proposed variant.
>> the problem is that I and, as far as I understand, other people
>> participating in this thread see no problem with changing the text of CoC
>> after the adoption of this RFC which just makes CoC an official part of
>> our community, and also clearly describes how to change CoC's text.
> As far as I can tell, no-one has disagreed that the CoC needs improved.
>  But as you say, responses so far indicate that several team members are
> willing to accept a policy document even if it needs fixing. I believe
> the changes needed are so large that I am unwilling to accept adopting
> the current document.
That is not correct. No-one has agreed that the CoC *needs* to be
improved before this RFC is accepted. Even further. Some of us have only
agreed that it could potentially be improved, but not that it definitely
should or needs to. Furthermore, I do not think we all agree with the
direction of that potential improvement either. Nothing is stopping
anyone from making any large or small changes to the CoC document.
>>> Again, I'll note that my objection to this RFC is not tied to my
>>> specific submission.  It is tied to the current version of the CoC being
>>> unacceptable.  My edit may be considered equally unacceptable for adoption.
>> to be honest, I absolutely cannot understand why you think CoC is
>> unacceptable.
>> in my opinion, the problems with the size of the text and with its depth
>> do not deserve such a low rating.
>> also, if it helps, I and a few other friends of mine, whose English is not
>> so good, read the current version of CoC and did not find any problems
>> with understanding it's text.
> I am a scientist, so like to rely on actual measurements rather than
> anecdotes.
I am a scientist too. So what?! I really would rather not have this sort
of debate where we start to claim who we are instead of argue the points.
> http://www.roadtogrammar.com/
> CEFR Level: CEF Level C2  (highest category)
> https://readabilityformulas.com/
> Flesch Reading Ease scored your text: difficult to read.
> Gunning Fog scored your text: difficult to read.
> I'm glad your friend's English ability is higher than they (you?) think
> it is.

You are judging the whole value, quality and perception of a document
based on a single number computed by a formula. This is not scientific.
It is actually frowned upon in science to reduce a whole bunch of
metrics to a single number.

So let's give some more context to this. Yes, the Flesch readability
score of the current CoC is about 38 +/- 3 depending on your choice of
provider. That puts it at grade-12 or first-year-college reading level.
However, the overall quality of the text in terms of its use of correct
terms, value to reader and being informative is much higher. One such
metric is the Grammarly quality score [1], based on multiple metrics
(word count, number of unique words, number of rare words, number of
sentences, avg. length of sentences, avg. reading time, avg. speaking
time, etc.). On top of that, the Grammarly score is more broadly
applicable because it is context aware due to using the latest in NLP
[2] techniques able to pick up on meaning, direction, focus, clarity and
more. The score puts the text at 84/100. Which is pretty good. Does that
make me win the argument? No, it does not. Because again it's a single
number. I can imaging this sort of thing can go on for very long, where
each of us proposes our favourite test to prove our point. That's not
going to solve any issues though.

This argument, as it is proposed, is pointless to the RFC in question
because the CoC will never  be perfect. Even if we get a higher score on
readability and achieve 100/100 on some other scoring function, the CoC
document would still be subject of improvement. Even then, we could just
as easily change "our/the standard" and not be satisfied again. None of
these metrics check how the CoC reflects on what we wish to say. No
metrics can.

We are trying to create a policy document. The CoC is sufficient when it
comes to doing its job of explaining the general and some specific
points related to the way people should conduct themselves on our
platform. I think most of us agree on that. However, in order to serve
any such purpose, it needs to first be adopted and not endlessly delayed
because it is perhaps too long or is not 5-grade-level readable.

The latter are not the main metrics we are optimising. Nor have we set
any sort of standard for them, nor have we even agreed on the metrics we
should use when judging such texts in the first place.

> Allan

[1] - https://www.grammarly.com
[2] - https://www.grammarly.com/blog/engineering/category/nlp-ml/

More information about the arch-dev-public mailing list