Flesch–Kincaid Readability Test FAIL

[even-dave]

When I throw the text of the covenant into a Flesch–Kincaid readability test for English, it comes out with a Flesch grade score of 19.58. This means that this text is understandable by college graduates but not by others with less education.

Considering that the covenant should itself be inclusive regardless of education the readability test begs otherwise.

You can try it yourself here: https://www.online-utility.org/english/readability_test_and_improve.jsp

To me this is a very serious problem because, in my honest opinion, it is the less educated that require the greatest understanding. The text needs to be made simpler for more people to understand it.

If you want people to behave in a certain way, you need them to understand you first. That is very important. The concepts in the covenant might be understandable by you, but it is completely pointless if nobody else gets it, or you are cutting out the people who need guidance the most.

Some simple changes might be: Shorter sentences. Using less complicated words.

As an example (though just my 2c): "Using welcoming and inclusive language" -> "Be friendly." "Being respectful of differing viewpoints and experiences" -> "Respect everyone." "Gracefully accepting constructive criticism" -> "Learn from others." "Focusing on what is best for the community" -> "Stay on topic." "Showing empathy towards other community members" -> "Listen to others."

When you simplify it, it makes it better for everyone.

Not to piss on anyone's fire, IMHO this document needs a whole rewrite. :-)

[even-dave]

Just as a follow up to this, the US Federal Govt. has a web page dedicated to plain language. It has guidelines how to write plainly. An amazing resource.

https://www.plainlanguage.gov/guidelines/

Maybe someone should take a look before Donald Trump redefines what plain language is. :-P

[tieguy]

Hi, @even-dave- thanks for pointing this out, and trying to get constructive/objective with your analysis and suggestions.

FYI, I'm not a maintainer here, just a drive-by reader who noticed this issue and is obsessed with legal readability.

As to the specifics:

How best to propose readability changes? Definitely agree that (if nothing else) at least some of the very long sentences could be broken up, so there is some progress that could be made here. @CoralineAda would you be willing to accept suggestions that are focused purely on readability? If so, what's the best way to suggest and discuss those changes? One sentence/section per PR, or start with an issue first, or everything in one issue, or...?

