On 21 Jun 2015, at 19:00, Hynek Schlawack wrote:

...

...

I am sure everyone understands that the Twisted community would love more diversity. While it is hard to achieve, it should be easy to remove one of the obvious blockers -- making underrepresented groups feel more welcome. Thanks for taking this on, Moshe.

+1

...

...

My current draft, including instructions on how to build it, is in https://github.com/moshez/twisted-coc . I have intentionally not made the built documents available, in an attempt to avoid someone picking them up before they're approved by us.

Why isn't this repository either (A) just a simple text file saying "we have adopted the Django CoC" or (B) a very small fork of something else? One of the concerns is licensing; if the text comes via Django, Django credits the "Speak Up!" project, which is CC-BY, apparently from this repository: https://github.com/jnoller/talk-mentorship. Another is... is Twisted really distinct enough to need its own CoC? Just s/Django/Twisted might be good enough? (Since this is not a fork, figuring out if anything else has changed is rather tedious, even after having read both ;)).

I wonder whether it might make sense to just say we adopt https://www.python.org/psf/codeofconduct/ ?

What I would really love is if we could have our own diversity statement like Django has: https://www.djangoproject.com/diversity/

The Django one is more explicit -- it's rather sad that it needs to be, but it does lay out more directly the unacceptable behaviours. That being said, it's not an unchangeable document -- if it doesn't suit the community's needs, we can modify it to suit.

Cheers, —h

