Add proposed Project Jupyter Code of Conduct documents.

These documents were based on the Django CoC, and were adapted with input from the Project Jupyter team.

Thanks once this is merged I can update The Pr on the Jupyter Website.

LGTM

@fperez I would love to see this merged prior to year end. Anything that I can do to move this forward as it seems very close to being done 👍

me too! I've the md files from @fperez, I'll push them shortly :)
On Wed, Dec 21, 2016 at 11:37 PM, Carol Willing<EMAIL_ADDRESS>wrote:

@fperez https://github.com/fperez I would love to see this merged prior
to year end. Anything that I can do to move this forward as it seems very
close to being done 👍
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jupyter/governance/pull/23#issuecomment-268596911,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB23jV3U7EIHmoyXqLrcoJdftkMrOwvks5rKWrEgaJpZM4KwSq2
.

--
Yuvi Panda T
http://yuvi.in/blog

me too! I've the md files from @fperez, I'll push them shortly :)

Cool, feel free to take the WIP tag off after so we can merge this.

I've uploaded the rest of the documents (with some minor formatting / line-wrapping fixups), and retitled the pull request.

Agreed @willingc, and with @yuvipanda's recent help, we're almost there... Working on it now :)

One small note so we don't forget: once we merge this in its rendered form on the site, we need to double check some of the relative links that currently point to other .md files, to point to the rendered .html targets in their official locations. @Carreau already has a placeholder PR for that...
In fact, we should be able to create the rendered PR based of these materials, now that they are all here in quasi-final form.  This would let us update the links during the public feedback period, so that we're 100% link-consistent out of the gate.

Minor q: should we rename all these files and remove the conduct_ prefix? Since they all live in a conduct/ subdir, it seems redundant to me, so I'd prefer that.   Any reason not to?

OK, sent email to the project list!
Thanks everyone for your help, let's watch this space, hopefully we can merge it quickly :)

Thank you to everyone for their help and input. A special thanks to @rnetro for your dedication and initiative and @Ruv7 for your mentorship and patient wisdom.

I realize that it's most unlikely that this comment is going to have any useful effect, but, I was very sad to read this PR.
I will happily comment on specifics if y'all have any interest, but it seems to me that this document, like many others of it's type, is going to have exactly the opposite effect of the one intended.
I realize that having a strict and aggressive policy on 'conduct violations' might seem that it would make the community more open and welcoming, but I humbly beg that you consider whether that is really true, and how you can achieve the desired effect without the threatening language in this document.
Have a look at

http://lists.software-carpentry.org/pipermail/discuss/2016-May/004414.html
https://github.com/swcarpentry/board/issues/111

for one instance where a classic code of conduct, combined with very vague 'up to the committee' rules on what a 'violation' was, caused some needlessly impersonal and unpleasant enforcement, and ironically resulted in a female coder being ejected from the list.

I realize that it's most unlikely that this comment is going to have any useful effect, but, I was very sad to read this PR.
[snip with british accent I can hear in my head while reading.]
http://lists.software-carpentry.org/pipermail/discuss/2016-May/004414.html
swcarpentry/board#111
for one instance where a classic code of conduct, combined with very vague 'up to the committee' rules on what a 'violation' was, caused some needlessly impersonal and unpleasant enforcement, and ironically resulted in a female coder being ejected from the list.

Thanks for this link @matthew-brett I read part of the thread, but jet lag and late here are forcing me to stop.
I think I understand your point, and as a non native American/English/British speaker, I can understand. I am often concern to miss-step at a conference and use or say a wrong things that would violate the CoC, so tend to sometime avoid speaking out of fear (less now but it' use to be strongly the case). I was involved in one of the first draft, and tried to help phrasing things to give the benefit of the doubt or at least make things clear that enforcement is only if things will go horribly wrong.
I also believe that the feel for a need of a CoC can be quite different between culture in Europe and U.S. I have my own personal thoughts about this, but this is probably not the place for it here.
I'll respond longer at a later time and appreciate you coming forward to share your concerns, we'll see if we can incorporate some changes to address them.

Hi @matthew-brett,
Thanks for sharing your thoughts. I'm sorry that you were sad to see this PR. In a perfect world, I believe that a Code of Conduct "may" not be necessary. Unfortunately, we do not live in a perfect world.

I realize that having a strict and aggressive policy on 'conduct violations' might seem that it would make the community more open and welcoming, but I humbly beg that you consider whether that is really true,

Personally, I see a Code of Conduct as an opportunity for the community to demonstrate that the members view and treat people in minority groups (by race, gender, ...) as professionals in the community. I wish to participate in communities that respect me as a "professional" engineer first and foremost. To me, a Code of Conduct is the minimum bar for me to participate long term in a community or encourage others to do so.
Will the Code of Conduct alone make a community more open and welcoming? No, only the members of the community have the ability every day to do so.

and how you can achieve the desired effect without the threatening language in this document.

Guidelines on violations are only one part of the Code of Conduct. While I personally do not see threatening language in this document, I respect that others may view this from a different perspective. If you wish to share a specific example of a phrase or sentence that you find threatening, I believe that there is likely room for improvement to the wording.
Thanks! - Carol

I can imagine that in some cases a CoC committee could reach a decision
that could hurt a community or individual. I am not overly worried about
that with our community, but I do think it is something we have to watch
carefully. That is one reason why I think it is important for the CoC team
to report to the SC on its cases.
Having served previously on a CoC committee in another organization - one
which dealt with some extremely difficult cases - I can say this. Handling
CoC violations requires incredible sensitivity, wisdom, restraint and most
of all grace. It is a huge responsibility, not to be taken lightly. One big
question a CoC committee has to wrestle with is this: "which is the first
priority - justice or restoration/healing?" It is my opinion that the first
priority in any CoC case should be to attempt to enable restoration and
healing between the parties. If that fails, then the proper justice and
actions can be taken to protect the individual(s) and the broader integrity
of the community.
On Fri, Dec 23, 2016 at 5:43 PM, Carol Willing<EMAIL_ADDRESS>wrote:

@willingc commented on this pull request.
In conduct/conduct_reporting_online.md
https://github.com/jupyter/governance/pull/23:

mailing list archive or GitHub/gitter.im) please include a link
+* Any extra context you believe exists for the incident
+* If you believe this incident is ongoing
+* Any other information you believe we should have

+## What happens after you file a report?
+
+You will receive an email from the Project Jupyter Code of Conduct Committee
+acknowledging receipt immediately. We promise to acknowledge receipt within 24
+hours (and will aim for much quicker than that).
+
+The working group will immediately meet to review the incident and determine:
+* What happened
+* Whether this event constitutes a Code of Conduct violation
+* Who the bad actor was
@Carreau https://github.com/Carreau I agree. I would suggest: "Who are
the individuals involved"
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jupyter/governance/pull/23, or mute the thread
https://github.com/notifications/unsubscribe-auth/AABr0JysHA_A52Rv9j47Hs3YT4ZshBB2ks5rLGqegaJpZM4KwSq2
.

--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
<EMAIL_ADDRESS>and<EMAIL_ADDRESS>

I want to say I am being bold and updating the documents under proposal. I'll keep a close watch on the PR and make uncontroversial suggested edits about once a day (but often sooner!). This is a purely clerical service to keep the proposal moving along :)

Yes, I find this document remarkably frightening in intent.   I find it difficult to imagine anyone feeling free to speak freely having read this document, unless they have so thoroughly absorbed the current liberal constraints that they have forgotten what speaking freely means.  I was sad to read it because we have had discussions about the problems from these kind of documents in the BIDS, and for some reason I felt sure that those discussions would have some effect on this doc, but if anything, this CoC seems more extreme in terms of legal language, and anonymous reporting than the others I have seen.

Hi @matthew-brett. I'd like to quote from https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/jupyter/yaS6OOStNg0/gJh1azGJDQAJ:

We welcome input and feedback on the PR and are open to clarifying/refining specifics, but we're committed to moving forward with something very much along these lines.  If someone feels very strongly that we should not have these guidelines in the first place, it may not be worth your time trying to argue that point, as the decision to adopt them is a done deal.

Note that the email / code of conduct is not an edict handed down, but came from lots of in-person discussions, and experiences over the years in many different communities. I too would welcome it if you could spend time on helping us 'clarifying/refining specifics', but if you 'feel very strongly that we should not have these guidelines in the first place, it may not be worth your time trying to argue that point, as the decision to adopt them is a done deal.'
I echo @willingc and @Carreau's comments - please point out specifics so we can work on improving them. Code of Conducts are new (by human behavioral change scales, at least) in OSS communities, and will have 'bugs' that need fixing. However, getting rid of them entirely due to 'possible issues' seems to be throwing the baby out with the bathwater. Speaking from painful personal experience, long running meta-discussions on weather a CoC is 'really' needed are not tend to have serious negative effects if you care about attracting a diverse set of contributors. I was really happy to see the sentences I quoted from the email in the email, and I hope we can prevent this PR from spiraling into any of the very many possible meta-discussions it could spiral into.
Personally, I'm going to read through the links you provided, see what the issue was, and attempt to amend this CoC in ways to help handle issues like that better. I would appreciate your thoughts related to that too.
Thanks!

Ah no - I guess the standard misunderstandings that arise here are that
anyone objecting to the broad form of these things either:
a) does not feel that it is a problem that mailing lists can be miserable
and occasionally threatening places  and / or
b) is constitutionally committed to having no rules of any sort.
I don't suffer from either of these two problems, personally.
I will follow up with a fairly detailed summary of what I mean about the
use of threatening legal language, as well as the damage that I believe
will arise by the tone of this document - but not today - I'm in Cuba and
we celebrate Christmas on the 24th.

but not today - I'm in Cuba and
we celebrate Christmas on the 24th.

It's already the 25th here. Still, enjoy the CoC ! (Christmas of Cuba)

