[RFC] [Draft] Adopt Code of Conduct

On Mon, Jan 4, 2016 at 4:06 PM, Anthony Ferrara <ircmaxell@gmail.com> wrote:

Thanks for bringing this to the table, Anthony. I am +1 because, while we're diverse on some axes, we are startlingly alike in others <http://www.facesoftheelephpant.com/archive>.

On 4 January 2016 at 13:06, Anthony Ferrara <ircmaxell@gmail.com> wrote:

I am definitely pro-this. Good thinking!

Although it's not required by our voting process, I think it might be a good idea to require more than a basic majority for adopting this. It feels like something we need broad buy-in on. Thoughts? Adam

Hi!

Looks to me like solution in search of a problem. I'm with PHP project since 90s, and maybe it is my biased view, but with all heated and sometimes very controversial discussions, people rage-quitting and swearing oaths to never have anything to do with PHP again, etc., that we have had over these years I can remember maybe a handful of instances where there were - at least in public spaces of the mailing lists - comments that may be suspicious within the framework described in http://contributor-covenant.org/version/1/3/0/code_of_conduct.md. Even in those instances, I'd be hard pressed to remember any instances that would constitute actual intentional harassment. Maybe I'm biased, but as it looks to me, we may have a lot of issues with discussions on the list and in general about how we conduct things, and there was a lot of critique about that over the years, but this does not seem to be the problem we have. Going into the specifics of the RFC, we can already do all things the CoC committee is proposed to do, and I don't remember any case where it was needed - i.e., where a commit had to be reverted or commit karma had to be revoked for harassment, over 20 years history. Was there such a case? If it happens that this is needed, we have mechanism to police commits & pulls. We do not have any mechanism for instituting bans (again, I don't remember us ever needing one - maybe my memory is faulty?) but I think such thing should not be done by 5 people. It should be an exceptionally broad consensus. That consensus would be especially hard to reach when, as RFC states, nobody but those 5 people (and, I assume, the author of the complaint) would not even know the details of the issue, and as the accused would be banned from wikis and mailing lists, thus unable to provide explanations or defend themselves, no semblance of due process can be preserved. If we ever need the procedure for such measures - which I highly doubt - it should be only performed with very broad consensus (minimum 2/3 with high quorum requirement so 4 people voting on holiday week-end couldn't pass such decision) and allow for the accused the chance to explain and provide their point of view.

On Mon, 4 Jan 2016 at 21:07 Anthony Ferrara <ircmaxell@gmail.com> wrote:

Perhaps cite the code of conduct as it would appear in the RFC body. We may decide to make changes to the text to better suit our project, or the linked site may go offline and it's nice to maintain a record of the proposed text. Sort of mixed feelings on this. I think mainly because we shouldn't need such a policy, let alone a "response team" to enforce it. The intent is unequivocally positive, and Eli's point makes sense. Absolutely not against it, maybe just a little sad we feel it's necessary. Maybe someone else's thoughts can capture my feelings better. I'll keep an eye.

On 01/04/2016 03:06 PM, Anthony Ferrara wrote:

