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.
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.
On Sat, Oct 09, 2021 at 09:17:05PM +1000, Allan McRae via arch-dev-public wrote: 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. 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
On 9/10/21 10:07 pm, Alexander Epaneshnikov wrote: 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
Resending PGP signed. On 09/10/2021 16:15, Allan McRae via arch-dev-public wrote: 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
-- Regards, Konstantin [1] - https://www.grammarly.com [2] - https://www.grammarly.com/blog/engineering/category/nlp-ml/