Before going into specifics about this PR, I wrote down some principles that are relevant to a document like the "Code of Conduct".  I hope y'all will agree with these, broadly.   I'm setting them out here to refer to them later.
To be clear, I am writing this as a member of many open source communities, and do not claim any audience on the basis of my credentials for the Jupyter projects.  The Jupyter community is influential, and the decisions you make, good or bad, will have an effect across many communities.
Features of a healthy community
Open source software lives or dies by its community.  A healthy project builds on the foundation of a healthy community.  But, what do we mean by "healthy"?
I'm going to define healthy in terms of production.  A healthy community is one that tends to produce more work, and more useful work.  It is a community where communication is efficient, that is, ideas can be expressed freely, and clearly, and discussions are substantial, addressed to the ideas.  A healthy community is effective at training new people to work within it.  Because its culture is clear, conscious, and widely agreed, it can attract people from different cultural backgrounds, in order to benefit from the widest range of expertise.  A healthy community is a community of equals; the best idea is the best idea, whether it comes from a new member or an experienced member.  The experienced members know these rules, and subject themselves to the furnace of review with the same humility they expect from others.
The ability to discuss freely, even fiercely, is characteristic of successful organizations outside open source ref.  A loss of that ability is a cost that may be severe, even fatal to the project.
Trust through transparency
This level of discussion takes trust.  The participants need to be confident that their views will be properly considered, and that the final decision, even if wrong, comes from an impartial review of the ideas.  In contrast, if it is not clear how project decisions are made in practice, and it appears that some members have more weight than others, then discussion becomes corrupted by lobbying and pandering, otherwise known to skeptical coders as as "politics".
Trust in open-source comes from transparency.   The project commits itself to having discussions and making decisions in public.  Any member can review the discussions and confirm that the decisions were a reasonable reflection of the evidence.  A contrasting model is trust based on personal confidence.  In this model, certain members of the community are particularly trustworthy: "X would never do anything to hurt the project".  Because it is based on faith, this is a more fragile model; the suggestion that X may have made a wrong decision, or for the wrong reasons, is a direct threat to the project, and may be treated as hostile.
Barriers and risks
Cultural differences
Open source projects have several major problems to overcome, in supporting this kind of discussion.  The first is, that open source projects usually have contributors from many different cultures.  I may express myself in a way that is perfectly ordinary in my own culture, and cause unwitting offense to someone from a different culture.  In particular, there are large and often unnoticed differences between computing cultures in the USA and elsewhere.  US culture has two significant groups that are mainstream in the US, but only exist on the fringes of other societies.  The first is Libertarian, maybe most obviously exemplified in open source by the writings of Eric Raymond.  The second is the codified speech of the US left, best expressed with the word "safe" as applied to speech in which any possibility of offense has been carefully removed.  Both ideologies can excite varying degrees of incomprehension, ridicule and horror from cultures outside the US.
Electronic communication is impersonal
A second problem is that most discussion must happen by electronic means, such as email, rather than face-to-face.  Electronic communication is impersonal - it is much more difficult to express the kind of cues that let your readers know that you are prepared to negotiate, that you are joking, that you don't mean the message to be taken very seriously. Electronic communication introduces a social gap that can give the sender considerable space to break the rules that they would normally observe when speaking to someone in person.   This gap may contribute to patronizing, sexually suggestive and threatening online behavior of men towards women.   It is hard to believe that this kind of behavior does not contribute to the remarkable lack of female members in open source communities.  The proportion of women in open source appears to be about 3 percent, compared to around 25 percent in the computing industry source. This is against the basic rules of equality that open source aims to represent, reduces our talent pool considerably, and deprives us of the social benefits of a well-mixed working group.
Impersonal is threatening
Because electronic communication tends to be impersonal, electronic communities such as open-source projects can be particularly threatening. Most people find impersonal criticism, rejection or shunning to be particularly threatening and unpleasant.  Being rejected by an online community to which one is committed can be a extremely painful experience. Linus Torvalds sheepishly refers to a time that he indelicately rejected some code submitted to the Kernel.  He later heard that the code author had considered suicide as a result.
The role of the community code
We have a code of community to be explicit about the things we care about and to make them clear to new members. We write these down to make them visible for constant discussion, and refinement.  The code provides a structure when things go wrong, so all parties are clear about the protections that they can expect, and the responsibilities we all assume.  It should represent our values, of supporting free and vigorous discussion, of absolute equality in expressing ideas, of trust through transparency, of the importance of ideas over opinion or personality, and our desire for the widest possible community.

Here's a quick summary of the structure of the code of conduct, with some comments.
The "code of conduct" is a document describing a general set of behavior and attitudes that are desirable, and some that are undesirable. From the list headings, the desirable attitudes are: being: friendly; patient; welcoming; considerate; respectful; careful in phrasing, moderate in expectations; understanding of disagreement; quick to apologize.
The section "Be careful in the words you choose" is the most specific in naming things we're not allowed to do, such as make violent threats, post sexually explicit material and so on.  The section on "Be respectful" appears to ban "personal attack", although there's no explanation of how you know when it's a personal attack or an attack on the person's idea, which presumably is allowed.  The section on "When we disagree" might be intended to mean that blaming people is a code of conduct violation.
When someone thinks that this "code" has been "violated" they are to "report" the violation.  Usually this is sending an email to the "code of conduct enforcement committee" - or filling in a web form.  This form can be anonymous.  The committee then responds, where the minimum positive action is a private formal reprimand from the committee.  There is no right of appeal for anything other than a permanent ban.
Critical summary
There is very little attempt to define what a "violation" is in this code of conduct.  Apart from extreme cases, the code of conduct boils down to a request for ordinary good manners.  A violation of good manners is extremely subjective, and left up to a committee that discusses in secret and whose members are not allowed to express public dissent from the judgment.  In general, the whole document reads something like a campus policy on reporting of sexual assault, but apparently intended to be applied to issues like being welcoming and respectful on the mailing list.
The code of conduct enforcement committee
This design of this committee goes against several of the values I suggested as fundamental for open source:

its deliberations are secret, with the members embargoed from comment.  This is the very opposite of transparent;
for anything but extreme cases, it's not at all clear what would constitute a "violation" of this code of conduct.  That makes the judgment subjective, making it even less transparent;
it is impersonal.  Judgments, having been arrived at in secret, are required to be unanimous, and are handed down from the desk of the committee.  The committee members are not allowed to say whether they thought the judgment was right or not, or give any further details of why the decision was made. It is already a severe social blow to be publicly criticized by a secret group of your peers; these further details of enforced unanimity and secrecy make this doubly unpleasant and threatening;
it is not equal.  The committee has been elected specifically as judges of their peers. The idea is, presumably, that committee members are selected for their right-thinking social views and polite behavior.  These members then have the power to cause severe social damage to members, once a complaint has been made against them;

This next comment doesn't refer to my previous summary, but I think it is obvious.  There is a reason why we try to avoid secret committees governing behavior in open societies, and that is that secret meetings are rich compost for group-think, self-righteousness and bullying.  I guess the idea is that the people elected to this committee would never do such terrible things, but that is against all experience - see mobbing in academia for many examples, just in academia.  I can, off the top of my head, think of two famous incidents in open source where a secret committee, that refused to give detailed reasons, censored a member of project, and caused the project to fork, in both cases with disastrous results for the original committee.  The first is the famous incident where the NetBSD "core", a group whose meetings were not public, removed commit rights from Theo de Raadt, causing the project to split, and sending NetBSD into terminal decline.  The second is similar, where the XFree86 "core" removed commit rights from Keith Packard, eventually causing the project to split, and the death of XFree86 ref.
In the next comment on this PR thread, I'll suggest two things:

that we should proceed as for any speculative design problem - by analyzing
use-cases.  I mean, finding or making up things that might or might not be
code-of-conduct violations, and thinking how they might proceed with the
proposed structure, and with any alternative structure.  These should
include severe cases, like threats of sexual violence (no matter how rare)
with minor cases, such as complaints that reviewers are being too
argumentative;
that we should change from a teacher / pupil model (as exemplified here) to
a mediation model, in which we do everything possible to resolve disputes
before they reach some formal body for a ruling.

As promised, the third of four longer comments on this PR, this time with suggestions for a way of thinking about alternatives.  In my next comment, I'll suggest an alternative approach.
I suggest that the best way to explore this code of conduct is to write some tests, where the tests are realistic scenarios in which a question could arise as to whether this is behavior that should be covered by the community code, and if so, how that behavior should be dealt with.
To start, consider an extreme case: a relatively new member posts a sexually explicit GIF to the pull-request discussion interface.
What should happen?   I think the current process has something like this:

someone raises a complaint via email to the "conduct" mailing address or via
a web form, presumably pointing to the graphic;
presumably any member of the committee can take down the graphic (but I
guess this would have happened immediately by anyone with commit rights);
I suppose some member of the committee would try and lock that member out of
the PR thread, and maybe block their email from the mail list, if they can
find it;
the committee then has to investigate.  I suppose this would involve someone
contacting the person who sent the graphic to ask them why, whether they had
sent it by accident, whether someone had hacked their account, whether they
understood this wasn't allowed from the code of conduct and so on;
at that point it's not clear to me how to proceed in anything but the most
obvious situation, which is where the person confesses to sending it in full
knowledge that it was against the code of conduct.

I guess that the large majority of cases will be much less clear cut. For starters, I have the following real case.
SpacedGirl posted her first mail to the Software Carpentry (SC) Mailing List in May 2015, including an apology for being a novice.  Immediately, a more experienced member I'll call PG replied telling her to post under a resolvable identity, claiming this was customary on the SC list.  SpacedGirl replied quickly, including the sentence "At this point, rather than have to receive asshole teaching statements, can someone point me to an ideal how-to guide for this list?"
The list administrator sent a small reprimand to PG, and replied to SpacedGirl "Please keep your language civil and avoid personal attacks", and pointing to the code of conduct document.  (Reading the code of conduct now, it appears to relate specifically to harassment, and there is no mention of
swearing.  It does have the sentence starting "All Software Carpentry interactions should be professional, regardless of location, harassment is prohibited whether it occurs on- or off-line ...")
I replied to SpacedGirl suggesting that there be a community guidelines document, separate from the code of conduct, and SpacedGirl followed up with a mail starting "How about SC and just do away with the whole code of conduct in general?
At this point the mailing list administrator removed SpacedGirl from the mailing list, after privately consulting the SC equivalent of the code of conduct enforcement committee.  The explanation was apparently that her behavior was unprofessional, although no more detailed explanation was forthcoming.
So - running that through the Jupyter code of conduct procedure:

I guess PG or someone else would send an email to the code of conduct
enforcement committee after the first email.  They would cite, I guess, that
the code of conduct does not allow personal attacks, and the SpacedGirl had
personally attacked him;
Then, presumably someone else would send another email to the code of
conduct committee complaining of her use of the word 'shit' referring to the
code of conduct.  Maybe the complaint here would be something along the lines
that this was not respectful;
I suppose these two complaints would be fused into one.  I guess, if someone
on the committee felt this was urgent, they would suspect SpacedGirl's
account;
Now the committee convenes.  I guess they try to decide whether these two
emails were really disrespectful or not, or whether the first email was
really a personal attack.    If it deserves punishment, then SpacedGirl, as one of her
first, and presumably last experiences of Jupyter, would get a formal
private email from the committee telling her that she had violated the code
of conduct.

Next - what can we do to avoid this formal, subjective and censorious approach?

This is the last of the four emails.  It has my suggestion for a change in approach, and therefore procedure.
My suggestion aims to achieve the following goals:

personal rather than impersonal;
emphasize resolving conflict rather than judging behavior;
increase engagement in good discussion practice from new and old members;
better and more explicit support for new members, with the aim of increasing
participation from women in particular.