Jumping back to the beginning of the thread as the tail of it at this point has veered off onto a rather pathetic pseudo-anarchist rant-tangent... I've had very mixed feelings about CoCs for a long time. Drupal went through its own rather contentious CoC process a few years back, and I was initially in the No camp. In the end, though, the devil is in the details and I am +1 to a CoC as long as it's a well-written one that doesn't jump to "innocent until proven guilty as soon as anyone thinks they might be offended, then we burn the witch". Such CoCs do exist, and suck, and we should have no part in them. On the whole, I find the Contributor Covenant a good CoC model although it is imperfect. My main issue, as noted by a few others and expanded on in the RFC, is the confidentiality/anonymity involved. I am a firm believer in the right to face one's accusers. (Yes, that "right" as defined in the US constitution is legally only binding on US legal bodies, and some may argue only the Federal government, but I firmly believe that as a general principle it should apply universally.) That's because the accused person MUST be allowed to present their side/interpretation/perspective, and to do so effectively they need to know what they're even accused of. Redacting the name of the accuser is ineffective, as if enough context is provided for the accused to respond at all it will, by nature, reveal the name of other people involved. If not, then the accused cannot provide any meaningful response. Not having anonymous complaints is exactly how we avoid (or at least minimize) the "secret cabal/star chamber/people have it in for me" factor. My other issue is that the RFC focuses on punitive measures rather than corrective measures. The tone here is very important, as we want everything related to a CoC to be cooperation-driven rather than penalty-driven. (That was one of the biggest complaints against the first draft of the DrupalCon CoC a few years back; the second draft, which was adopted, was worded much much better.) There is lots of prior art here, and I would strongly recommend reaching out to the Drupal Community Working Group or its counterpart with other major OSS projects for advice on how to strike a more positive spin. While the ban-hammer is the obvious tool, it's rarely the best and other approaches are often much more effective in the long run. (The Drupal CWG is responsible for managing and enforcing the Drupal CoC. I'd be more than happy to make introductions for anyone who is interested.) So on the whole, +1 in concept but needs some work before it's ready. To some of Stas' points: 1) Part of the point of a CoC is to signal that it's OK for someone to come in. There doesn't have to be a problem, yet, for them to still be valuable. They *could* be interpreted as "we have a problem and here's part of the solution", but could also be "we want to take an affirmative step before a problem happens". Hopefully the latter more than the former... 2) To the claim that "we're all equal now", that's hogwash. :-) PHP Internals may not have a formal structure or hierarchy beyond Release Managers, but because it's a group of more than 2 people there is of course an implicit, informal power structure. The best writeup on that front would be: http://www.jofreeman.com/joreen/tyranny.htm (It's talking about the feminist movement of the 60s, but the concept applies to just about every OSS project ever created. And any other volunteer group since forever.) A specifically named community working group / CoC Response Team / whatever you call it is a way to explicitly separate the addressing of misbehavior issues from that informal power structure, so avoid (or at least minimize) people with more "karma" (informal term here) getting an implicit pass. That sort of implicit tolerance has been very toxic in other communities (c.f. http://blog.randi.io/2015/12/31/the-developer-formerly-known-as-freebsdgirl/ for the most recent sad example). Having a formal process doesn't guarantee it doesn't happen, but it helps reduce it and provides a way to call out when it happens. Again, having the mechanism in place before it becomes an issue is a way to ensure it stays not an issue. 3) Stas, you claim that such a Response Team and process would be rarely used. I will not comment on its likely workload, however, I would submit that having a process to handle misbehavior that rarely if ever needs to be called upon is perhaps the best ringing endorsement of a community there can be. That is, if we do setup a Response Team or whatever, and they are incredibly bored in the job and never contacted, that's something to be proud of, not upset at wasted time. (If they're bored because no one trusts them to bring an issue to them in the first place then that's a very big problem but I'm trying to be optimistic here.) 4) Yes, much will depend on who the people on that team are. That's always the case. No process will protect you from incompetent people, and no group of really good people can protect you from a broken process. Additionally, I would note that there is absolutely zero correlation between a person's coding ability and their conflict resolution ability. That is, the people who are best for that role will probably *not* be the top coders, and that's OK, and probably a good thing. Separation of concerns. :-) --Larry Garfield

I don't think this is a good idea. the proposed code of conduct (contributor covenant) is extremly open to interpretation, as it is very subjective where harassment starts, what personal attacks are, if something is trolling, and i don't even want to see a discussion if something someone said is sexualized or not. We are in an environment here, in which people from various cultural backgrounds and mother tongues. What is understood is not always what was said (or meant) And frankly, I can recall more than one occasion where there have been things that I'd consider personal attacks, including declaring that i shouldn't be allowed to vote by Anthony, where till today i haven't seen an apology for. No seriously, this (to me) seems an attempt to create an instrument that can be used to discredit and silence others. I just have to look back on the whole dual-mode vote, where a hand full of us old-guys stood in conflict with a lot of the newer guys, including Anthonys "voting irregularities" mail, and i can see how a vote on who would be in the "response team" would swing, and how the vague code of conduct would be used afterwards. best regards, Peter Petermann On Mon, Jan 4, 2016 at 10:07 PM Anthony Ferrara <ircmaxell@gmail.com> wrote:

Peter Petermann ProtonMail: ppetermann@protonmail.com (encrypted / based in .ch) Email: ppetermann80@gmail.com - get my public PGP key from SKS Keyservers PGP Key: http://pool.sks-keyservers.net:11371/pks/lookup?op=get&search=0x0E6DBD675836A5C7

On Mon, Jan 4, 2016 at 10:06 PM, Anthony Ferrara <ircmaxell@gmail.com> wrote:

Anthony, a small suggestion: could we explicitly state the version of the linked Code of Conduct version (I know that we already explicitly linked to the version 1.3.0) and if we are explicitly targeting that version we could/should just include that into our own RFC verbatim, based on the feedback some people was confused by the introduction text on http://contributor-covenant.org/ (including me) I would also like to see in the RFC some explicit mention about what happens when this CoC gets a new version (obviously I'm in favor locking to this version and any upgrade should happen via the standard RFC process).