For example, I've got a local copy of the "Our Responsibilities" section that cuts the Fleisch-Kinkaid from over 23 to under 16, and that I think does not lose any critical nuance. I'm not sure the best way to get your eyeballs on it (or even if you'd be interested).

Move some details out of the document? I'm grateful that the issue contained some concrete suggestions, but (at least to my inexpert eye) some of them trade off readability for important nuance. For example, lots of people's definition of being "friendly" omits inclusivity - they don't know, or don't care, that "hey guys" can sound friendly to, well, guys, but not necessarily to everyone else. Because of that, dropping inclusivity in favor of "mere" friendliness could make the document less effective.

With that problem in mind, I wonder if it would make sense to either link out to more educational information, or maybe even have an annotated version (like this)? If there were some way to preserve (or even enhance) the details outside of the core document, that might allow some additional simplification while keeping the nuance available for those who want (or need) to dig in some more.

P.S. Dave, let me offer some constructive criticism - opening with all-caps FAIL and closing with "this document needs a whole rewrite" is somewhat rude to the authors who have put in a lot of work on this. In the spirit of a healthier open source, and in the spirit of this document in particular, I'd politely suggest that a more positive approach (open with "readability could be improved" or "suggestions for readability"; close with "I'd be happy to offer more suggestions if that would be helpful") might yield better results and happier humans.

[even-dave]

The average Kincaid grade level for US adults is between 7-9. So 16 is still too high. 13-14 year old kids can participate in open-source.

Having an annotated version IMHO opinion is just complicating things. If it can be writtten in plain language do it. Everybody will understand it regardless. An annotated version just creates another level of unnecessary obscurity.

It doesnt matter how we look at it, readability is important, and this document does not cut it for it's broad target audience. A rewrite is required.

This is not to say the efforts are entirely wasted, because what we have from the current document is intentional function, all we need now is functional form. We are half way there.

@tieguy I have read your public constructive criticism, and I understand your good intentions from your offer, but I think you are being overly critical, so I will respond with another perspective, though I am neither wanting to troll nor start a flame war. I do this because I think it is also important for the project. The more perspectives the better.

First of all I didn't open in caps, only one word at the end of a sentence. It is probably because I write server software and I would log a FAIL in all caps so that it would be noticed in a large log full of 1000's of lines. It is more of an established work habit than a conscious attempt to be rude. A seasoned coder would recognise this. Have you ever seen unix software services start up? They give a OK or FAIL. Was it misplaced? maybe? but github is a place for code. I would never write a full sentence in caps.

Secondly, I added a smiley ":-)" at the end to convey that no harm was meant by the message. More of a "Oh no" moment. The whole purpose of emoticons is to clarify human emotional intent in text messages. When something could be misinterpreted you use one. It is a an established norm in the computing industry.

Thirdly, I also used "Not to piss on anyones fire". That might be foreign to you. It is a colloquial expression figuratively meaning "I am sorry if this has upset your efforts, I don't want to disrupt your fervor for the project". Literally it comes from: "If you have spent a long time rubbing sticks together to make a fire, I do not want to destroy your efforts by putting it out, keep going". This is quite the opposite of what you are offering to give criticism for.

I am Australian by birth, we have ways of saying things. In the spirit of the document, respecting the culture of others that you do not understand is also a big part of it. You also might learn something.

If you have a problem with understanding something you could simply ask for clarification. "

"What did you mean by that?"

As opposed to a "shoot first, ask questions later" kind of approach. That means instead of immediately offering criticism (constructive or not) asking for clarification should be attempted first.

I know it may be hard, some people live in a shoot first world, others do not. BTW I am not asking you to change, just offering my constructive criticism in kind. You can do what you want, I will do the same.

Sometimes the truth hurts. It seems you are a lawyer, I would expect that you understand that better than others. I would also expect you to see the detail between a single uppercase word at the end (not opening) of a whole sentence of mixed caps. But maybe only Australian lawyers are so observant? I really don't know, these are my cultural expectations.

If I see a truth, I say it for what it is, it is a big part of Australian culture. Nobody should be obliged to appease people whom the truth may negatively impact, though in my own cultural way I feel I have tried to lessen any impact.

Here is a thought: Are you trying to suppress my culture? Not for a second did I think I was not being positive or a caring helpful human being. So now who gets to choose in what form "being positive" should be in? Your culture or mine?

There is not an easy answer to that. Working with people across the planet is complicated and there are differences. Even when we speak the same language. Try explaining to the majority of the world that "pineapples" are not called "ananas". The planetary opinion by the numbers outweighs our anglo cultural truth.

This is why we need this document as a guide to help us all get along in a mixed up world. The easier it is to be understood by all the better. We are humans, we all make unintentional cultural mistakes and hopefully we will continue to make them. A homogeneous world would be inhuman.

Embracing and seeking understanding rather than immediately correcting people on your expectations is the right direction.

But that is just my cultural opinion no offence meant or taken. :-)

[even-dave]

lots of people's definition of being "friendly" omits inclusivity

IMHO being friendly does not strictly omit inclusivity. To be simply friendly is a human acknowlegement of social existence on the simplest level. That in itself is a type of inclusivity. Inclusivity has many levels from being acknowleged in presence to being intimate in relation.

In context of the document I think the level of inclusivity aimed for is to allow others to freely participate in harmonious collaboration.

"Using welcoming and inclusive language"

To be sematic about it, using "inclusive language" in itself does not necessarily mean that you are allowing others to participate. Words must be followed by action.

IMHO "Be friendly." covers it quite well, as it invokes a simple adjective/attribute to develop a more inclusive relationship. Inclusivity is created and invoked further by initially being friendly.

It is the first step to commit to harmonious collaboration, because in the end that is the objective of the document. (correct me if I am wrong)

The other themes/steps in the document build on the first to reach a more complex objective.

I know being clear and simple is not easy by all means, don't get me wrong. It is an art, and I am not a literary expert, poets are quite good at being succinct.

However I am thinking like a unix guy, I am looking for the elegant solution.

Write something that does one thing and do it well. Write it so that it works well with the next thing.

So I think the strategy to get there is to break down the problem into smaller simpler bites.

Do you see what I mean?

[CoralineAda]

I’m open to structural changes for readability but the language the Covenant uses is necessarily nuanced and will not change for this purpose.

On Jul 19, 2018, at 12:56 AM, Luis Villa notifications@github.com wrote:

Hi, @even-dave- thanks for pointing this out, and trying to get constructive/objective with your analysis and suggestions.