Short version
More senior members of the project sign up as mentors.
We encourage new members to ask for mentors, and strongly encourage anyone having an interaction problem to ask for a mentor.
The mentor helps the new member negotiate with other members, if possible, and negotiates themselves, when not possible, to try and resolve the problem informally.
If that is not possible or practical, the complainant and the person complained against are both required to take mentors to represent them, and a third agreed senior member acts as a mediator, to find an agreed solution between the parties.
Only if this fails, does the problem escalate to a committee.  This should be extremely rare.
Long version with some worked use-cases
Working out how the community works can be a difficult task, and it can take time.  When you run into trouble, as a new or junior member, it can feel that you have little protection, and that you are not worth much to the group.
New members who want to get involved should be encouraged to ask for a mentor, by emailing<EMAIL_ADDRESS>or some other channel, as standard procedure.
The mentor undertakes to answer any private questions the new member has, and give them advice on how to proceed on asking questions, making suggestions, making new pull requests.
If any member runs into trouble on any of the Jupyter forums, of any sort, then we strongly encourage them to ask for a mentor.  The phrasing could be something like "We care very much about learning to make our culture better and more responsive to solving problems.  One way we can learn to help better, is for our more experienced members to mentor new members in how to do things in our community.  This becomes very important if you are having any trouble on the mailing list or other Jupyter spaces - for example, if you are feeling the discussion is becoming unproductive or unhelpful.  It would help us a great deal if you could contact us to get a mentor to help you solve these problems.  That way, we learn more about how to avoid those problems in the future".
Dysfunctional interaction use-case
Say person F (Fresh new member) is feeling that person G (Grumpy old member) is being unreasonably critical or patronizing.  They ask for a mentor, and mentor M volunteers (or is allocated).  F and M have a private email conversation about the problem, during which M explains to F that G can appear grumpy, but they have known him a long time, and he's always happy to hear when he's being unhelpful.  M helps F draft an email to G, and F sends the email to G, maybe Cc'ing M, saying that F is finding the discussion difficult, and that he (F) wants to try a different approach with G.  G responds generously; F and G find they enjoy working together after this.
Apparent sexism use-case
Now say the problem is more serious.  B (a new female member) is having problems with another member P (Putdown artist).  B feels that P is being patronizing about her work, and suspects this is because of her gender.  She contacts M.   M and B discuss the problem, and M agrees the P's emails are unpleasantly patronizing, to the extent that conversation between B and P will be difficult.  Now M contacts P and says that, having seen the emails, M agrees with P that these have gone too far, and explains why, with specific reference to the emails, to the extent that M is able, given the permissions that M has to use the email correspondence.  M then suggests that mediation will be necessary to fix this, and asks P to choose a mentor to represent P in this process.  P chooses S.  S should be of the same level of seniority as M.
M and S then discuss who should be the mediator.  They select D.  D is asked to join as mediator, and discusses the problem separately with (B and M) and (P and S), and arranges further discussions with the four members as they think necessary.  D's job is to come to an agreed way forward with all parties.  This may include cooling off periods or other action as can be agreed by the parties.  Only if the parties cannot agree, does D escalate to the committee for further action.  The escalation is in the form of a report, also given to all four parties, with a statement from (B and M), agreed by them, a statement from (P and S) agreed by them, and then D's comments, seen by the other parties, but not necessarily agreed by both or either side.   The committee, investigates, interviewing all parties, and decides on a course of action, with reasoning given to all parties.

Thanks @matthew-brett for sharing your views, perceptions, interpretation, and values on open source contribution. I respect that your opinion is shaped by your experiences in open source. I also can see how your experiences could develop into implicit rules of what you've learned about how things should and should not be done.
Each of us have our own past experiences that shape our thinking. The Code of Conduct presented here represents a broad spectrum of the experience and knowledge from the Jupyter Steering Council and attendees of the Jupyter team meeting. These individuals provided a broad and inclusive foundation of experiences. After thoughtful, vigorous discussion and debate, the team's consensus supported moving forward with this Code of Conduct.
Reading your views, I do think there would be value in adding a sentence about the CoC committee will take into account the intended communication of non-English speakers if there is a misunderstanding among community members. I also think having a more formal list for mentors, though not as part of the CoC or its implementation, would be a valuable addition to the community.
Thanks for caring about the community and sharing your thoughts. All the best for 2017.

Carol

P.S. While the Software Carpentry threads make interesting reading, I do not find them relevant to this discussion of Jupyter's Code of Conduct.

Carol - late here, but a few questions:
Did you consider my suggestion for mediation and mentorship above?  I posted it recently.  Can you give more detail on why you rejected that suggestion, if so?
Did you give any thought to the problem of the ease with which the code of conduct enforcement committee can be used for controlling dissent, and bullying?  This does happen, I've given links to real examples above.
I tried hard to show that the SC example is absolutely relevant to your current structure, in that the SC system has the same vague specification of what correct behavior is, and a secret committee to decide on outcome.   I also went through my guess at how the SC example would be handled by the proposed system, and it seemed obvious to me, from that attempt, that the current system is particularly unsuited to these kinds of minor social infractions, which are also the most common.
Last - you have seen that I have spent considerable time and energy thinking and writing about this, on this PR request.  Will you return me this favor by reporting your discussions here?

This is the current place of discussion and the realization of the aforementioned deliberation. There is no secret tribunal meeting about this. The substance of this PR is the current draft and is the place to contribute by reviewing the document to improve it towards making a welcoming and healthy community that stands by its code of conduct.
Please provide direct concrete feedback on the content of the PR instead of expecting us to review your long comments as if they themselves are up for review. Many of us are also volunteers and are limited in the time we can contribute. I appreciate the amount of time you put into your comments, they clearly come from a source of passion.

Interesting last few comments. An unstructured response:

@matthew-brett: While all of open source hopes to be a buzzing environment with vibrant discussion on as many points as are raised (and more), it is entirely unreasonable to expect that your points unconditionally merit a point-by-point response. In the same way that you have chosen to spend time diving into detailed analysis, the core team can also choose to spend time doing things that are not responding point-by-point to your detailed analysis.

I question the base number of people who would feel threatened by the existence of a Code of Conduct. Out of the entire jupyter community, how many people would that be? Then, how many people from that group would have acted in a way that violates the Code of Conduct if it were not in place? Gut check this for yourself - how many times have you decided not to say anything because there was a document that said "be nice to everyone"?

I only browsed through the SC links, but it seems like the unanimity requirement in the jupyter draft would address that possibility.

I'd like to offer my high-level support of the draft with a different perspective. I work as a management consultant, where I work with large companies on a number of topics. One of them is always change management and culture building. Open source communities, while not economically the same as these companies, are very similar to these large companies - they're just large groups of people with a few folks that are more senior and therefore lead the community. Having the leaders formalize the overarching beliefs for the organization is a good thing, a very good thing. Top-down communication, culture-setting and governance is strictly critical, and it's the first thing I see brought up. The committee's process for response also seems to be informed by the right underlying principles. While I haven't considered the mechanics of the process, I trust that the right answer is already 90% there.

Subjectivity is fine and we also can't get rid of it. What are we going to do, list out the swear words that we find unacceptable? Even relying on community members to report conflicts is subjective.

Hi @matthew-brett,
I respect that your viewpoint differs from mine in substantive ways. This difference does not make one view right or wrong; instead they are simply different based on our individual experiences and perspectives on treatment of others in a professional setting.

Did you consider my suggestion for mediation and mentorship above?
Did you give any thought to the problem of the ease with which the code of conduct enforcement committee can be used for controlling dissent, and bullying?
Last - you have seen that I have spent considerable time and energy thinking and writing about this, on this PR request.

To all three of your questions, I did thoughtfully and rigorously consider all of your writings in this PR. I recognize that you have strong beliefs that differ from my own. I too have spent considerable time and energy on this issue.

Will you return me this favor by reporting your discussions here?

Matthew, it's unclear to me what you are referring to here. The PR encompasses the result of the Jupyter team's discussions.
I share the following article with you and the community as it represents yet another view of Codes of Conduct: The complex reality of adopting a meaningful code of conduct
If you wish to have a further discussion with me on the general subject of codes of conduct, I would be happy to do so in person the next time I visit BIDS.
Warmly, Carol
All: For the purposes of this PR, I am +1 on this PR to merge as written.

Sorry, this got long and rambely.  In short, explicit is better than implicit.

I think that THE TYRANNY of STRUCTURELESSNESS is a relevant essay here.  The very short version is: all human groups have a power structure, even if you do not write them down.  If you do not write them down you will get feuding informal power structures and get nothing done.  Writing down a CoC and how to handle violations of that is part of documenting the power structure of our projects.
I see nothing in here that prevents a quick email or comment for gray-areas, which will in most cases facilitate the apology of point 8.
The problem with using the mentor scheme as the primary conflict resolution is that it is entirely dependent on the implicit power structure and is even more susceptible to abuse and bullying than what is written here (by gaming who the other mentor / mediator is).  It also does not address well conflicts across 'seniority levels'.  These things are simplified by having a standing committee who has agreed (and the community has agreed) will handle interpersonal conflicts that need a resolution.
That said, I think a more formal scheme for new contributors to request / be assigned a mentor would be a major win for all of our projects.  That might even be something that should be done at the numFOCUS level (and is well outside of the scope of this discussion).
Keeping CoC violation discussions private by default is part of trying to make sure that these things do not turn into witch hunts.  Further, being required to make all parts of a complaint public (along with the inevitable blow back of 'this person could never do X') is a burden that which is unfair to place on reporters in some cases (again, being more sensitive to complaints across the implicit power lines).  If only some CoC reports are private, that flags those as interesting, so all should be private by default.
In the case of software carpentry, from @matthew-brett 's reported version of events the response by SC seems reasonable.
I think one of the greatest dangers of CoC is endless argument of what exactly 'professional' means, at some point someone has to make a judgment call (or we devolve into endless hair splitting and hypotheticals instead of producing software).  With the committee scheme the community is saying "these people get to arbitrate" so at least we know who is doing it.  In the ad-hoc mentor scheme no one knows who is doing said arbitrating (but it is still happening) as it happens in a distributed manner.  For example, both of the mentor use-cases rely heavily on private email to a single person.  This seems much more apt for abuse and secretive than the committee system.
I keep alluding to, one of the cases I am most concerned about is CoC violations where the violator is a 'senior' person and the other person is a 'junior' person.  I think this is the case where the committee has a chance of getting it right (the members are explicitly charge with holding all community members accountable and may start to see patterns) and where the ad-hoc system absolutely falls on it's face (until there is a crises as I assume the FreeBSD and XFree86 cases went?).
 However I think that an approach like the one outlined in this PR will always do better at preventing it and be more transparent than an ad-hoc system (and any 'ad-hoc' system you try to write down will eventual boil down to basically this system)

@matthew-brett

Will you return me this favor by reporting your discussions here?

I think you got your mailing configuration confused, Carol did respond on the PR. I think other people get confused by this statement later as they do not realise you have a complex system that sometime break threading. Or I may misunderstand the situation as well.

I question the base number of people who would feel threatened by the existence of a Code of Conduct. Out of the entire jupyter community, how many people would that be? Then, how many people from that group would have acted in a way that violates the Code of Conduct if it were not in place? Gut check this for yourself - how many times have you decided not to say anything because there was a document that said "be nice to everyone"?

@petehuang I, am one of the person that does feel scared (not threaten) by some code of conduct. I starting to be comfortable in english (language, and customs). I did do/say some extremely controversial things because I was mistranslating, or did not knew what the correct behavior was. I was reprimanded, after the fact, but had the chance to have the benefit of the doubt as people knew I likely made a wrong translation (my french accent was a strong hint). And some code of conduct (in general) are the reason why I do not express my opinion in some conferences/events. Because I am scared of miss-expressing myself. It can also be a question of tone, because my vocabulary is still highly limited and I am likely to express things in english a simpler (harsher?) form than a native speaker.
So it is not a question of being lenient on people that will misbehave on purpose. It a signal to people that do not have the same culture that they can have the benefit of the doubt and that we will politely point to them what we consider to be the limit if they happen to be close (or beyond) to them before taking actions.
@matthew-brett just happen to know some of the people and have the courage to speak on their behalf.
I'll try to come back to various point later, but I would suggest to put in the right place that the "enforcement" policy is our last resort(for important or recurring violation), and that if we think someone is behaving in a way which does not seem to correspond to the apparent implicit consensus of professional behavior we will attempt to warn them and explain why. That does not mean that it has or does not have to go through the conduct committee.
For the example of SpacedGirl that @matthew-brett linked to, I think that a clear mail from anyone asking her to pay attention to her language and be a little more respectful (from a core member or anyone else) may have been enough to set the tone.
IMHO SpaceGirl did went a bit too far. But the immediate unilateral response by banning her was (I feel) a bit harsh.
The code of conduct still have IMHO (but I need to reread it carefully with all the changes @yuvipanda made a bit) a feeling of guilty-just-because-someone-complained which goes against presumption of innocence.
We did had people on the IPython-dev mailing list to whom we said we would block if they continued their behavior. For information it went like that:

(Repeated behavior)
Public reply (as user) to their mail hinting their behavior were felt as not appropriate.
(Unchanged behavior)
Public reply (as a Core Member) that we expect them to change their behavior (or go away).
(Unchanged behavior)
Private personal mail asking them one last time for change or we would take actions.
(User disappeared)
I strong believe the user genuinely thought their mails were appropriate/useful.

Hi Kyle,
I'm sorry for the confusion - I was responding to this in Carol's response:

After thoughtful, vigorous discussion and debate, the team's consensus supported moving forward with this Code of Conduct.

It was pretty late at the time I read it, and I now see that she meant 'proposing this code of conduct', not moving forward with the current code of conduct unmodified.
I am sorry that my responses were long.  This reflects my understanding this is an extremely important issue for the health of the community that needs careful reflection before rushing ahead.
As Chomsky points out you can only be concise when you are repeating something everyone believes already.
In particular, I think there is some background here, which is implicit, and assumed as "normal", and therefore not worth explaining.   The current code of conduct is - in my opinion - an undigested artefact of current trends on the US left towards suppression of speech labeled as harmful - see demands for censorship.  These trends are so pervasive, that conforming to those trends apparently requires no justification.  My long posts have to be long because I'm trying to explain why the things that apparently seem ordinary to many people here, are really not ordinary at all, and have the potential to have a devastating effect on the quality of debate, and the atmosphere of the community.
I hope you'll read my posts with care, to see if I may be right in saying that the current document contains truly frightening threats to open discussion, and transparent process, that have not been justified here, and I think, cannot be justified.

Thomas - responding to your point about the mediation proposal.
The important distinction I'm trying to make is between control of bad behavior by judgment and punishment (the current proposal) compared to development by agreement and consent (my proposal).    Of course you can put strategies in place to stop the mentor selection being gamed, but the 'game' that the mentor is engaged in, is supporting the member, and helping them to come to an agreement, that all parties consent to.  So, the member should chose the mentor that is most likely to help everyone agree.

On the SC case - it seems that it is turning out to be useful, because I was surprised to hear that the outcome in that case was acceptable.  It seems to me that almost any outcome would have been better than the outcome that resulted, and that anyone observing that a person could get ejected from the mailing list without warning, for 'unprofessional behavior', as interpreted by a secret committee, would be very careful about what they said after that.

Keeping CoC violation discussions private by default is part of trying to make sure that these things do not turn into witch hunts

Actually, my argument was the opposite, that keeping the discussions inaccessible to the parties, is the absolute best way to make it possible to pursue witch-hunts.  Indeed, that is exactly what these kinds of committees were used for in more disciplined societies behind the Iron Curtain.

the "enforcement" policy is our last resort(for important or recurring violation)

Yes - this is exactly what I am arguing for.  I am not saying that enforcement should not be possible, I am saying it should be the last resort.

I've submitted these changes that "Give the benefit of the doubt to newcommers", precising that we'll remind everyone that a thread / behavior is geeting out of bounds.
Because I believe if you don't publicly tell what are the limit when someone is out of bounds there is no way for people to know the bounds.
And also mention that the CoC violation can resolve itself, in which case the committee can (and will likely) take no actions. The case I want to cover with this is for example the hypothetical situation:

Me saying something inappropriate in GitHub Issue.
(Someone fill in the form)
(Council  receiving the mail from above form, and taking notice)
User Lambda [May not be not in the committee, or even regular contributor] pointing out to me I was out of bound.
Me apologizing

I was on my phone with french keyboard that autocorrected and have now edited my comment.
Or even just realized my poor phrasing

(council decide to do nothing)

Somme comments following things that were said on the twittersphere.
@matthew-brett comments seem to happen just when the PR was about to get merged. It is untrue as @fperez did send a mail to the jupyter mailing list requesting feedback. So @matthew-brett is pitching in because we requested it. This is exacerbated as the PR was submitted on Nov 15, but worked on privately while it appeared inactive on GitHub.
Many of us know personally @matthew-brett and some of us work with him. He is not a random stranger commenting on this because it crossed his twitter feed.
I don't believe (as some people said on other social media) that @matthew-brett is trying to derail the PR. He is IMHO, expressing real concerns.
This thread is a perfect example to show that electronic communications can be really difficult to interpret and lack many of the cue from meeting in person, and interpretation can depend on whether you know the person IRL or not.

@matthew-brett I think this is the clearest summary of your concerns:

The current code of conduct is - in my opinion - an undigested artefact of current trends on the US left towards suppression of speech labeled as harmful - see demands for censorship. These trends are so pervasive, that conforming to those trends apparently requires no justification.

which makes responding to any specific point difficult as the underlying objection is to something much deeper.
It is a bit frustrating that in the stories about how mentoring would go, everyone is always acting in good faith but in the case of how things would go under this proposal everyone in the leadership is acting in bad faith.  If everyone is acting in good faith all the time, then all of the reporting and enforcement text is moot.
Compared to something like http://scikit-image.org/community_guidelines.html text of the actual CoC they are identical in sprit, this version just has a lot more words.  It has built into it ample space for 'local' discussion (pt 1, 3 (which explicitly calls out the non-native speakers), 7, and 8) and course correction [ @Carreau brought up self-resolving  while I was typing out this comment].  I simple do not see every controversial interaction being reported as a likely out come (and to a large degree against the grain of this whole operation).
I think everyone agrees the more things that can be sorted out informally the better.  The main difference between the skimage guidelines and this one is the specification of how things get handled when they go sideways and can not be.   In this proposal there is clear reporting channels and a procedure for how the report gets handled.  There is a statement that through records should be kept of any investigation (which could presumably be reviewed if needed).  There is a reasonable list of possible responses, both to guide the committee (more-or-less in order of impact) and to give people an idea of the scale of responses.  In contrast, skimage there is an oblique instruction to email 'one of the project leads' and where to find their email addresses.  I will admit, I am not sure who else other than Stefan falls in that category and sorting that out may require reading the implicit power structure of the project.  Once you have sorted out who to email, what expectation do you have of a response?  What if you just reported being made unsafe by someone to their best friend?  What if the person who is being problematic is one of the project leads?  If I had to deal with an issue like this on mpl I would probably do what is described in the enforcement page (form a committee, collect evidence, discuss what do to, do something about it), but in an ad-hoc way (and I suspect that the skimage folks would do the same), however by writing it down we (the sundry project leads) are able to hold our selves accountable and have a better chance of handling these issues uniformly and fairly.  (sorry for picking on skimage @stefanv but you brought me here :smiling_imp: )
Having the CoC violation committee discussions private means that members can safely move their view of what should be done in response to learning new things during the discussion.  It also means that spurious or explosive allegations can be handled with finesse if needed.  Despite the allusion to communist secret courts, this seems pretty standard (most things with HR, investigations in the US).   I think everyone agrees that there needs to be some level of privacy in these things; all of the mentor stories above + the skimage docs rely heavily on private email communications rather than mailing the main development list.  In the proposed case it is known who is doing the discussing, they should be keeping records, and (crucially) they are charged by the community to do this.  In the ad-hoc model there will still be private discussions, but among who? Why does that group have authority to do something about this?
Asking the committee to not publicly discuss the matter beyond what they all agree on is an extension of this.  Having 3 versions of what happened and what should be done in public discussion blows up any possibility of finesse (which if there was not the need for that then why did the issue get escalated to begin with?) and can only feed the (apparently hostile) implicit power structures in the organization.
I think that the CoC serves two (possibly conflicting) purposes.  The first is a set of guide lines to help integrate new members into our community and the second is to keep our selves (the 'senior' members of our projects) accountable.  It is important to give the benefit of the doubt to reporters in these cases, particularly if reported against someone with a fair amount of implicit (or explicit) power in the project.

I think (hope) everyone agrees the more people we have involved in the community the better. Further, we have a lack of diversity along many axes (race, gender, age, expertise) and is a problem.  The alternatives to the proposal in the PR is basically the status-quo which evidently is not working.  If this makes things worse, then I have enough faith in this community that will re-address this.

There is also a much wider meta-debate going on in our community about how to deal with the coming professionalization of our projects.  Our reach is now well past what can be sustained on volunteer nights/weekends and time pirated from employers by small, informal teams.  Formalizing all of the things 'we just know' (and sorting the disagreements we discover when we write them down!) now is critical for our projects over the next decade.

I think everyone agrees the more things that can be sorted out informally the better.

Well - the current proposal is that everything gets resolved formally, with a judgment from a committee.   My proposal is that we put mechanisms in place to resolve problems by agreement, so that formal judgments and punishments are an absolute last resort.
Hence:

The alternatives to the proposal in the PR is basically the status-quo which evidently is not working.

That is not at all the alternative.  The alternative that I'm proposing is precisely that we try and improve the atmosphere and feeling of safety by removing the threat of summary discipline and providing support from senior mentors.   I think that the current proposal is going to make things much worse for anyone but the most abject conformist.   We must make it possible to disagree, vigorously and safely, and the current proposal will have the opposite effect.

which makes responding to any specific point difficult as the underlying objection is to something much deeper.

Again - it's very easy to respond to my specific points - remove the immediate threat of judgment and punishment, emphasize learning and consent over enforcement, hold the committee to account by making their judgements transparent to the parties concerned.

We must make it possible to disagree, vigorously and safely, and the current proposal will have the opposite effect.

Where is evidence (not your personal feelings) for the general truth of this claim.

Again - it's very easy to respond to my specific points - remove the immediate threat of judgment and punishment, emphasize learning and consent over enforcement, hold the committee to account by making their judgements transparent to the parties concerned.

 The offending posts were removed, but making complete deliberations about what to do in such cases permanent public record would commit the very offense that is supposedly being remedied.

I think everyone agrees the more things that can be sorted out informally the better.

Well - the current proposal is that everything gets resolved formally, with a judgment from a committee. My proposal is that we put mechanisms in place to resolve problems by agreement, so that formal judgments and punishments are an absolute last resort.

This as approaching a straw man position.  The exact wording is

If someone makes you or any other contributor feel unsafe or unwelcome, please report this in a timely manner. Code of conduct violations reduce the value of the community for everyone and we take them seriously.

compared with

If you ever feel like you are not being treated as well as you should, please get in touch with one of the project leads (our email addresses are available through our GitHub profiles). We are committed to making this community a safe and welcome space.

from skimage.  They are slightly different spellings of identical courses of action and will presumably be hit at the same rate.  The only difference between the two is in this case the reporter has any visibility into what is going to happen, in the skimage case it goes into the blackbox of the the project lead that got emailed.  The preference for the later cuts directly against the 'trust through transparency' from your first post.

The alternatives to the proposal in the PR is basically the status-quo which evidently is not working.

That is not at all the alternative. The alternative that I'm proposing is precisely that we try and improve the atmosphere and feeling of safety by removing the threat of summary discipline and providing support from senior mentors.