_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Some repilies to all the issues mentioned here: 1. I think we should definitely maintain our own copy. Sorry for it not being a fork, the only non-formatting changes I made are things that referrred to the Django-run events (since we don't run events -- I did replace some of this language with mention of the meetup group). As for CC-BY: I did refer to the Django CoC, I thought CC-BY only refers to the "last point of copying". If it makes sense to add Speak Up! to the mention for license compliance, I'm happy to do that. 2. The Django CoC specifically has a change procedure. I did not copy that part over, since our organization is a lot less formal -- I'm pretty sure it's "if the PLC agrees". I think it's a problem that we don't have the names of the people on the PLC on our wiki, but this is a separate issue. [It should be rectified, as well as clarifying the rules for how the PLC acquires/retires members. 3. I considered briefly the PSF one. I think it is *way* under-specified. I want to have something that's clear. I think Django, specifically, has a pretty good track record of promoting diversity and the PSF has a...worse one. 4. A CoC has several purposes, and "banning people" is actually pretty far down the list. The first reason is that we assume most people are good people, or at least wish to follow the rules, and having clear rules about what's not acceptable will hopefully lead to people voluntarily complying. The second reason is to send out a message to underrepresented groups: "we value you, and will protect your right to be treated with dignity in our community". While this does not solve diversity problems by itself, it is an important step. A distant third, in my opinion, is the banning of people -- not least because this issue has not really come up [some people got banned from IRC, I believe, but usually not for the kind of reasons described in the CoC, and I don't remember people getting banned from Trac or the ML]. I really did mean what I said in my first e-mail: we do try to be an open and inclusive place. We are *already* complying with the CoC. [If you subscribe to a Hyackean view of law and legislation, this is law, not legislation.] 5. Not a reply to an e-mail, but I like to publicly call out Hyneck for actually reading through the CoC, noticing a couple of mistakes and sending me a pull-request. It is much appreciated! Thanks everyone who took the time to read and think about this important issue, Moshe Z. On Sun, Jun 21, 2015 at 4:38 AM anatoly techtonik wrote:

On Sun, Jun 21, 2015 at 2:30 PM, Amber "Hawkie" Brown wrote:

...

...

On 21 Jun 2015, at 19:00, Hynek Schlawack wrote:

...

...

I am sure everyone understands that the Twisted community would love

...

...

...

Thanks for taking this on, Moshe.

+1

...

...

My current draft, including instructions on how to build it, is in https://github.com/moshez/twisted-coc . I have intentionally not made the built documents available, in an attempt to avoid someone picking them up before they're approved by us.

Why isn't this repository either (A) just a simple text file saying "we have adopted the Django CoC" or (B) a very small fork of something else? One of the concerns is licensing; if the text comes via Django, Django credits the "Speak Up!" project, which is CC-BY, apparently from

...

...

I wonder whether it might make sense to just say we adopt

https://www.python.org/psf/codeofconduct/ ?

...

What I would really love is if we could have our own diversity

statement like Django has: https://www.djangoproject.com/diversity/

The Django one is more explicit -- it's rather sad that it needs to be, but it does lay out more directly the unacceptable behaviours.

That being said, it's not an unchangeable document -- if it doesn't suit

more diversity. While it is hard to achieve, it should be easy to remove one of the obvious blockers -- making underrepresented groups feel more welcome. this repository: https://github.com/jnoller/talk-mentorship. Another is... is Twisted really distinct enough to need its own CoC? Just s/Django/Twisted might be good enough? (Since this is not a fork, figuring out if anything else has changed is rather tedious, even after having read both ;)). the community's needs, we can modify it to suit.

So that CoCs are just a set of rules to ban users expressed in a vague legal form, so that people can not complain, because they don't understand. Is that right? =)

-- anatoly t.

_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Hi everyone, I'm sorry I haven't responded to the e-mails -- I have had a busy weekend, and my stack was a bit deep for personal projects. I will try to get caught up and see what the right next step is on Monday. Thanks for your understanding, Moshe Z. On Wed, Jun 24, 2015 at 1:27 PM Kevin Turner wrote:

I'm generally +1 on the idea of having a CoC.

I'm content to delegate the details to subcommittee, so maybe I should leave it at that, but I find there's one point I want to reinforce here:

On Sun, Jun 21, 2015, at 08:46 AM, Moshe Zadka wrote:

4. A CoC has several purposes, and "banning people" is actually pretty far down the list. […]

Agreed. Clayton said "They rarely get read until there's a problem," but I think prevention and expectation-setting are things to aim for here. If people only find out about what's acceptable conduct *after* there's a problem, that's too late.

and as an aside,

I think it's a problem that we don't have the names of the people on the PLC on our wiki, but this is a separate issue. [It should be rectified, as well as clarifying the rules for how the PLC acquires/retires members.

Agreed. (I am one of the current PLC members.) _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

What needs to happen to move this proposal forward? -David On Sun, Jul 19, 2015 at 10:28 PM, Kevin Turner wrote:

I was chatting with some people at the Community Leadership Summit today about the Recurse Center's social rules https://www.recurse.com/manual#sec-environment, which reminded me of this thread. What's the status of this proposal?

_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Not that I'm a heavy contributor, but: - A CoC is like a ToS in many ways. They rarely get read until there's a problem. - A CoC is like a License in many ways. They should be pretty standard infrastructure. I think both of these facts argue for joining Twisted to an existing CoC. No one goes around reading the CoC for every group they participate in. We increase the odds that someone reads our CoC if they get leverage (one read, lots of groups) and we get spill-over (they read the CoC for another group and thus know ours). If an extremely common library (think JSON handler) lacks a feature, we don't start by creating yet another fork. We make the case to fix upstream. We only consider forking if we can't get upstream fixed. A CoC is no different. In fact, a CoC is likely even more generic than a JSON library -- I have to wonder what's so special about a CoC that we'd need a fork! If we use the upstream CoC, we also benefit from improvements contributed by others. Clayton On Tue, Jun 23, 2015 at 11:39 AM, John Santos wrote:

Hi everyone,

I am sure everyone understands that the Twisted community would love more diversity. While it is hard to achieve, it should be easy to remove one of the obvious blockers -- making underrepresented groups feel more welcome.

I think, and hope, that our IRC channel, our issue system and mailing list have been a friendly, pleasant place. This is an attempt to clarify what we mean by a "friendly, pleasant place".

After some discussion on IRC, I volunteered to write up a Code of Conduct for Twisted. It is mostly an adaptation of Django's CoC -- I think Django has a nice track record of commitment to diversity, and, of course, we expect our communities to overlap.

My current draft, including instructions on how to build it, is in https://github.com/moshez/twisted-coc . I have intentionally not made the built documents available, in an attempt to avoid someone picking them up before they're approved by us.

Please respond if there are any concerns about the wording, anything that I missed and anything you think does not belong there. I hope we can achieve consensus, and have the Project Leadership Committee approve this (including approving the current committee -- I've volunteered to chair it, and Glyph and Amber (HawkOwl) have graciously agreed to be on it.)

Thanks, Moshe Z.

I've noticed several typos in the Reporting Guidelines section (reporting.rst)

I hope this is the appropriate place to report them.

* first sentence of the 4th paragraph of the "What Happens..." section. The last word is "response", should be "respond"

* Last sentence of the same paragraph: "Finally, the Working Group will make a report on the situation to the DSF board. The board may choose to a public report of the incident." Should be TSF board, not DSF board, and needs a verb in the final clause, probably "make".

Also, more substantively, the first possible response is "Nothing (if we determine no violation occurred)." Maybe I'm just too literal, but I think there should be a positive response to every report, even if that response is "We've decided not to do anything", so the reporter knows the report has been seen and thought about and hasn't just fallen through the cracks.

Another note, someone earlier implied that since Twisted doesn't sponsor events, the event-related parts of the Django CoC were irrelevant. In the past, there have been several local bug-fixing sprints, one of which I almost actually attended. I would think these would qualify as events and the issues for a CoC when people meet in person may be somewhat different from when we meet online.

Otherwise, I strongly support this and am happy the Twisted Project is taking a proactive stance on it. Great work, everyone, and thank you Moshe, Glyph and Amber!

-- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539

_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

On Tue, Jun 23, 2015 at 11:47 AM, Stephen Thorne wrote:

http://bit.ly/psf-coc

I like the PSF code of conduct. It's readable, and covers the bases with an emphasis on civility and respect. -J

On Tue, Jun 23, 2015 at 11:59 AM, David Reid wrote:

I'm going to come out strongly against using the PSF CoC. It is woefully inadequate, it includes no mechanisms for reporting, and as any PSF member who has been on certain mailing lists knows it is actually completely unenforceable.

Enforcing CoCs is hard, and to that end I don't think adding a section to the PSF CoC indicating who will act as arbiter for enforcement and what the stages of remediation available to the arbiters are. -J

Apologies...editing while on a call. On Tue, Jun 23, 2015 at 12:51 PM, Steve Waterbury wrote:

On 06/23/2015 03:31 PM, Jason J. W. Williams wrote:

...

On Tue, Jun 23, 2015 at 11:59 AM, David Reid wrote:

...

I'm going to come out strongly against using the PSF CoC. It is woefully inadequate, it includes no mechanisms for reporting, and as any PSF member who has been on certain mailing lists knows it is actually completely unenforceable.

Enforcing CoCs is hard, and to that end I don't think adding a section to the PSF CoC indicating who will act as arbiter for enforcement and what the stages of remediation available to the arbiters are.

With all due respect ;), that is not a well-formed sentence ... this part of it:

"adding a section to the PSF CoC indicating who will act as arbiter for enforcement and what the stages of remediation available to the arbiters are"

is a noun phrase. So you said "I don't think [noun phrase]." I suspect you want to say "I don't think [noun phrase] would be difficult." ... or something like that.

Steve

_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

I'm not picky which CoC we use, but the fact that upstream requires approval shouldn't disqualify PSF. Part of my argument is that our contributions benefit a larger community. If PSF needs an enforcement clause, they might be more than willing to adopt the change -- and a bigger community would certainly benefit. The goal should be to participate in and contribute to something broad. PSF woudl be great. A little Googling identified some other referenced CoCs (Twitter, Ubuntu, GDC, OSI, Gnome, Mozilla) -- see https://openhatch.org/wiki/Project_codes_of_conduct for these and more examples -- as well as the "Contributor Covenant" that claims ~30 projects as participants and accepts PRs: http://contributor-covenant.org/ It seems likely that at least one of these options provides both a good starting point and an acceptable governance policy. Clayton On Tue, Jun 23, 2015 at 4:49 PM, David Reid wrote:

While it should not in theory be difficult to update the PSF CoC, in practice I expect it would be quite difficult for the simple reason that:

"This document was approved by the membership of the Python Software Foundation during the vote which concluded on 19 April 2013."

Implying that any updates to the CoC would also need to be approved by a vote of the membership.

So while it'd be nice for the PSF CoC to be updated such that it was enforceable I think that should block adoption of a CoC by the Twisted Project.

I'm a +1 on adopting the Django CoC.

-David

On Tue, Jun 23, 2015 at 1:00 PM, Jason J. W. Williams < jasonjwwilliams@gmail.com> wrote:

...

Apologies...editing while on a call.

On Tue, Jun 23, 2015 at 12:51 PM, Steve Waterbury wrote:

...

On 06/23/2015 03:31 PM, Jason J. W. Williams wrote:

...

On Tue, Jun 23, 2015 at 11:59 AM, David Reid wrote:

...

I'm going to come out strongly against using the PSF CoC. It is

woefully

...

...

inadequate, it includes no mechanisms for reporting, and as any PSF member who has been on certain mailing lists knows it is actually completely unenforceable.

Enforcing CoCs is hard, and to that end I don't think adding a section to the PSF CoC indicating who will act as arbiter for enforcement and what the stages of remediation available to the arbiters are.

With all due respect ;), that is not a well-formed sentence ... this part of it:

"adding a section to the PSF CoC indicating who will act as arbiter for enforcement and what the stages of remediation available to the arbiters are"

is a noun phrase. So you said "I don't think [noun phrase]." I suspect you want to say "I don't think [noun phrase] would be difficult." ... or something like that.

Steve

_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

I definitely meant "I don't think that should block adoption". -David On Tue, Jun 23, 2015 at 7:12 PM, Glyph wrote:

On Jun 23, 2015, at 1:49 PM, David Reid wrote:

So while it'd be nice for the PSF CoC to be updated such that it was enforceable I think that should block adoption of a CoC by the Twisted Project.

I hope that you meant

I *don't* think that should block adoption…

unless you meant you thought it should block adoption of the PSF CoC?

In any case, to try to cover some concerns raised so far:

Why the Django CoC rather than the PSF (or, the quite-similar Contributor Covenant)?

There are two reasons: specificity, and reporting.

Specificity is important because of course, everyone wants to be reasonable. The point of having a code of conduct is outlining what "reasonable" means in our specific context. Given the difficulties the software industry has had in the last couple of decades with respecting its marginalized members, it's important to take that context into account and say what (sadly) might not be obvious to people.

Clarity around how reporting violations works is important because people who are already feeling harassed in their day-to-day existence are often not going to be comfortable poking around trying to figure out *how* to deal with a violation of the code on their own. Most likely, they will simply quietly exit the community. So it should be as easy as possible to report.

Why isn't this a fork of an existing CoC?

I agree that this is a problem. Django does not appear to have their CoC in an easily-forkable format. Perhaps we should contact the Django project and ask them to rectify that so that we can make minor tweaks. We also do need minor tweaks, because the information about contact points for reporting has to be different for different projects.

I'd also like to raise two issues of my own. In his original message, Moshe said this:

I think, and hope, that our IRC channel, our issue system and mailing list have been a friendly, pleasant place.

For the most part, I believe this is true, and I think we have managed to be a welcoming and pleasant environment for all concerned. However, I don't want anyone to get a false sense of confidence from this, and think that we're doing great since we've never had any incidents. The nature of such incidents is to remain private. In Twisted's decade-plus of history, especially on IRC, I have had to personally adjudicate several disputes, and we have definitely had potential contributors quietly disappear from the community due to apparent hostility or inappropriate remarks. We have certainly had to ban people from the channel, on at least one occasion permanently. There have not been any particularly severe, particularly public or particularly recent incidents, but there has definitely been some unpleasantness at times. So, while I do believe we are doing well, there is unquestionably room to improve.

Thank you all so *very* much for not making me type that as a *reply* to anyone saying we don't need a CoC ;-).

Also, I would like to stress that I personally believe that this is a 1.0-release type of effort, and in no way a finished product. I have lots of concerns with fairness and transparency in the way disputes are handled, and the list of possible responses, but what we have right now (i.e.: the personal judgement of whatever committer happens to be online at the time) is definitely far worse. So I expect that the work will continue and we will see revisions to this, hopefully in collaboration with other projects so that Twisted developers aren't taking this on, Django being the obvious example.

-glyph

_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Russ has informed me that it's accessible on https://github.com/django/djangoproject.com/blob/master/djangoproject/templa... -- so we could potentially fork the repo and make it just that file or so :) Amber "Hawkie" Brown GPG: https://keybase.io/hawkowl

On 24 Jun 2015, at 12:06, Amber Hawkie Brown wrote:

...

On 24 Jun 2015, at 10:12, Glyph wrote:

...

...

Why isn't this a fork of an existing CoC?

I agree that this is a problem. Django does not appear to have their CoC in an easily-forkable format. Perhaps we should contact the Django project and ask them to rectify that so that we can make minor tweaks. We also do need minor tweaks, because the information about contact points for reporting has to be different for different projects.

As a member of the Django CoC committee, I will pass this suggestion on.

- Amber _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python