FYI, I'm not a maintainer here, just a drive-by reader who noticed this issue and is obsessed with legal readability http://lu.is/blog/2012/08/19/a-quick-note-on-conspicuous-text-also-known-as-all-caps/.

As to the specifics:

How best to propose readability changes? Definitely agree that (if nothing else) at least some of the very long sentences could be broken up, so there is some progress that could be made here. @CoralineAda https://github.com/CoralineAda would you be willing to accept suggestions that are focused purely on readability? If so, what's the best way to suggest and discuss those changes? One sentence/section per PR, or start with an issue first, or everything in one issue, or...?

For example, I've got a local copy of the "Our Responsibilities" section that cuts the Fleisch-Kinkaid from over 23 to under 16, and that I think does not lose any critical nuance. I'm not sure the best way to get your eyeballs on it (or even if you'd be interested).

Move some details out of the document? I'm grateful that the issue contained some concrete suggestions, but (at least to my inexpert eye) some of them trade off readability for important nuance. For example, lots of people's definition of being "friendly" omits inclusivity - they don't know, or don't care, that "hey guys" can sound friendly to, well, guys, but not necessarily to everyone else. Because of that, dropping inclusivity in favor of "mere" friendliness could make the document less effective.

With that problem in mind, I wonder if it would make sense to either link out to more educational information, or maybe even have an annotated version (like this https://www.mozilla.org/en-US/MPL/1.1/annotated/)? If there were some way to preserve (or even enhance) the details outside of the core document, that might allow some additional simplification while keeping the nuance available for those who want (or need) to dig in some more.

P.S. Dave, let me offer some constructive criticism - opening with all-caps FAIL and closing with "this document needs a whole rewrite" is somewhat rude to the authors who have put in a lot of work on this. In the spirit of a healthier open source, and in the spirit of this document in particular, I'd politely suggest that a more positive approach (open with "readability could be improved" or "suggestions for readability"; close with "I'd be happy to offer more suggestions if that would be helpful") might yield better results and happier humans.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ContributorCovenant/contributor_covenant/issues/547#issuecomment-406163422, or mute the thread https://github.com/notifications/unsubscribe-auth/AABXDPMq7oaTalI-dW2hO-G4UHIazNsyks5uIB-pgaJpZM4UvhS8.

[even-dave]

Sorry coralline that statement doesn't make sense, can you please explain what you mean by structural change? And isn't nuances something to avoid? Because nuances create fog in meaning. Let's make sure we are talking about the same thing.

http://www.dictionary.com/browse/nuanced

Subtle shades of meaning are not a good thing when you are trying to communicate in plain language to the widest audience as possible.

IMHO the necessity for nuance should be avoided at all costs. It is contradictory to the essence of the document. Nuance creates misunderstanding not fosters understanding.

[CoralineAda]

Nuance is essential. Words are complex, and human behavior is complex. The language of inclusivity and diversity is necessarily complex.

The average intelligence and reading level of the developers in the communities that produce open source makes the FKRT irrelevant in my opinion.

On Jul 19, 2018, at 11:53 AM, even-dave notifications@github.com wrote:

Sorry coralline that statement doesn't make sense, can you please explain what you mean by structural change? And isn't nuances something to avoid? Because nuances create fog in meaning. Let's make sure we are talking about the same thing.

http://www.dictionary.com/browse/nuanced http://www.dictionary.com/browse/nuanced Subtle shades of meaning are not a good thing when you are trying to communicate in plain language to the widest audience as possible.

IMHO the necessity for nuance should be avoided at all costs. It is contradictory to the essence of the document. Nuance creates misunderstanding not fosters understanding.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ContributorCovenant/contributor_covenant/issues/547#issuecomment-406344419, or mute the thread https://github.com/notifications/unsubscribe-auth/AABXDA4BUfSbCwafLizSwnU0BmDso6zdks5uILmngaJpZM4UvhS8.

[CoralineAda]

Maybe it would help to be concrete. Can you give an example of language in the CC that you consider too complex or too nuanced?

On Jul 19, 2018, at 11:53 AM, even-dave notifications@github.com wrote:

Sorry coralline that statement doesn't make sense, can you please explain what you mean by structural change? And isn't nuances something to avoid? Because nuances create fog in meaning. Let's make sure we are talking about the same thing.

http://www.dictionary.com/browse/nuanced http://www.dictionary.com/browse/nuanced Subtle shades of meaning are not a good thing when you are trying to communicate in plain language to the widest audience as possible.

IMHO the necessity for nuance should be avoided at all costs. It is contradictory to the essence of the document. Nuance creates misunderstanding not fosters understanding.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ContributorCovenant/contributor_covenant/issues/547#issuecomment-406344419, or mute the thread https://github.com/notifications/unsubscribe-auth/AABXDA4BUfSbCwafLizSwnU0BmDso6zdks5uILmngaJpZM4UvhS8.

[johana-star]

@coralineada I believe that readability is important, but I also believe that revising the document to a lower grade-level introduces a risk of creating subtle, breaking changes.

So, my suggestion is to keep the English translation as is, but also create a Basic English or Simple English translation.

@even-dave would you be willing to take on the heavy lifting of translating the Contributor Covenant into Basic English or Simple English?

[even-dave]

Nuance is essential.

Maybe when you are writing to impress a university level audience. But this is not a thesis, nor a legal document, it is a community agreement. The community must understand.

Can you give an example of language in the CC that you consider too complex or too nuanced?

The whole document, throw it in a Kincaid test. That is a quantifiable measurement of complexity. I saw a online tool called typely that measures readability as you type and highlights problems. https://typely.com I have not fully tried it.

Also go ask your average budding 13 year old coder what "covenant" means. Also ask someone who has English as a broken second language living in their home country. Talented coders who struggle to participate. I think you would be surprised.

@strand Maintaining 2 documents is a PITA, it can also create division. Subtlety of meaning is dangerous. Also for people who do not have English as a mother tongue (more ESL in open source than native English speakers) it can lead to confusion. I live in Europe, I see the struggle the coders have. I strongly believe a single plain English variant will suffice.

would you be willing to take on the heavy lifting of translating the Contributor Covenant into Basic English or Simple English?

I can try, my time is limited like most, so no deadlines. It is open source anyway. Also it is important that it is checked by a diverse audience and discussed openly. If there are important subtle meanings that should not be subtle because they are truly important, they also need to be openly discussed out clearly. Nuances need to be explained. Just because you understand it doesn't mean others do.

I am also not a language expert but I am willing to learn something new. I really have no idea what the outcome will be at this moment. But that is kind of exciting. Reaching out to ESL educators should also be considered. I am sure there is a wealth of knowledge that can be tapped into. For a coder it is an unusual project.

[CoralineAda]

ESL is not an issue really, given that Contributor Covenant has been translated into 28 languages?

On Jul 19, 2018, at 1:39 PM, even-dave notifications@github.com wrote:

Nuance is essential.

Maybe when you are writing to impress a university level audience. But this is not a thesis, nor a legal document, it is a community agreement. The community must understand.

Can you give an example of language in the CC that you consider too complex or too nuanced?

The whole document, throw it in a Kincaid test. That is a quantifiable measurement of complexity. I saw a online tool called typely that measures readability as you type and highlights problems. https://typely.com https://typely.com/ I have not fully tried it.

Also go ask your average budding 13 year old coder what "covenant" means. Also ask someone who has English as a broken second language living in their home country. Talented coders who struggle to participate. I think you would be surprised.

@strand https://github.com/strand Maintaining 2 documents is a PITA, it can also create division. Subtlety of meaning is dangerous. Also for people who do not have English as a mother tongue (more ESL in open source than native English speakers) it can lead to confusion. I live in Europe, I see the struggle the coders have. I strongly believe a single plain English variant will suffice.

would you be willing to take on the heavy lifting of translating the Contributor Covenant into Basic English or Simple English?

I can try, my time is limited like most, so no deadlines. It is open source anyway. Also it is important that it is checked by a diverse audience and discussed openly. If there are important subtle meanings that should not be subtle because they are truly important, they also need to be openly discussed out clearly. Nuances need to be explained. Just because you understand it doesn't mean others do.

I am also not a language expert but I am willing to learn something new. I really have no idea what the outcome will be at this moment. But that is kind of exciting. Reaching out to ESL educators should also be considered. I am sure there is a wealth of knowledge that can be tapped into. For a coder it is an unusual project.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ContributorCovenant/contributor_covenant/issues/547#issuecomment-406374684, or mute the thread https://github.com/notifications/unsubscribe-auth/AABXDPY5pb0-GwG-0b-PQwJcteIA3CQFks5uINJLgaJpZM4UvhS8.

[even-dave]

In fact "covenant" is even possibly the wrong word. When I think about it this document is truly non binding in a global sense. Maybe a international lawyer can add their 2c. I think it is arguably more of a ethical commitment, a code of conduct, code of ethics, or a global consise of commonality in behaviour to be upheld but not strictly an enforceable agreement. There is a difference.

As a systems admin I uphold a professional code of ethics. https://www.usenix.org/sites/default/files/code_of_ethics_poster_english.pdf

Many professions I know have similar codes of ethics, doctors, lawyers, engineers etc.

In my eyes this is more appropriate, but of course it needs to be targeted to the audience, and the global OSS community is broad.

[even-dave]

ESL is not an issue really, given that Contributor Covenant has been translated into 28 languages?

Can you confirm that those translations contain the subtle English nuances of your original document? That is when things get really tricky because they are not in a language you can fluently understand.

If I had a choice I would have all contracts written originally in German. German is a very precise language. No mincing words. Of course there are exceptions in many languages, but in German there is less interpretation. Those guys have a word for everything.

But you know what, many Germans struggle to understand English humor. They miss the nuances. My partner is native German speaker, watching a comedy in English with her his difficult, and her English is excellent compared to the local population because she lives with me and speaks English everyday.

[even-dave]

Another question? Are those translations understandable by their respective general native populace or do you also need to be a college graduate to participate in OSS in those countries as well? Elitism needs to be eliminated, not encouraged.

I think these are valid points.

[even-dave]

@CoralineAda Did you define an audience before you started to write the CC? If not, it is very important that we do this first to write a plain language document. It will also help to define what "inclusive" really means because at the moment it appears that, despite intentions, it is not really inclusive as it excludes individuals with a lower level of education.

Federal Plain Language Guidelines, March 2011, Rev. 1, May 2011 I. Think about your audience One of the most popular plain language myths is that you have to “dumb down” your content so that everyone everywhere can read it. That’s not true. The first rule of plain language is: write for your audience. Use language your audience knows and feels comfortable with. Take your audience’s current level of knowledge into account. Don’t write for an 8th grade class if your audience is composed of PhD candidates, small business owners, working parents, or immigrants. Only write for 8th graders if your audience is, in fact, an 8th grade class. Make sure you know who your audience is – don’t guess or assume.

https://www.plainlanguage.gov/media/FederalPLGuidelines.pdf

So let us not assume or guess.

I am going to be broad here and and say open source project as opposed to a open source software project. Because open source (OS) is not just about software. It can also be hardware, it can also be a collaborative document like this one. I could see school children collaborating in OS on their own projects of interests. What an amazing way to instill global tolerance and acceptance in humans everywhere. To what OS can be applied is diverse.

So with this OS definition in mind:

1. Open source is for all people. Define all people. 1.1 Age - All ages??? 1.2 Sex - All orientations 1.3 Nationality - All nationalities 1.4 Race - All races 1.5 Creed - All faiths 1.6 Disabilities - ??? 1.6.1 Mobility Impaired 1.6.2 Hearing Impaired 1.6.3 Vision Impaired 1.6.4 Intellect Impaired - All intellects???? 1.6.4.1 Educational level. a) Can a person with no education start or contribute in a OS project? b) Can a person with a primary education start or contribute in a OS project? c) Can a person with a secondary education start or contribute in a OS project? d) Can a person with a tertiary education start or contribute in a OS project?