All, On Mon, Jan 4, 2016 at 4:06 PM, Anthony Ferrara <ircmaxell@gmail.com> wrote:

In response to significant feedback here and elsewhere, I have expanded the text of the RFC significantly. It now includes the text of the Contributor Covenant 1.3.0 as well as including verbage about updating it requiring an RFC. I included a vote requirement for course of actions of 4/5 of the CoC team. I also included content about the "Reasonable Person Test", explicitly stating that it shall be assumed that both parties are acting as reasonable people until proven otherwise by significant evidence. It also stipulates that reporting an incident does not excuse someone from the CoC (meaning victims are still bound to follow it, and are not excused from proper behavior because of a violation). I also made it explicit that potential actions should be a last resort, and that the CoC team should make every reasonable attempt to defuse the situation without having to resort to "punishment". I also removed the ability to remove commit karma from the team, instead including that in the "ban" category (meaning that the CoC team is no longer allowed to remove commit karma long-term without the action of internals@) Additionally, I added a line specifying that bans (temporary or permanent) should only be used in egregious cases. I added a section on transparency, Conflict of Interest (though this needs expanding) and accountability (giving internals@ the ability to "overturn" any action by the CoC team with a vote of 50%+1). I also made it explicit that accused people have a right to confidentiality as long as no action is taken by the team. I also added a section on appeals. Those are the changes to the RFC as it stands. Please review them. As to the comments in this thread, I won't reply to every one, but here are a few points I'd like to make. It's been mentioned that we may want to adopt a CoC, but it shouldn't "have teeth". I disagree here, as without an enforcement mechanism it basically is no different from where we are at today. Saying we should act reasonable is fine, but we need a method for what we are to do when one of us acts unreasonably. Additionally, as has been stated, requiring people to report publicly creates a barrier to entry. Many people will simply chose to leave quietly rather than report publicly. Simply look at the way people who speak out about harassment are treated in public to understand why. The point of the CoC is to create a safe place for everyone to contribute, not just those with thick skin. As to why the Contributor Covenant as opposed to another CoC or our own custom one, there are two reasons for this. First, it's a standard that's been adopted by a number of significant scale projects. Second, it saves us from having to bikeshed over every single word of a CoC. If there's another standard CoC that we should entertain, I'm happy to look at it. But I do not believe that we should create our own. As far as the conflict resolution process, that I am open to expanding or retracting as much as practical. I do think it's important to have, but would be happy to take advice from groups like Drupal who have done this before. To those that say this is a solution in search of a problem, it very well may be. But that doesn't mean it isn't important to do. You could say the same thing about smoke detectors. Even if you've never had a fire, that doesn't mean it isn't good practice to install protection from one. In this case, we simply do not know if or how many contributors we may have lost due to incidents covered by a CoC. Even if that number is 0, does that mean it's not worth installing one to prevent it in the future? Thanks, Anthony

On 1/4/16 4:06 PM, Anthony Ferrara wrote:

I'm not keen on the negative approach to managing behavior in projects such as PHP. It delineates bad behavior and provides bureaucratic regulation for judging people with respect to that law and punishing or reeducating those found guilty. The negative approach can only address obvious egregious behavior, which, as already pointed out, hasn't often been a big issue for PHP. At the same time it ignores the more subtle bias and discrimination that's hidden or only close to the surface that has a real effect on who is able to participate and how and what they can contribute. I think internals could do better at this and it's worth making the effort to change and for this I think a positive approach is preferable, i.e. education in constructive and inclusive participation. Imagine if the energy and time spent in discussion of this CoC had instead been spent on contributing to a doc (that could live in the PHP source so anyone can write issues and PRs against it) that states the values and goals, describes what people think works well the various modes of engagement, how people can avoid and mitigate bad behavior, techniques to intervene, coach, and so forth. The collective experience, intelligence, wisdom and wit available here is sufficient to do something really interesting. I think it's perhaps too general to be of great use to us here but The Code Manifesto is a good example of the positive approach. https://github.com/kayladnls/code-manifesto/blob/master/README.md Tom

All, On Mon, Jan 4, 2016 at 4:06 PM, Anthony Ferrara <ircmaxell@gmail.com> wrote:

I have made some more substantial changes to the CoC. Please review https://wiki.php.net/rfc/adopt-code-of-conduct It still uses the Contributor Covenant as evaluating alternatives hasn't occurred yet. It is still in my plans to do so and potentially replace it with another, I just haven't had the chance to review many of them yet. If you know of a better CoC, please let me know so I may add it to the list to evaluate prior to putting up for vote. The choice should be as transparent as possible and I welcome discussion around it. There has been some discussion asking for a split of the RFC into two. I do not believe that this is a good idea, because the CoC is useless without some sort of resolution strategy (without *anything*). And if we do need to do something (which I firmly believe), then why not do it right the first time. I am more than willing to evolve this proposal significantly (it's no where near a final form). This discussion should help it evolve. A quick summary of the changes: * Renamed "CoC Team" to "Conflict Resolution Team" * The process was altered to focus on defusing and mediating rather than punitive. Additionally, it is made clear that punitive action in any form shall be a last resort. * Temporary bans shall not include internals@ to allow for appeals and conversation around the incident to be fair to both parties. This is under the assumption that behavior on internals@ remains civil as judged by the overall community. * Added a quarterly Conflict Resolution Team report posted to internals to summarize all activity * I added a few of examples of when the CoC should apply outside of the project, and what constitutes "representing the project". These are not meant to be exhaustive, but intended to communicate the "spirit" of representing. Again, all of this is up for discussion. I am simply expanding here to better clarify and codify what my intent was here. The thing I want to communicate is the spirit rather than the specifics. Please let me know what you think. I welcome all constructive feedback. Thanks Anthony

On Mon, Jan 4, 2016 at 10:06 PM, Anthony Ferrara <ircmaxell@gmail.com> wrote:

just wanted to mention that the jenkins project just adopted a slightly modified version of the Contributor Covenant version 1.3: https://jenkins-ci.org/conduct/#code-of-conduct from what I can tell what seems to be changed that they adjusted the rights to those who already have them: "The Jenkins board has the right and responsibility to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. Plugin and other maintainers also 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." versus "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, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful." Adjusted the definition of their maintainers and contributors, explicitly defined where does the "This code of conduct applies both within project spaces and in public spaces when an individual is representing the project or its community." apply. They also explicitly stated how to report problems and what is the process handling those reports. They went with the full privacy path, and used their pre-existing government body to handle the reports, which is something we don't have (closest thing we have is the PHP group, but members of that are mostly inactive and doesn't really have extra governing power over others). https://jenkins-ci.org/conduct/ https://jenkins-ci.org/blog/2016/01/07/official-code-of-conduct/ ps: I'm not suggesting anything here, just dropping the info so maybe there is something we can use/learn from it.

Hi all, I've already written a blog on the topic, so needless to say I have no objections personally to seeing a Code of Conduct. Reading the current draft RFC, I did see a few potential issues which I'd like to raise on the specific text used insofar as it's starting point. 1. It should probably be made explicit that the Conflict Resolution Team is uniquely responsible for determining what is or is not "unethical or unprofessional conduct" subject to overview by Internals (via the appeals process). It's already implied, but this may cover any spurious claims that they lack the authority to do so. It also recognises that what constitutes unethical or unprofessional conduct needn't immediately be defined in a 100 book volume. Also see pt. 6 below. 2. The phrase "representing" strikes me as difficult to assess and is open to interpretation. Examples towards the end of the RFC clarify this better, but may be insufficient. I'd be more in favour of an open ended approach, centered on whether or not the subject of a complaint currently utilises the resources (list, git, etc.) of the project, i.e. where the project actually has recourse to punitive measures. This would encompass scenarios where there's no direct representation in evidence but the conduct in question is still linked to the PHP project through more indirect means. It's all too easy to imagine scenarios where harassment is designed to avoid the appearance of representing the project despite it obviously being linked to the project by context. 3. I'd like to see the Conflict Resolution Team framed as a group whose members will, volunteers allowing, be diversified. 4. The process for reported incidents does not mention specific timelines. There's also no mention of immediate relief measures. I'd find it troubling if the timeline turned into weeks, and the subject of a complaint continued their actions unabated and without consequence. If the team can make a rapid provisional determination, it should be explicitly allowed for them to request the accuser cease any objectionable actions under question while a final determination is pending. 5. It should be made explicit that the accused is definitely not allowed to disclose the identity of their accuser, directly or indirectly, without consequences. I'll leave it open to the floor as to what extent this could be applied, e.g. in scenarios where it's fundamentally necessary in order for the accused to collate evidence in their defense. 6. It's easier to enumerate what to do, then what not to do. Perhaps fold in text from the likes of the Debian COC as a supplementary or inline statement of accompanying principles? Regards, Paddy "But I Only Voted That One Time" Brady