The status quo that is being maintained in to entirely rely on the implicit power structures of the projects.  There is not currently (than I am aware of) a mechanism for 'summary discipline' so I am not sure how arguing against adding it is not maintaining the status quo.  I suspect we are talking past each other here.

I think that the current proposal is going to make things much worse for anyone but the most abject conformist.  We must make it possible to disagree, vigorously and safely, and the current proposal will have the opposite effect.

What specifically do you think will be punished under this proposal that will inhibit technical discussion? (which @bryevdv beat me to)

which makes responding to any specific point difficult as the underlying objection is to something much deeper.

Again - it's very easy to respond to my specific points -

remove the immediate threat of judgment and punishment,

There are bad actors that will show up in OSS projects.  We as a community have been relatively lucky (as far as I know, which might just reflect badly on me) in not having many of them.  They will need to be dealt with and having a written down process for dealing with them is better doing at ad-hoc transparency reasons.  Is the assertion that we can only use carrots for self-moderation?  That no one can ever say 'That was out of line, please do not do that again' (publicly  or privately)?

emphasize learning and consent over enforcement,

This is effectively the exception handling mechanism when normal in-band has failed.  No one disagrees that a more formal mentoring / on boarding program would be great!  Or that such a program would reduce reports.  It is something we should do on all of our projects!  However, it is orthogonal to purpose of reporting CoC violations.   Would this be addressed by adding an outcome to the list of "mediation between the parties"?

hold the committee to account by making their judgements transparent to the parties concerned.

In the data collection part it seems pretty evident that the committee will talk to the people involved and they will have their chance to report their side, how likely is there to be any major surprises?  Adding something to get the individuals involved to get a more through than the public statement seems reasonable.  Ultimately the committee would be accountable to the SC
Related, 'appeals' were brought up earlier.  They probably should be expanded to include anytime engineering controls that reduces privileges are used.
I did not do a good job of distilling those points from your initial posts which contributed to my feeling that your position was moving.

This as approaching a straw man position. The exact wording is

I wanted to make sure that we understood each other here.   The current PR has, as first formal procedure, an appeal for judgement to a secret committee.
The alternative, that I am suggesting, is that there should be concerted, formal attempt to resolve the problem by negotiation and mediation, before triggering this procedure.   And that, during this procedure, the person complaining, and the person being complained against, has some named and formal support from the community, because this is a very frightening process.

We must make it possible to disagree, vigorously and safely, and the current proposal will have the opposite effect.
Where is evidence (not your personal feelings) for the general truth of this claim.

I must admit, it's really hard for me to imagine myself into the world, where the combination of very vague general rules of behavior, and a secret committee that judges on these rules, would not make people nervous about expressing things that are controversial.

Quick note (b/c I'm actually working on the docs :): the committee is not meant to be secret, and never was (see the Django one, which is what we're using as a starting point.
I'm doing my best to absorb all this feedback and post an update soon, thanks all for the input!

The only difference between the two is in this case the reporter has any visibility into what is going to happen, in the skimage case it goes into the blackbox of the the project lead that got emailed. The preference for the later cuts directly against the 'trust through transparency' from your first post.

Sorry - you seem to assume that I am advocating for the scikit-image CoC instead?   I'm pretty sure the the scikit-image team are working on a more transparent process.

I must admit, it's really hard for me to imagine myself into the world, where the combination of very vague general rules of behavior, and a secret committee that judges on these rules, would not make people nervous about expressing things that are controversial.

What sorts of things do you think are controversial and are related to the technical discussion?

Yes, your mentor scheme and the skimage process look about the same to me.

This is effectively the exception handling mechanism when normal in-band has failed. No one disagrees that a more formal mentoring / on boarding program would be great! Or that such a program would reduce reports. It is something we should do on all of our projects! However, it is orthogonal to purpose of reporting CoC violations. Would this be addressed by adding an outcome to the list of "mediation between the parties"?

Ah - excellent - that's very encouraging !   Yes, it would absolutely help to add this outcome to the list, and thanks for that suggestion.
My additional suggestion is that we formalize this process, as the first step, if informal negotiations have failed.   I can't see a disadvantage to this, and it seems to me to have many advantages in reducing the threat of this process, and potential for damage and ill-feeling, which is considerable.

Yes, your mentor scheme and the skimage process look about the same to me.

Specifically, I took you to be complaining about the skimage process where the email goes to the project leads.  You thought this wasn't formal or transparent enough.   I agree with you, but my proposal is, I believe, both formal and transparent, it's just that it allows and encourages the mentor to use every tool available to come to an agreement before triggering the judgement  / punishment phase.

@matthew-brett While I believe we are converging on common ground on broad concepts, I find a formal mentor model as you described as "frightening" as a member of an underrepresented group.
The formal mentors would come from a pool of individuals that are not yet a diverse, inclusive group. As others have mentioned, the mentors could likely suffer from biased thinking at best and gaming the system at worst. While I suspect this formal mentor proposal would work in a diverse community, the open source community has a long way to go to reflect the perspectives of underrepresented groups.
This proposal unduly burdens the member of the underrepresented group and forces them to take a huge leap of faith in trust.

Carol - I'm not sure I follow.    Remember that the mentor is there to support you and take your side.   The job of the mentor is to represent your point of view as you negotiate and agree with the other party.    If the mentor doesn't do a good job of that, and you don't reach agreement, the worst that can happen is that the complaint proceeds to the next stage, of judgement and punishment.   It seems perfectly reasonable that a woman could ask for a woman mentor / supporter, even someone from outside the project, but respected in the community.  The point is that the person complaining, and the person complained against, does not feel alone or unsupported.

The Django CoC and the PSF CoC have substantively and measurably improved the communities that they serve.

Carol - I think any fair system will eventually have to establish the complaint is valid.   For the mentor system, I was not proposing that the person complaining put any extra work into proving the complaint - the exact opposite.  The idea is that, with a supportive voice at the beginning of this process, the complainant will have to do less, because the job of the supporter is not to cross-examine you, but to say, right, yes, that sounds bad, let's see how we can fix this.  On the other hand, when the complaint goes to the tribunal, there's really no choice but go through the semi-legal process of establishing facts and so on, which is bound to be painful and unpleasant.  My argument is that most people don't want to go through that, they want to fix the problem in the most reasonable and kindly way that they can, and my suggestion was to make that possible.  Of course, sometimes that isn't possible, and that's why there's the judgement / punishment backup.

I must admit, it's really hard for me to imagine myself into the world, where the combination of very vague general rules of behavior, and a secret committee that judges on these rules, would not make people nervous about expressing things that are controversial

Those seem like your personal feelings. Can you point to any observable, demonstrable, quantifiable or describable diminution int the quantity or quality of germane technical discussion around any OSS project that has adopted a CoC, as a result of having adopted the CoC?

Those seem like your personal feelings. Can you point to any observable, demonstrable, quantifiable or describable diminution int the quantity or quality of germane technical discussion around any OSS project that has adopted a CoC, as a result of having adopted the CoC?

Just to see if I can understand your question - do you agree with this statement?
"On average, people who tend to agree with the majority are more favorably viewed than those who disagree"?
If you do agree, I am sure you can imagine a mechanism where a less popular member of the community would be less likely to be given the benefit of the doubt in a tribunal, for which the rules were ill-defined and up to interpretation.
As to damage from the code of conduct, a few points:

we're not discussing whether or not to have a 'code of conduct' (I think that's a very bad name for it, but that's another point);
if I systematically removed 10 percent of the committers every year, it would take a long time before there was clear objective evidence of harm, because there are so many other variables in play;
we're talking about what kind of community we want.  Do we want a community that is scared to disagree, or do we want a community that values and supports disagreement.  Even if it was not possible to show an objective benefit of the second, I would chose the second.

we're talking about what kind of community we want. Do we want a community that is scared to disagree, or do we want a community that values and supports disagreement.

The PR very clearly communicates the expectations of the type of community and the intent of the CoC document.
Project Jupyter is an engaged and respectful community made up of people
from all over the world. Your involvement helps us to further our
mission and to create an open platform that serves a broad range of
communities, from research and education, to journalism, industry and
beyond. This diversity is one of our biggest strengths, but it can also
lead to communication issues and conflicts. Therefore, we have a few
ground rules we ask that our community members adhere to.

Fundamentally, we are committed to providing a productive,
harassment-free environment for everyone. Rather than considering this
code an exhaustive list of things that you can’t do, take it in the
spirit it is intended - a guide to make it easier to enrich all of us
and the communities in which we participate.

This code applies equally to founders, developers, mentors and new
community members, in all spaces managed by Project Jupyter. This
includes the mailing lists, our GitHub organizations, our chat rooms,
in-person events, and any other forums created by the project team. In
addition, violations of this code outside these spaces may affect a
person's ability to participate within them.

If you believe someone is violating the code of conduct, we ask that you
report it by emailing
[*conduct<EMAIL_ADDRESS>or by filling out
[this form](https://goo.gl/forms/sJzOIie3zde9M71T2). For more details
please see our Reporting Guidelines.

By embracing the following principles, guidelines and actions to follow
or avoid, you will help us make Jupyter a welcoming and productive
community.
If that doesn't answer your questions, feel free to contact us at
[*conduct@jupyter.org*](mailto:conduct@jupyter.org).

1. **Be friendly and patient**.

2. **Be welcoming**. We strive to be a community that welcomes and supports
   people of all backgrounds and identities. This includes, but is not limited
   to, members of any race, ethnicity, culture, national origin, color,
   immigration status, social and economic class, educational level, sex, sexual
   orientation, gender identity and expression, age, physical appearance, family
   status, political belief, technological or professional choices, academic
   discipline, religion, mental ability, and physical ability.

3. **Be considerate**. Your work will be used by other people, and you in turn
   will depend on the work of others. Any decision you take will affect users
   and colleagues, and you should take those consequences into account when
   making decisions. Remember that we're a world-wide community. You may be
   communicating with someone with a different primary language or cultural
   background.

4. **Be respectful**. Not all of us will agree all the time, but disagreement is
   no excuse for poor behavior or poor manners. We might all experience some
   frustration now and then, but we cannot allow that frustration to turn into a
   personal attack. It’s important to remember that a community where people
   feel uncomfortable or threatened is not a productive one.

5. **Be careful in the words that you choose**. Be kind to others. Do not insult
   or put down other community members. Harassment and other exclusionary
   behavior are not acceptable. This includes, but is not limited to:
   * Violent threats or violent language directed against another person
   * Discriminatory jokes and language
   * Posting sexually explicit or violent material
   * Posting (or threatening to post) other people's personally identifying
     information ("doxing")
   * Personal insults, especially those using racist or sexist terms
   * Unwelcome sexual attention
   * Advocating for, or encouraging, any of the above behavior
   * Repeated harassment of others. In general, if someone asks you to stop,
     then stop

6. **Moderate your expectations**. Many in our community volunteer their time.
   They are probably not purposefully ignoring issues, refusing to engage in
   discussion, avoiding features, etc. but often just unavailable.

7. **When we disagree, try to understand why**. Disagreements, both social and
   technical, happen all the time and Jupyter is no exception. It is important
   that we resolve disagreements and differing views constructively. Remember
   that we’re different. The strength of Jupyter comes from its varied community
   that includes people from a wide range of backgrounds. Different people have
   different perspectives on issues. Being unable to understand why someone
   holds a viewpoint doesn’t mean they’re wrong. Don’t forget that it is human
   to err and blaming each other doesn’t get us anywhere. Instead, focus on
   helping to resolve issues and learning from mistakes.

8. **A simple apology can go a long way**. It can often de-escalate a situation,
   and telling someone that you are sorry is act of empathy that doesn’t
   automatically imply an admission of guilt (Canada has turned
   [*this notion into law*](http://www.theloop.ca/canadians-love-to-say-sorry-so-much-we-had-to-make-this-law/)).

Sure, of course one can say "we value disagreement" - but if the procedures say "but we'll punish you without recourse if we think you've stepped out of line, on any of a wide range of vaguely defined grounds", then the message is pretty clear.

Hi all,
I'm sorry that I have to run to a doctor's appointment right now, but I've spent most of the day trying to absorb and incorporate all of the feedback from this discussion... I'm sure my changes aren't perfect, but I tried to include:

emphasis on good-faith, productive engagement rather than only punitive actions.
clarifications about the committee's composition, communication process and visibility.
guidelines and principles the committee should honor when dealing with complex situations.
an idea for a mediation mechanism as an optional tool.
explicit consideration of non-native speakers and foreigners: as a member of both groups, I am acutely aware of this issue.

I'm sure what I've written won't make everyone here happy, and I value further input.  I think there's been a lot of valuable discussion above (even in the midst of what I recognize is serious disagreement on a difficult  topic).
I do hope my changes move us in the right direction... Please let me know :)
Thanks for everyone who helped!  I'm sure I've left some credit out in my haste, please do point it out and I'll ammend as necessary.

Folks, thanks for the extra feedback (@willingc, @tacaswell)! I've made changes accordingly, let me know how it looks...

@willingc, I do genuinely think that there can be instances where mediation can be valuable, as long as it is strictly voluntary.  I have seen complex situations where multiple actors end up creating a "gordian knot" that is more productively disentangled with all parties at the table than with a one-sided assignment of responsibility/blame.
But this doesn't in any way force a reporter who may feel unsafe, threatened or mistreated into an even more damaging situation:

The committee should exercise judgment and consider proposing mediation only when it seems genuinely valuable and relevant.
The reporter still has complete freedom to decline.

The way I see it, it's adding a tool into the toolbox that can be useful.  I see no need to remove a potentially useful tool from our options a priori, given the setup I've proposed here.

All: thanks again for maintaining a productive discussion even in the face of such a complex topic that I know often stirs up a lot of complex feelings.  We have all seen these kinds of conversations degrade, sometimes catastrophically, and I'm glad this hasn't been the case here: I know it's been tense, but we haven't gone off the rails.  Let's keep it that way :)
I have done my best to carefully consider all input given and improve our documents accordingly, while trying not to make them unmanageably long (happy to take content-neutral wordsmithing help that can shorten things, if anyone wants to!).
I genuinely think this has led to real improvements: I am not simply trying to "split the difference" by giving everyone a bit of what they ask for.  I carefully considered all input, and only added changes that I felt, sincerely, would lead to better outcomes.  You may disagree with me on any such changes (and you may convince me that I'm wrong!), but I hope you will trust that I made them with the long-term well-being of our project and community in mind.
In the end, Codes of Conduct are a community formalization of a lightweight "justice system".  Like all such systems, they will be imperfect: we all know that the legal systems of all countries often support and produce injustices.  Yet (and I say this as someone who grew up in one of the most violent societies on the planet and with complete criminal impunity around me), we hopefully  agree that an imperfect justice system is still better than not having one.
I hope that what we have here does a good job of balancing multiple concerns and is fair, provides robust and meaningful protections and redress to any who may need them, promotes the growth of our values in our community, and will support healthy and diverse engagement on the vast range of challenges that Jupyter tackles today.
I have the sense that we're getting close to something we can move forward with, let me know if that's not the case. Thanks again!

On Wed, Dec 28, 2016 at 19:10 Thomas A Caswell<EMAIL_ADDRESS>wrote:

@tacaswell commented on this pull request.
In conduct/conduct_enforcement.md
https://github.com/jupyter/governance/pull/23#pullrequestreview-14628692
:
+## Conflicts of Interest

+In the event of any conflict of interest, a committee member must immediately
Should they find a stand in?

Honestly,I don't think so: given that we want to avoid delays in response
time,I think it's better to proceed with four members for a single incident
than to wait and try to get a replacement.
Obviously a persistent conflict should lead to replacing that committee
member.

Hi Fernando, and thanks for introducing some calm to the discussion.

In the end, Codes of Conduct are a community formalization of a lightweight "justice system".

That's right - but this justice system is lightweight in all the wrong places.  It's extremely heavy in the massive range of behavior over which it claims authority, but extremely lightweight in the specifics of what constitutes a breach.   To deal with that disparity, it relies on the wisdom and judgement of a conduct enforcement committee.    This boils down to an extraordinary increase in the legislative power of the project.    If you're the type of person who is happy to put their faith in this kind of society, of course that's a big win.    If you aren't, then this document is going to be a huge red flag.  If I were starting out now, and read this document, I would conclude that this community was authoritarian, conformist, self-righteous and paranoid, and I'd stay away at all costs.
How to fix that?   The work that needs doing is a) restrict the range of behavior that the code claims authority over.  For example, no-one would object to measures to control frank harassment, they're clearly necessary; b) spend some serious work clarifying what constitutes a breach.
At this point, you might reasonably object that this is too much work.  That's right, but the way round that is to start small and enlarge with experience.  I mean, specify the stuff where you can be confident most reasonable people would agree this is not acceptable, claim authority for (eventual) judgement over that, and elsewhere, use the machinery to advise, and collect experience, for any potential increase in jurisdiction.

Would a sentence/paragraph saying that "this code of conduct is subject to improvement and feedback/addendum are welcome" be a good idea ?

By the way - I think the primary problem here is that this "code of conduct" is both a manifesto for a desirable community - "community guidelines" and the specification of a legal system.   Because they are in the same document, the legal system claims jurisdiction over every desirable behavior in the guidelines.    How about splitting the document into two, with a sort of community manifesto, which can concentrate on the positive aspects of community, and a separate 'when things go wrong' document, that clarifies more precisely what is within the scope of the judge / punish system?  In that case, I think your new members will first read an inspiring document on desirable community, and then go to rules part of the doc, and think 'sure, those are things to which rules should clearly apply'.
For example, there is a section in the code of conduct titled "Be friendly and patient".   At the moment, the reader could conclude that if they were not sufficiently friendly or patient, they could get into trouble with the conduct enforcement committee.  I suggest that "Be friendly and patient" be dealt with by personal interaction, exclusively.  I mean, that should someone be unfriendly, or impatient, they should not expect to find that a complaint to be lodged against them to the<EMAIL_ADDRESS>email address, they should expect to get friendly and informal shots across the bows from senior project members.  If these are not effective, then they'll get less friendly public emails saying 'no, that's not how we do this here'.

I hope that what we have here does a good job of balancing multiple concerns and is fair, provides robust and meaningful protections and redress to any who may need them, promotes the growth of our values in our community, and will support healthy and diverse engagement on the vast range of challenges that Jupyter tackles today.

Thanks @fperez. Your genuine giving of your time and perspective is appreciated.
I sincerely hope that this CoC as it reads at this moment helps move the project forward from the "status quo" to becoming a more welcoming and effective community, particularly for women and underrepresented groups. Anything that takes away from that goal would be a sad price to pay.

@Carreau, I'm not sure we need to explicitly say that here: all our documents and materials, by virtue of living openly on github with PRs and issues, are by definition open to continued refinement.
If anything, if there was ever something we'd consider completely immutable, that's what should be flagged as an exception.  But we don't need to say "our usual procedures also apply here, as they should".
My key question for you is: do you think the changes made yesterday address your concerns regarding language/cultural barriers? As I said, I am a member of the same group (though I've lived much longer than you in the US) and I'm keenly aware of this issue, having made my share of culture-gap mistakes.  I tried to add language in several places to address it very explicitly, let me know if you still see a problem and we'll keep iterating.

@matthew-brett, re. the splitting of the doc: no.  I explicitly wanted it to be structured this way as a single document, precisely because I think it's more effective to have the complete message in one place, opening with a positive and welcoming framing but acknowledging that things can and do go off the rails.  I know we disagree here, but it wasn't a lack of consideration of the alternative.

Fernando - sure - I understand the rationale for putting it on one doc, but it does have a cost.

Thanks @ellisonbg! Most were small things, see question up there on appeals boundaries (others may want to pitch in too).

On Thu, Dec 29, 2016 at 3:57 PM, Carol Willing<EMAIL_ADDRESS>wrote:

I agree with @ellisonbg https://github.com/ellisonbg that loss of
privileges should be able to be appealed. I'm with @tacaswell
https://github.com/tacaswell that appeals of communication violations
are likely to devolve especially if the P(erson) has difficulties with
boundaries and always needs to have the last word. In general, I don't find
public shaming or reprimands very effective.

We currently have Thomas' version, but in thinking further about this, I
was thinking of going back to Brian's original (appeals option for all
actions).
I realized that this is a case where we do have control to prevent things
devolving: the appeal goes to the SC, and the SC makes the call.  It's not
an open-ended option for discussion, but a chance for the SC to review how
things are going.  I really see no harm in that, other than we may get an
extra few emails at the SC list (hopefully very rarely, as I would like to
think we're not going to have a flood of CoC complaints :).
I certainly don't want it to turn into never-ending discussion of every
decision, but given this specific implementation, I see no risk of that.
Thoughts?

Thanks for the feedback, @parente! Re. how to change the document: all docs in this repo operate under the same guidelines listed here.  Do you think that's not sufficient?
I'm a little loathe to keep adding internal cross- references that will need maintenance/updating, given the main doc is reasonably visible and easy to find by itself...

Re. how to change the document: all docs in this repo operate under the same guidelines listed here. Do you think that's not sufficient?

Ah yes. The text there is sufficient.

My gut feeling would be to never restrict appeal. No one wants to get
trapped in a wormhole of infinite response, but in practice momentum
rapidly slows when it becomes clear that the community is in more-or-less
unanimous opposition.

@stefanv I may be misinterpreting your comment here related to appeals:

the community is in more-or-less unanimous opposition.

I'm ok with appealing all but I want to caution that if the appeals process becomes a way to circumnavigate or game the CoC committee (a large number of overturned decisions) that the community/SC look at whether unconscious bias by the majority has crept into play.

@parente Great to see your suggestions here. Please make sure that we sufficiently address them :sunflower:

Reading the Geek Feminism Wiki just now, led me to this page: http://geekfeminism.wikia.com/wiki/Code_of_conduct_evaluations
That page does a better job of explaining the point I was making above, about the over-reach of the code of conduct in covering general behavior, such as being friendly, and the lack of specifics about what constitutes a breach:

Important elements of an effective code of conduct include:
...
A clear demarcation between unacceptable behaviour (which may be reported per the reporting instructions and may have severe consequences for the perpetrator) and community guidelines such as general disagreement resolution.

Matthew, Cool that you are checking out the resources. Let's put your previous comment on the list of things to discuss in person at BIDS. There's a bit more history and nuance (more than I can put in writing) that isn't captured when looking at just the one bullet point.
Please see additional linked article in the referenced GF wiki page:  https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/ This particular section is important:

Besides making your project more pleasant and efficient for people already involved, a code of conduct attracts new people. The OpenHatch wiki explains it this way: “As a new contributor, you might prefer FLOSS communities where contributors pay attention to these sorts of social questions. Having a code of conduct is often an indicator that a project has a sizeable number of contributors and interested in growing.”

Two community codes of conduct we especially like are the Django code of conduct and the Rust code of conduct. Why? Because these codes of conduct:

List specific common behaviors that are not okay
Include detailed directions for reporting violations
Have a defined and documented complaint handling process

Without these elements, a code of conduct isn’t worth the electrons used to display it on your computer screen. In fact, a code of conduct that isn’t (or can’t be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren’t actually important or respected in your community.

To all of my peers that have put time and effort into moving this forward, I humbly thank you. Those who know me well know how much I want to share the amazing Jupyter projects (and the other wonderful packages in the ecosystem) with others. Several years ago, I told folks that I hoped that the notebooks would go viral as I had already observed their potential for engaging high school and college students. I saw the notebooks accelerate new Python learners' understanding and interaction with the language (as well as simplifying teaching an Intro to Python workshop). To me, the CoC is a step toward engaging these users to see that they too can be contributors to the future of this project.
As I sign off from GitHub for the remainder of 2016, thanks for being a great group of individuals. I hope you will take a moment to look back on all the team has accomplished in 2016. Here's to 2017 and sharing the project with the world. :heart: 🌍

@matthew-brett Point 5 of the code has a (non-exhaustive) list of things that are specifically disallowed.
And I think point 7 does a pretty good job explaining that in general disagreements are something to be worked through with empathy and civility by the community rather than something that will necessarily be policed by the CoC (unless actions cross a boundary, such as those listed in point 5).
A different way of organizing things comes from the Contributor Covenant Code of Conduct:

Our Standards
Examples of behavior that contributes to creating a positive environment
include:

Using welcoming and inclusive language
Being respectful of differing viewpoints and experiences
Gracefully accepting constructive criticism
Focusing on what is best for the community
Showing empathy towards other community members

Examples of unacceptable behavior by participants include:

The use of sexualized language or imagery and unwelcome sexual attention or
advances
Trolling, insulting/derogatory comments, and personal or political attacks
Public or private harassment
Publishing others' private information, such as a physical or electronic
address, without explicit permission
Other conduct which could reasonably be considered inappropriate in a
professional setting

Points 1 - 4 of Jupyter's proposed Code are similar to the positive examples from the Contributor Covenant. Point 5 covers some examples of unacceptable behavior. The Citizens Code of Conduct has a similar organization. So the content here is already similar to many other Codes, but the organization is slightly different from those two examples.
Also while digging around I found that the Django CoC on which this is based gets high praise from the Ada Initiative: https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/

👍 I am happy with those changes @fperez

Hi all,
I'm having some discussion with some people in France, I'll make a longer comment later, but I believe with the backlash that happen against @matthew-brett it might be that others are no pitching in. Indeed it feels like  expressing opinion against the current state of the CoC is automatically seen as a way to derail the discussion and troll, and users might be afraid of giving feedback.
I propose that we allow anonymous feedback on the CoC via a google form.

Free Text field for comments.
[Boolean] Do you consider yourself part of a minority
on a scale from -X to X  how likely is this CoC going to influence your (potential) participation, -X being I have less chance to start contributing, if I'm already contributing I'll likely contribute less. +X will likely contribute more.

I'm having some discussion with some people in France, I'll make a longer comment later, but I believe with the backlash that happen against @matthew-brett it might be that others are no pitching in. Indeed it feels like expressing opinion against the current state of the CoC is automatically seen as a way to derail the discussion and troll, and users might be afraid of giving feedback.

I have heard from several people that they are inhibited in discussing their concerns about things in this PR (and I felt the same way too), at least in part from seeing some of the comments @matthew-brett received here or on twitter, etc. I thought it a bit ironic.

I am really interested in hearing thoughts about all this from people in different cultures, particularly cultures not represented among those that have given comments already.

I have heard from several people that they are inhibited in discussing their concerns

I was concerned to be the only one in contact with these kind of people. Thanks for pitching.

I'm reposting @fperez' original emails to the Jupyter mailing list. If an individual has been concerned about posting here publicly, I highly recommend reading these emails for alternative ways to comment:
Hi all,

it has taken us far longer than it should, but thanks to the persistent work of a number of folks on the team, we finally have a PR ready for public feedback!

https://github.com/jupyter/governance/pull/23/

These community guidelines/CoC documents were inspired by the ones from the Django team (https://www.djangoproject.com/conduct), which seemed to us as having some important qualities:

- Validated by real-world experience from a large and active project and community.

- It highlights the positive reasons why all guidelines are the way they are: across the guide, there's an emphasis on how it is a guide for building a better community in the face of complex and challenging interactions, rather than simply a laundry list of "mandated don'ts".  I personally find that approach much more productive in the long run.

I want to emphasize that while the PR appears as mostly mine, this work was done in conjunction with many others mostly during our most recent in-person project meeting at Cal Poly, and this PR should be seen as the official proposal from the project's Steering Committee and other core developers present at that meeting.  We welcome input and feedback on the PR and are open to clarifying/refining specifics, but we're committed to moving forward with something very much along these lines.  If someone feels very strongly that we should not have these guidelines in the first place, it may not be worth your time trying to argue that point, as the decision to adopt them is a done deal.

Multiple people have helped with the drafting and tuning of these documents for our project, even if we started with the excellent base provided by the Django team.  I'd like to particularly thank Reese Netro (without her dedication this task would have lingered in my perpetually late todo list til who knows when), Ana Ruvalcaba, Carol Willing and Yuvi Panda, who put in a lot of extra time to make it happen, as well as the excellent points about CoCs made by Safia Abdalla in her newsletter (http://tinyletter.com/captainsafia).

Please provide any feedback you may have on the PR, as usual, and we'll all do our best to respond.  We'd like to merge this sooner rather than later (ideally by the new year, though given folks' travel/holiday schedule we may slip by a few days).

One final note: if you'd like to help us with translations of these docs, great!! We have an issue open for that: https://github.com/jupyter/governance/issues/28.

Thanks again everyone, and sorry this took so long :)

Cheers,

--
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail

and
On Wed, Dec 21, 2016 at 7:02 PM, Fernando Perez<EMAIL_ADDRESS>wrote:

it has taken us far longer than it should, but thanks to the persistent work of a number of folks on the team, we finally have a PR ready for public feedback!

https://github.com/jupyter/governance/pull/23/

oops, one more thing I completely forgot to include in the original email!  While we have framed the composition of the committee that would handle this as the responsibility of the Steering Council, it doesn't mean its *members* have to be all from the SC, quite the opposite.

We want, and should have, a mix, so we'd love to ask for folks from the community who'd like to volunteer to be part of this team, whether you are in the SC or not.  If you'd like to do so via PR, feel free to comment in the PR issue with a short note about why you'd like to help and any relevant experience you may have (if so, it's not like we're asking for a CV, but it helps if you have already participated in similar setups elsewhere).

If you prefer to do so privately, feel free to send a short email to<EMAIL_ADDRESS>
Thanks to everyone who has responded on the PR with input/fixes/questions, I'll be back on it shortly :)

Cheers

f

--
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail

I have heard from several people that they are inhibited in discussing their concerns about things in this PR (and I felt the same way too), at least in part from seeing some of the comments @matthew-brett received here or on twitter, etc. I thought it a bit ironic.

This doesn't tell the whole story, though (sorry!). I eventually started participating because I saw the great lengths that especially @willingc and @fperez went to in order to have a constructive and respectful conversation. Thanks @willingc and @fperez! (And thanks to the others that have contributed in likewise manner!)
As it stands now, I am supportive with reservations (to use one of the gradations in the consensus scale that we talked about in the dev meeting), with the main reservation being the conflation of community guidelines/etiquette with more serious code of conduct issues, without a lot of clarity about what sorts of infractions warrant serious actions. That said, I'm still working through my thoughts on the implementation details of something like this.

I am in support of merging this because this is already much better than having nothing.
It would probably be more productive to discuss the remaining points being discussed after this initial version is merged.

Thank you @jasongrout and @SylvainCorlay for the support despite reservations.
I want to share the ACM Code of Ethics and Professional Conduct that has been in place since 1992 (ACM = Association for Computing Machinery). The full document is contained here: https://www.acm.org/about-acm/acm-code-of-ethics-and-professional-conduct
It's important to me personally since professional conduct helps us, as a community, create a working environment based on mutual respect and the common goal of making useful and world class software under the Project Jupyter umbrella.
I fully believe that I, and other as well, will continue to work in the best interests of the community and iterate these documents as needed. You have my word on that. Thanks!

I want to share the ACM Code of Ethics and Professional Conduct that has been in place since 1992 (ACM = Association for Computing Machinery). The full document is contained here: https://www.acm.org/about-acm/acm-code-of-ethics-and-professional-conduct

Thanks. I like how they clarify that membership may be in jeopardy with gross misconduct:

However, if a member does not follow this code by engaging in gross misconduct, membership in ACM may be terminated.

which clarifies a bit more how much things are policed, which in some ways addresses some of the comments above about separating etiquette from more serious problems.

It's important to me personally since professional conduct helps us, as a community, create a working environment based on mutual respect and the common goal of making useful and world class software under the Project Jupyter umbrella.

I think we all agree there! It's the implementation details and ramifications that we're carefully considering.

As it stands now, I am supportive with reservations

(though I still think the outstanding change requests Carol and I discussed above should still be made)

I am also approving this code of conduct. Thank you to everyone who put in so much time, effort, and attention to it!
I understand the benefit of having a document like this, and in general feel it is more inclusive to have something like this in place and alter it down the line if any problems arise. So in a way, I was going to approve it just on those grounds alone - I want the Jupyter community to continue to be friendly and  welcoming and see this as another way to signal that.
But at the same time I had reservations, for example about the code of conduct over-promising, or the potential for cargo-culting by way of tons of projects just having code of conduct without it carrying any meaning. This was difficult to put down into writing, so I won't try to do it now, but in some ways not writing anything here and simply pushing the accept button felt lazy and somewhat dishonest. I am grateful for several people who engaged me in conversation to process this.
I want to thank @matthew-brett for speaking up to question and challenge the wording as it stood originally. I think a very important thing fell out of this process is the record of activity and conversation about these issues. I think this is a more meaningful document as a result of all of our effort.

I think it's worth considering why some people do not want to join in this discussion.   I understand why people wouldn't want to join in, it wasn't at all pleasant for me, and I had many reasons to feel safer than average - I know many people in this organization personally and I've been around in the scientific Python community for a long time.
There are two aspects that I think are important.   First is a general one, that it appears to be completely ordinary to assume and assert that someone who disagrees (me in this case) is doing so to be perverse, therefore making it pointless or even counterproductive to address the substance of the argument.  This is mainly from the Twitter comments, but it also comes through in the tone of some of the discussion on this PR.
The second is, that it is generally clear when reasoned disagreement is welcome, and when it is unwelcome.   Welcome is where the people in the discussion do some work to thank the person making the disagreement, show that they have read and considered the arguments, and address their points in a substantial way.  When the topic is tough, as here, that really has to be the people in charge.    I don't think that has happened here, and I think that was obvious enough, that people reading the discussion realized that they'd be given less than warm treatment if they joined in.
I don't think it's too late to do that, and I think it's worth trying to improve the width of the discussion, in order make the document as good as it can be.  Specifically, I believe that the current document is particularly odd and threatening to people from cultures outside the US, for the reasons that I've already given, and that it would be perfectly possible to reshape this document, so it does cover the cases that need covering, and can get the enthusiastic endorsement of everyone in the community.   In order to do that, I think the document does need to be split so it's clear from its parts, which are recommendations for good etiquette, and which are categories of behavior subject to the formal complaint / enforcement procedure.   I'm sure that, if you do that, you can get everyone on board, and still get all the benefits you are hoping for.
I'm very happy to help do that, but as for my previous posts here, I'm trying to get some agreement that is a good way to go.

Sorry - I should make clear - I'm not asking to be thanked here, I'm saying that I think it would be worth someone with unquestioned authority making it clear that discussion about the reach and tone of the document is important and welcome, and that there is no rush to merge the document before that discussion has run its course within some reasonable time.

I also think that it's worth considering why women and other underrepresented groups are not sharing their thoughts in this forum.

I'm equally concerned that each message and day that this thread continues as is makes this community look less and less welcoming to underrepresented groups. There is an implicit assumption that the community is very welcoming and friendly to all as is. Is that really accurate?

I feel very strongly that the status quo (No Code of Conduct) is insufficient. A CoC very similar to this has already been adopted by PyData, the PSF, and many other organizations. I'm willing to continue discussion and iteration after an initial CoC is adopted. Until then, I respectfully decline to participate further in this thread.

I forgot that I could push changes directly to @fperez's branch. I made changes that were discussed in my comments above in https://github.com/jupyter/governance/pull/23/commits/791f32968958693e2b29566e4f4b1e8000b66b50

@matthew-brett Is the example I posted in a previous comment more appealing to you?

@jiffyclub - thanks for pointing me back to your previous post.  Yes, absolutely, it would be a huge help to separate the would-like and will-enforce stuff like that.

Brian - sorry - I meant Matthias comment here where he implies that he is talking to people that are afraid to express their opinions because they'll be dismissed as trying to derail the discussion and troll.    You might be saying the solution is to make line-by-line comments on the current text, but I suspect the comments that Matthias is referring to, are about the general structure, such as the discussion about splitting the document into guidelines and rules for more specific forbidden behavior.  In that latter case, it's specific, but it does require some degree of agreement before taking action, and the current atmosphere is pretty tense.

@matthew-brett I humbly and sincerely suggest that if you would like for everyone to consider a version of the doc with etiquette and enforcement split into different sections, the very best way for that to happen would be to provide an actual diff.

@matthew-brett

We already have a way for people to provide private feedback (conduct@jupyter.org). I am fine with a Google form for feedback in general. However, some of the questions that @Carreau is proposing look more like a survey of opinion. If we wanted to draw actual conclusions from such a survey, we would need to conduct a survey in a manner that didn't suffer from participation bias. Let's see what @fperez thinks.
It was a very deliberate choice to combine the etiquette and enforcement. The etiquette is critical as it provides the underlying spirit and ideas the enforcement section is based on. Another way of thinking about it is this: we want to offer a CoC that balances positive behavior that we want to encourage and negative ones we want to discourage. We may be able to better organize our documents to clarify these distinctions though.

@ellisonbg - sure - as I said above, I understand the motivation for keeping the docs together, but the big problem is that the effect is that enforcement is applied over far too wide a range of behavior, making for a very unattractive document that seems unnecessarily overbearing and prescriptive.

@bryevdv @jiffyclub - I humbly suggest that you read over @Carreau's several posts here, and in particular, about the aggressive tone of the posts on Twitter.
Of course, if you want the discussion to stop, getting this PR merged as soon as possible is a good idea.   But I hope that you agree that it is not a good situation, where there are some people who do not feel that they will be given a fair hearing, and are avoiding this discussion as a result.

@matthew-brett I can only re-iterate my suggestion that the appropriate thing for you to submit for consideration in this setting is a concrete, constructive, actionable proposal. i.e., a diff that contains the actual words you think should be in the actual document.

I abuse your patience more - can you suggest a way of making it easier for
@Carreau and others to express their concerns so they can be addressed?

I have no issue expressing my though and feedback here, even if I would get a
backlash. I just need time to express them in the right way which takes time,
and a bit more than usual as I got some minor health issues.

@matthew-brett I humbly and sincerely suggest that if you would like for
everyone to consider a version of the doc with etiquette and enforcement
split into different sections, the very best way for that to happen would be
to provide an actual diff.

@bryevdv, @matt-brett expressed his reasons not to do so. I feel like your
comments could be seen has having the same issues than what you are accusing
Matthew of.

We already have a way for people to provide private feedback
(conduct@jupyter.org). I am fine with a Google form for feedback in general.

Private feedback =! Anonymous feedback.

However, some of the questions that @Carreau is proposing look more like a
survey of opinion.

That's mostly to know whether the feeling are first hand, or reported. Someone
who tells you they are a minority and feel scared about CoC is different than
someone telling you that User X might feel uncomfortable.

At this point I'd suggest that the best way to refine the CoC would be to
merge this PR and allow people to make new pull requests against the existing
document.

Agreed.

However, there is a history of CoC discussions getting sidetracked and
torpedoed. I think I can speak for our entire Steering Counsel in saying
that we (the Steering Council) is fully on board with the idea of having a
CoC and support the overall approach expressed in this current draft.
Because of that, if the feedback anyone has is along the lines of "the
project should not adopt a CoC" or "this entire approach is wrong," the
Steering Counsel will likely not take action on the feedback. Any SC member
who disagrees with that is welcome to correct me.

As a Steering Council Member, with my Steering Council Member I have to agre.
Me as a person, As a French, who have spend only a couple of years in the US,
with my "me" hat don't completely agree.
Honestly, if 5 years ago IPython and SciPy (the conference) had CoC, I would
likely no be here today. My 5 years ago self, would have been scared enough
from contributing or come to the US. You might not even realise it but the fact
that there is a CoC document can be seen in some culture as a warning sign
not to participate. Regardless of the language used.
This is a deeper problem that some people, me included, have with understanding
the US culture. The bound of accepted behavior is restricted in such a way that
you don't even think to try to get close to the borders. Then you can't even
infer what people are thinking as what they say is always "politically
correct". This installs habit of always being on your guards and never trusting
people words.
I have, and still am regularly restricting myself from speaking or expression
my opinion in meeting/conferences/online discussions because of documents like
this one. So as a person I do think that in some context/culture adopting a
CoC is wrong. That's not saying that you should behave badly though.
It also affect the time I take to write responses. It already takes me 2x-3x
more time to write an email in English than a native speaker, the CoC will make
me weight even more on my words, so let's make that 3x-4x time longer minimum.
Not counting that it's more energy draining. So the net effect of the CoC will
be that I'm less likely to respond to a question.
 It's ok because I know the room, and if I fell in the pit, I know
someone may help me to get out and patch me up. It may feel for some people
like the pit is only made for bad people. But it also scares the heck out of
some other people that will not even dare to take a step.
Apologies if this is short, accidental "swipe for previous page" made chrome
died and I lost my previous (longer) draft.
But for the sake of time, let's merge this and iterate.

@bryevdv, @matt-brett expressed his reasons not to do so. I feel like your
comments could be seen has having the same issues than what you are accusing
Matthew of.

I don't see how? I'm not asking for any changes, much less big ones. Everyone else who has suggested changes has done so constructively by actually offering up concrete proposals, .i.e. "this exact section should say these exact words", and I unapologetically will state that I think that is a reasonable expectation in this context.

Thanks for that perspective Matthias, that's really interesting. For me a CoC is a signal that I'll be able to participate in a project/community with a lower risk of having to deal with harassment, abuse, sexism, racism, or personal attacks. Sadly those things are common enough, and abusers bold enough, that in order to create a safe community I think it is necessary to explicitly say those things are not permitted.

Thanks for that perspective Matthias, that's really interesting. For me a CoC is a signal that I'll be able to participate in a project/community with a lower risk of having to deal with harassment, abuse, sexism, racism, or personal attacks. Sadly those things are common enough, and abusers bold enough, that in order to create a safe community I think it is necessary to explicitly say those things are not permitted.

I've personally lived and felts the other way. I understand that I do match the stereotype of the 25-35 white male in tech, and in the bay area, {extend with stereotype here}. And was told not that long ago that my opinion was not welcome (to lower my hand not to ask a question) because the person who was speaking had made themselves from 0, grew up in a rough family, and earn by themselves the right to attend fancy schools, tacitly making me aware that any attempt to contradict them were not welcome, because I could not possibly understand. If you know about my background, and where I came from, you'll understand that this is far from being the case. Btw the discussion was purely technical, and in no way related to minorities, inclusivity or background of speaker.
I completly believe that the person who did it clearly told me to refrain myself from speaking without  even realizing what they were doing it. Did not even realize that I may even be able to understand what the life of the speaker, and did not even realize that I might not even going to disagree with the speaker.
 Unfortunately a CoC and enforcement as a weapon of dissuasion is extremely efficient. You don't even need to use it, you just need to warn the other "I'm going to tell on you".
That's (fortunately) an extreme case, but unfortunately a behavior that I tend to see more and more.
Is it because it has increased, or because I'm just paying more attention and seeing it more, I can't say.
You can get bitten once, move over to another community, twice, and then you start to just skip things that have a CoC.
So now I'm worried of every place that have a Code of Conduct, and enforcement policy, because even if in the end we are all consenting adults, the range of what is "acceptable" as high chances of decreasing and IMHO lock the community in an echo-chamber. Everything which is out of ordinary ends up as not-appropriate, in the same way as secrecy become contagious and other ridiculous censure rules.
What starts as a perfect good faith document for inclusivity can end inadvertently as a way to exclude other culture or way of thinking. Just in this thread:

Not providing exact wording and changes are a sign of bad faith: Well, what if you not an english speaker ? Understanding and writing english are 2 differents things.
Feedback mostly (only) from people with GitHub Account.
No Anonymous comments (they "can" send things to<EMAIL_ADDRESS>but do they even know who will receive and that's private , not anonymous)
Implicitly people "against" code of conduct will not be listened to.

I deeply wish that this does not becomes the case in here, and really hope the CoC will help things, and does not segregate groups in the end.
Just to remember that the vocal part of a group is only a tiny percent of the overall, I'm linking the relevant SMBC:
http://www.smbc-comics.com/?id=2939
merging.
We have 12 approval, and no more requests for changes so I'm going to merge.
Thanks everyone for reading, participating in this thread, whether it was writing it the CoC or giving your thoughts.
If you hadn't had a change to speak up now, feel free to contact any of us or open an issue, as well as proposing changes to the CoC structure.
We should likely starts translation and finding members for the CoC committee, plus the thread becomes hard to load even on Desktop.

 It's ok because I know the room, and if I fell in the pit, I know
someone may help me to get out and patch me up. It may feel for some people
like the pit is only made for bad people. But it also scares the heck out of
some other people that will not even dare to take a step.

This is a very fine description of the problem, thank you for taking the time to write it.

Unfortunately a CoC and enforcement as a weapon of dissuasion is extremely efficient.

The sad thing is, I think there is a way of writing this document that would not have that effect, but we didn't get there.  Cultural issues are very hard, and take a lot of patience and understanding.