etc.. Hopefully you can see what I am getting at, by defining the audience it is going to make it easier to write for them plainly. In fact it is the first step.

Now I am prepared to try and write a plain document, but in no way should I alone define the document scope. This is OS, everyone has a right to have a say on the scope.

What I think should happen is that we create a simple survey together and ask as many OS projects/contributors as possible who they think can contribute to open source in general. And be very explicit about general. We should not be asking projects whom they would like to contribute to their individual projects, but a more general whom do they think can participate in OS. Because that is the real sentiment that is sought to define the audience of a general OS contributor guidelines document.

That survey is going to be needed to be translated and distributed globally.

Once we have that information and extract the "lowest common denominator" we can define the audience based upon it and move on with formulating the document.

Writing simply is difficult, but not impossible.

[even-dave]

After some serious thought before I commit down this path I feel there is so much wrong with this covenant:

1. The legality (globally unenforceable)
2. The name "covenant" because of see 1. above.
3. The non-applicableness of defining attributes of humans in relation to projects. If OS is for everyone sex, race, creed, etc.. should be irrelevent to projects anyway. i.e. Everyone is everyone, no need to make distinctions about it.
4. The lack of true inclusiveness by design (age/intellect disparity in readability).
5. No mechanism for due process. The enforcer enforces.

