EthicalSource
Thoughts and proposals on conduct, diversity, and enforcement
As a collaborator of Homebrew Cask, I would like to offer some considerations on version 4.0 of the Contributor Covenant. Core maintainers @rolandwalker and @vitorgalvao might also wish to offer their thoughts.
After we first adopted the Contributor Covenant in February, I submitted some improvements that brought our CoC to v3.0b with caskroom/homebrew-cask#3112.
Unfortunately, I neglected to report back to this repo, causing #3112 to be effectively reverted when we updated the CoC to the latest upstream with caskroom/homebrew-cask#4055.
3.0b had introduced changes that are, in my opinion, quite desirable. Some of them were stylistic, others substantial. In this issue, I would like to focus on the latter, and start a discussion around the option to merge them here.
On conduct
To begin with, I would like to propose a new clause and an amendment, both originally included in #3112.
The new clause concerns internal communications. From our CoC v3.0b:
We provide constructive feedback […]. We are considerate of the effort of others. We are tactful when we provide criticism, and graceful when we face it.
While this “common courtesy” clause connotes a personal opinion on communication style, it also offers some protection from harassment; in particular, it catches attempts to bypass the CoC by being selectively tactless or brutal with specific individuals.
(I expect such strategies to be uncommon in projects that may wish to use the Contributor Covenant —due to size, public records, and collaboration being remote— but prevention is a cheap convenience.)
The amendment expands the set of categories explicitly included in the diversity statement. Again from our CoC v3.0b:
We extend courtesy and respect to everyone who volunteers their labor for this project. We welcome and encourage contributors regardless of their background or attributes including, but not limited to: ability or disability, age, culture, ethnicity, gender identity or expression, experience, national origin, physical or mental difference, politics, race, religion, sex, sexual orientation, socio-economic status, and subculture.
Declaring that there must be no x-based discrimination, regardless of x, is fundamental; optimistically, it could even be sufficient.
However, if we wish to enumerate “protected” categories, it is desirable to include as many as feasible: the intent of such a list is not to define who is protected and who is not, but to offer reassurance (in the form of a clear guarantee) to those who belong to the most frequently discriminated categories.
On enforcement
I am persuaded that procedural concerns should not be included in a Code of Conduct.
In #4, @phinze argues that excluding them exposes a CoC to easy criticism along the lines of “this is just a gussied up be excellent to each other statement”. I would suggest that “a gussied up be excellent to each other statement” may be a good solution for the CoC of a small online community: a qualifying pledge made by contributors.
There are legitimate reasons to strive for a comprehensive policy, but I suspect that turning the CoC into one would ultimately be detrimental. Policies have the unfortunate requirement of being quite exacting.
Consider the following statement from CoC v4.0:
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. Project maintainers who do not follow the Code of Conduct may be removed from the project team.
While this clause is well-intentioned, I feel that its directives are too vague to be effective: it states that a violator may be removed, but specifies neither who has the right to finalize this decision, nor the criteria and procedures to do so.
A fuzzy policy enforced within the soft, informally defined power structures characteristic of most OSS projects would merely legitimize whatever the leaders wish to do. In starker terms, I am afraid that it would have no effect.
For the policy to be effective, we would need to define clear guidelines that could be applied in a wide variety of contexts and cases. A daunting task that seems very prone to mistakes, pernicious quibbles, and deliberate neglect.
My suggestion would be, quite simply, to exclude enforcement language and let project managers act on the basis of the Code of Conduct to which they pledge.
+3, though perhaps this should be three separate issues.
With regard to any form of enforcement clause: this is different in kind than the rest of the statement – it is less universal. As different projects have different enforcement needs, defining that policy here will tend to limit uptake of the CoC.
With regard to the current specific enforcement clause, it is probably too vague. Legal documents are not really English or (choose your favorite language), though they appear to be. They are more like code, and the legal system is the compiler.
Laying out a process of termination definitely steps into the territory of legalities, but the compiler tends to choke on anything not written by a lawyer. For example, under US law, a person has certain inherent due-process rights. If an enforcement process abrogates those rights, then the enforcement clause may be unenforceable. And if one clause in a document is bad, then the whole document may be void unless something called a "severability clause" was included.
You would have to get a lawyer to explain the whole can of worms; I only know that it is a can of worms. Without an enforcement clause, I believe it is clear that contributors serve "at the pleasure of" the project leader/s.
While this clause is well-intentioned, I feel that its directives are too vague to be effective: it states that a violator may be removed, but specifies neither who has the right to finalize this decision, nor the criteria and procedures to do so.
A fuzzy policy enforced within the soft, informally defined power structures characteristic of most OSS projects would merely legitimize whatever the leaders wish to do. In starker terms, I am afraid that it would have no effect.
For the policy to be effective, we would need to define clear guidelines that could be applied in a wide variety of contexts and cases. A daunting task that seems very prone to mistakes, pernicious quibbles, and deliberate neglect.
I believe this is exactly what is going on in the opal.rb project. :disappointed:
