Add a code of conduct

[ghost]

We'll need to add a code of conduct when the EFF lawyers will write one.

[ghost]

@Hainish What's your opinion on adding a code of conduct?

[jeremyn]

I'm not @Hainish but I agree with having a code of conduct. The Contributor Covenant looks pretty good and has traction in major projects.

[ghost]

looks

Still, @SwartzCr already contacted the lawyers.

[ghost]

certbot/certbot#4841

[jeremyn]

I wasn't aware of the related discussion in the certbot project. I'm sure the EFF will want to use the same code of conduct across all of their projects.

[Hainish]

This is going through internal process at EFF currently.

[jeremyn]

@Hainish What's the status of this at the EFF?

[Hainish]

Sorry for the delay, this is still caught in internal process. As much as I'd like this today, it is something that we'd like to do right the first time instead of rush through.

[jeremyn]

@Hainish Does this mean that there is a draft version of a code of conduct being actively discussed internally at the EFF?

[Hainish]

I'm not sure, @andresbase might know

[andresbase]

Yes there is, and we hope to publish it soon. We'll update you when we do.

[jeremyn]

@Hainish and @andresbase: great, thanks for the information.

[ghost]

@andresbase Are there legal issues with Contributor Covenant? Can you publish an article on eff.org about these issues?

[jeremyn]

@Hainish , @andresbase Just checking in, what's the status here?

[brainwane]

Hi @jeremyn -- I got to speak with someone who's working on the Code of Conduct effort at EFF and it's still in internal process there. I'm sorry for the wait (and I personally helped introduce a code of conduct in a previous community so I'm also looking forward to the CoC when it's ready). Thanks for checking.

[jeremyn]

@brainwane Is there any way we can have some of the preliminary discussion about the code of conduct here in public? I'm unhappy with the way that the out-of-band ruleset update feature (issue https://github.com/EFForg/https-everywhere/issues/12606) was sort of thrown over the wall at us after significant work had been done. I would like that not to happen here.

I don't understand why a set of community guidelines requires months-long internal debate and legal review. There are a bunch of established codes of conduct out there, why can't the EFF just rubber-stamp one of them? I'm worried, in light of the EFF's vaguely libertarian positioning and some recent articles (one, two) indirectly supporting a racist website, that we're going to end up with some lukewarm, toothless thing. I hope I am proven wrong.

[dannyob]

@jeremyn -- Hi there. I'm the person who you should prod on this. Essentially the challenge is coming up with something that can be consistent across all our projects (and interact well with offline CoCs), will actually (as you say) be effective and enforceable, has a positive legal review, and doesn't clash with EFF's legal responsibilities as an employer of many of the people that the CoC would apply to. I also want some consistency between how event/offline CoC interacts with it. We're not going to cut something out of whole cloth here, but at the same time I don't want to undermine existing CoCs by rewriting them to fit our circumstances and have the world decide that Important Respectable Legal Authorities somehow disapproved of the bits that we had to re-write.

I've also been speaking to a few folks in the community informally to make sure we get it right. One of the challenges of creating such codes— or at least the ones with actual enforcement possibilities (as opposed to vague community guidelines) is that wordsmithing them in public can act to dissuade and discourage many communities from becoming involved subsequently. I'm happy to accept feedback on what you might want from a CoC. Based on what you've said already, I think you'll find the balance of what we're trying to pull together acceptable, even if it takes a bit longer than you'd hope.

[jeremyn]

@dannyob Thanks for your response. I can understand how, if you're trying to fit this project's CoC into CoCs for other EFF projects, as well as offline events/conferences, and the EFF's organizational HR policies, that this might take some time simply from bureaucratic delays.

I can also understand the other point about how public debate can discourage some people from participating. Inviting the internet at large to shout about how some particular group isn't really disadvantaged or there is some conspiracy or whatever, obviously we don't want that.

However there are really only maybe ten to twenty maintainers and high-volume contributors. You could just for example solicit interest in a CoC discussion, collect email addresses, and then maintain a private mailing list. Or even just have a bunch of one-on-one discussions over email. That way you could avoid a public free-for-all.

It's frustrating to be told that we'll only have input after everything is settled, because that's really no input at all, because any changes will have to go through the lawyers and bureaucracy again and I guess that will be very difficult and require a lot of energy from us. (See what's going on in the licensing discussion at https://github.com/EFForg/https-everywhere/pull/13062#issuecomment-340929552.)

The maintainers and frequent contributors will be the ones enforcing the CoC in the project so I think we should have some meaningful input. I don't want to feel obligated to call out behavior I think should be fine, or feel that I can't call out behavior that I should. I can also imagine situations where the CoC is just so inappropriate that I simply can't participate here anymore.

We're an international and often anonymous group so it is unlikely that you have accounted for all of our potential concerns by checking informally with some communities.

There are also some concerns that are idiosyncratic to this project. For example there is an open PR to provide coverage for the domain shemales.lgbt. (https://github.com/EFForg/https-everywhere/pull/12432). As you may know, "shemale" is an offensive term to many trans people (GLAAD reference), however it seems used appropriately in this case because it is part of a domain name and the mandate of the project is "HTTPS everywhere". (Others might disagree with whether this usage is appropriate or not.) However one could imagine a situation where a few people submit a flood of hundreds of issues or PRs for offensive domains, as an obvious attack on certain groups of people but acting within the letter of existing policies. How should that be actionable under our CoC, if at all? I'm not sure. Have you discussed this at all internally?

Another issue is what rulesets should be named. My take is that rulesets should be named after domains as much as possible rather than have complete descriptions, to minimize the amount of language and cultural knowledge needed to review and work with these rulesets. (See https://github.com/EFForg/https-everywhere/pull/12829#issuecomment-338031036.) There's another, related situation about comments in rulesets. (See https://github.com/EFForg/https-everywhere/pull/10486#issuecomment-342315615). Is there anything about this in the CoC?

I'm curious how much emphasis has been given, when writing this CoC, into increasing the diversity of participants in HTTPS Everywhere development. Lack of diversity in the project is something I have complained about before (https://github.com/EFForg/https-everywhere/issues/8900#issuecomment-284281410).

Just to be clear, without seeing a working copy of the CoC, I can't say that these are all of the concerns I have.

[dannyob]

I think maybe the length of time this issue has been up may overstate the extent of the lawyering and crafting going on here. It's a bit tricky, but not overpoweringly so, and I'm both pretty close to the point where we can have something for folks to look at, and I expect we can act a little more expeditiously after that. As I said, we're not crafting this entirely afresh, and my main direction here is to find an existing, resilient and working CoC that people already respect and that fits into the constraints we have. At this point, I have a strong idea of what that would be, but just want to make sure I'm not missing anything. (Running it past your scenarios, most of them aren't issues that would be answered by a CoC — though the CoC would inform how a solution would be discussed within the community, and how it would be dealt with if that conversation started impacting people in our community.)

I'm super-interested in the global aspects of these sort of documents, and that was definitely one of the filters I'm applying to candidate CoCs.

[jeremyn]

I don't expect a CoC to give a specific flowchart for all situations but it should include stuff like what are protected traits and who is empowered to enforce the CoC.

If an actual working document is almost here, then I can wait until then to discuss this further.

[jeremyn]

Another situation a code of conduct should address is this: it's possible to make guesses about personal details for a contributor/maintainer, who is otherwise anonymous, based on their issues/PRs/occasional comments. For example if someone makes a lot of PRs about birdwatching, you might guess they are a birdwatcher.

So, we should have a rule that says that other contributors/maintainers cannot make statements about these guesses, either directly ("Are you a birdwatcher?") or indirectly ("Hey @[contributor/maintainer], what do you think about this birdwatching PR?"). The reasoning is that, one, these statements or inferences might be awkward or embarrassing or even a form of harassment, and two, they work to de-anonymize the contributor/maintainer which is obviously bad.

An edge case is where a contributor/maintainer is willing to be called in to help based on their membership in some specific group. The main example I can think of is people who are willing to help test rulesets for domains that behave differently in certain geographic regions, such as inside/outside the "Great Firewall of China". In this case, these contributors/maintainers should be encouraged to identify this membership in their GitHub profile section, for example set "https://github.com/settings/profile > Location" to "China", and conversely other contributors/maintainers should not refer to personal attributes of these contributors/maintainers unless these attributes are clear from their profile.

(Of course profile information can be abused as well -- for example imagine a contributor with a photo that identifies them as an "X" being pinged on every PR for a domain vaguely about "X" -- but we can probably handle that on a case-by-case basis.)

As the code of conduct should be a high-level document, we don't want to be too elaborate about these scenarios. We could add a bullet item somewhere saying "Respect the anonymity of contributors and maintainers" or similar text, and the rest flows naturally from that.

[jeremyn]

What's the current status of this issue at the EFF?

[dannyob]

On Fri, Jan 05, 2018 at 03:31:31PM +0000, Jeremy Nation wrote:

What's the current status of this issue at the EFF?

Still processing, but should have some news by the end of the month.

[ghost]

Any progress?

[dannyob]

Not as much as I'd hoped — basically, I've got the okay for more resources to work with this within EFF, so we should actually have a deadline, rather than me steering this in between other work. What I was /hoping/ to have was the actual resources to spell out that a schedule, but it looks like I'm going to get that now (ie February).

At the risk of burning my very last free "please wait for more info" coupon on this tracker, I'll sit down and work out a rough schedule for Feb and let you all know next week.

(Incidentally, thanks for everyone who has sent me suggestions by mail on this — it's been really useful and should be incorporated in the final result)

[Hainish]

Thanks @dannyob!

[jeremyn]

Hi @dannyob , what's the status here?

[dannyob]

Hey! Okay, so it isn't next week, and it isn't February, but I do have an update and the outline of a timetable. We're now hoping to synchronize our online and event codes of conduct, which means that we;d want to roll it out by April 26 -- that's very much the last possible moment, and I've now got everything I need, so I'm assuming end of March.

For those of you that want a little more to chew on, it's probably going to lightly derived from the Rust and Rustconf codes of conduct: we're loathe to create Yet Another CoC, and these are pretty established and tested.

[ghost]

@dannyob Are the lawyers involved? Also, maybe we should avoid using a code of conduct based on Contributors Covenant to avoid the same issues it has?

[jeremyn]

@dannyob It's not clear to me from your comment, but is there going to be a window where we can give feedback and hope to have that feedback taken into account? For example if you release a draft CoC for comments at the end of March, and someone has serious concerns, will you realistically be able to modify the draft CoC based on those concerns before April 26th?

[dannyob]

@epicminecrafting oh so many lawyers @jeremyn yep there will, though I anticipate that will center more around comments and instructions about how best to put the code into practice. If it all becomes greatly hectic, I'll just let that process take as much time as it takes, and concentrate on finishing a separate event process instead.

I mentioned the Aprl date to reassure the very patient watchers of this issue that I do have some kind of internal deadline now. I also anticipate things moving a lot more quickly, but you may have heard that from me before...

[dannyob]

(Status update: currently with lawyers, really still looking like Rust's CoC, so take a look at that if you'd like to get ahead of the curve)

[jeremyn]

@dannyob What is the current status of having a Code of Conduct, please?

[Bisaloo]

Echoing @jeremyn's question: is this still on the roadmap? Could we get an update please?

[dannyob]

Update! We've got a small bit of wording to craft, and should have something more to offer in a couple of weeks. Thank you for your fantastically high levels of patience and tolerance.

[dannyob]

Okay folks, here's our the preliminary text of the code, as filtered through many internal discussions, wrangling, and probably not quite enough proof-reading.

I'm putting this here so that all of you who have been following this issue for so long can have a chance to see and comment on a preview. As I said, oh so many comments ago, it is at heart same as the Rust CoC. I'm happy to answer questions, but because this has taken so long, and because there were sometimes fairly intricate and context-dependent reasons for any alterations we made, please be tolerant of me if I have to dive back into my notes or am imperfect in explaining fully those intricacies the first time around.

I think one thing I'll note off the bat is that despite being filtered through lawyers, this is not a very legalistic document. This is deliberate: EFF, more than most I hope, understands the limits and challenges to spelling out every possible "if" and "but" for good or bad conduct in a single document; and how much how communities are built on understanding and acting on the spirit of the unwritten rules that bind us, not by consulting an external definitive text.

Also: if you're hoping to run this code through an emulator, and then throw at it some edge cases ("What happens if I post an insult so long that it buffer overwrites this code of conduct's stack and personally attacks someone in the next github repo but one?"), you're probably better off thinking "what is the common sense answer to this question?", and assume we'll do that. It's really about giving people a feel for what's okay and what's not, not being a perfect guide to edge-cases. That's what humans (or human-level AIs) are for.

preamble code reporting guidelines

[Bisaloo]

Thank you for the update @dannyob!

A very technical (and very minor) issue: URLs in markdown should be enclosed in <url> (source). So I would write:

• L6: **Contact**: *<email@eff>*
• L49: <https://www.bolderadvocacy.org/wp-content/uploads/2018/06/Election_Checklist_for_501c3_Public_Charities.pdf>
• L107: *<email@eff>*
• L115: <https://github.com/EFForg>

(I've redacted the email address just in case)

My text editor gets confused by backslash escaped characters in the current version.

[dannyob]

Thanks @bisaloo -- the markdown was autogenerated by Pandoc, whose defaults seems to be pretty enthusiastic when it comes to escaping characters. I'll make sure the final version is a bit more readable.

[Bisaloo]

@dannyob, maybe you're already planning to do this but I think it would be good to have some information about the Code of Conduct team. In particular, I think it would be important for users to know that the person they might be reporting is not in the Code of Conduct team. Or at least, it would provide them with a way to contact someone else from the team (if email addresses of the individual team members are provided).

If you already planned to do this, good job! If not, I definitely think it would be a worthwhile addition.

[pipboy96]

@dannyob Can you publish this draft in a GitHub repo so it can be publicly discussed for some time before being enforced for all EFF projects?

[dannyob]

@bisaloo yep, that's the plan. We'll put this info on the contact web page.

@pipboy96 hey! so as you can probably guess from the dates on this issue, we've had this in draft form for quite a while now, and it's not something that's really amenable to the line-by-line patching of a github repo. We're more at the stage of putting it out to explain why some things are worded the way they are, rather than re-writing and then sucking it back into EFF vortex for more endless process.

[pipboy96]

🎉