A set of pointers of how people should behave with one another in OS is fundamentally not a bad idea.

But I think what the outcome of what I am proposing will fundamentally break the "covenant" from what it now is:

An elitist and arbitary agreement of rules where OS project owners can boot people without due process because the legally unenforcable and misleading agreement says they can.

to what I think it should be:

A truly inclusive set of guidelines of how everyone should try and behave nicely with each other in OS without anybody needing to wield individual power on who is or who isn't allowed to play.

After I am done it will no longer be a "covenant" and it will be stuck in a project with the wrong name.

I feel a general "etiquette" of open source is required rather than a misleading hierarchical stick.

I think if I tackle this I will need to start completely fresh.

The fundamental difference is guidelines instead of rules.

There is a danger in this Contributor Covenant because it in itself being open source lulls the unobservant open source particpant into believing that it is a fundamentally well grounded project because it is open source. Open source is good right?!

On the surface I think most people would agree with it on how as humans we should harmoniously behave with one another. But if you truly fathom the covenants implications I feel it is nothing short of misleading and sets the wrong path of how open source should be.

I was nearly caught out. I hope others in the project can "see the forest for the trees".

[CoralineAda]

Thanks for your thoughtfulness, but I don’t plan on renaming or rewriting the Contributor Covenant. I have faith in its applicability and quality and it’s been very well received in the community.

On Jul 20, 2018, at 10:27 AM, even-dave notifications@github.com wrote:

After some serious thought before I commit down this path I feel there is so much wrong with this covenant:

The legality (globally unenforceable) The name "covenant" because of see 1. above. The non-applicableness of defining attributes of humans in relation to projects. If OS is for everyone sex, race, creed, etc.. should be irrelevent to projects anyway. i.e. Everyone is everyone, no need to make distinctions about it. The lack of true inclusiveness by design (age/intellect disparity in readability). No mechanism for due process. The enforcer enforces. A set of pointers of how people should behave with one another in OS is fundamentally not a bad idea.

But I think what the outcome of what I am proposing will fundamentally break the "covenant" from what it now is:

An elitist and arbitary agreement of rules where OS project owners can boot people without due process because the legally unenforcable and misleading agreement says they can.

to what I think it should be:

A truly inclusive set of guidelines of how everyone should try and behave nicely with each other in OS without anybody needing to wield individual power on who is or who isn't allowed to play.

After I am done it will no longer be a "covenant" and it will be stuck in a project with the wrong name.

I feel a general "etiquette" of open source is required rather than a misleading hierarchical stick.

I think if I tackle this I will need to start completely fresh.

The fundamental difference is guidelines instead of rules.

There is a danger in this Contributor Covenant because it in itself being open source lulls the unobservant open source particpant into believing that it is a fundamentally well grounded project because it is open source. Open source is good right?!

On the surface I think most people would agree with it on how as humans we should harmoniously behave with one another. But if you truly fathom the covenants implications I feel it is nothing short of misleading and sets the wrong path of how open source should be.

I was nearly caught out. I hope others in the project can "see the forest for the trees".

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ContributorCovenant/contributor_covenant/issues/547#issuecomment-406635367, or mute the thread https://github.com/notifications/unsubscribe-auth/AABXDLrepqNuBuA3h6q9q3SA3-ii3Endks5uIfbZgaJpZM4UvhS8.

[even-dave]

@CoralineAda Yes your faith seems entrenched. That is fine it is your project, renaming would be a PITA. It has been well recieved in some parts of the community no doubts, there is equal worthy criticism too. I hope you have taken that constructive criticism on board and acted upon it as well. As I said it lulls you into a false belief that this is what open source is about. I think it is not. I think many are duped in this false belief causing you to be more entrenched in your faith in this document. In my open source perception equality and hierarchy are mutually exclusive. I could be wrong. I could also very much be right.