Talk:Code of Conduct/Archive 4

Maybe disruption of work should be a little more defined. Taking things very literally, people (legitimately) -1'ing my patches disrupts my work, but that's obviously not the type of disruption meant here. Bawolff (talk) 00:34, 7 August 2015 (UTC)
 * I based that on "sustained disruption of talks or other events" at Friendly space policy; I've rephrased to make it more clear (and a little more narrow for now). Mattflaschen-WMF (talk) 03:15, 7 August 2015 (UTC)

Inappropriate
Again, as the WMF Harassing Policy for physical spaces, this implicitly reverses the burden of proof for non-listed harassment and creates first and second class victims. I don't want to support any such discrimination, much less assume any liability for the results, so if this or a similar policy is enacted, it should point out who is responsible for it and that conforming to it does not condone behaviour complying with this policy. --Tim&#160;Landscheidt 01:17, 7 August 2015 (UTC)
 * Where do you draw the conclusion that this creates two classes of victims? It's quite clear that the list is not exclusive; whether or not it's listed, if it's harassment, it's forbidden.  I think not listing an examples of harassment and simply saying "Do not harass contributors or users." is far too vague.  I'm very open to suggestions of concrete things that are missing from the list, though.  The document already notes the Community Advocacy team's existing role in this area, and the final document will have more clarity as to who to contact.


 * You cite a pre-existing policy (I think you're referring to Friendly space policy, which this is partly based on). That has a similar phrase, "Harassment includes but is not limited to".  Do you recall any harassment that occurred but could not be dealt with due to not explicitly being listed? Mattflaschen-WMF (talk) 03:15, 7 August 2015 (UTC)

This needs some more thought
I very much like this policy but:


 * 1) I feel like it could afford to be a lot more explicit. One source of influence (which also draws a lot from the Ada and CoC elements) is the jQuery Coc (COI: I've provided some comments to it). It's very clear about the things that are not okay, and more importantly it's very clear about the processes around the escalation paths, which this isn't.
 * 2) Community Advocacy is absolutely the wrong entity to be handling requests here; they are awesome but do not trend towards a technical background. Why aren't the Engineering Community team handling this? This is quite literally their job - building a healthy community.
 * 3) Who drafted this and does that group include members of groups traditionally marginalised within technical environments? If not, why not? Asking people to comment publicly is all well and good but it ignores how toxic these venues can get. We could lose a lot of incredibly useful submissions based around lived experiences by not including those groups early in the drafting process. Ironholds (talk) 16:55, 7 August 2015 (UTC)


 * I particularly agree with points 1 and 2. One of the things I like about the Contributor Covenant's version (which I think we should fork and modify for this; writing an effective CoC is hard, and we should take advantage of existing work!) is the specificity: methods of contribution, spaces the policy applies to (particularly "in public spaces when an individual is representing the project or its community"), unacceptable behavior, means of reporting, and consequences for violations.


 * I think that CA is a great resource to escalate to for really bad violations (think assaults at conferences, doxxing, etc.), but I think that we need people who are familiar with technical workflows and the normal structure of technical discussion to take point on this. Harassment thrives on plausible deniability, and someone who's not familiar with the normal operation of the space in question won't be as effective at identifying it and handling it effectively. Fhocutt (WMF) (talk) 19:31, 7 August 2015 (UTC)


 * This is still a draft, and I encourage people to keep editing it, including using other CoC's as inspiration (or maybe rebasing it; see below), and including being explicit about what is not permitted. I'm in communication with both the Community Advocacy and Engineering Community teams, and the exact roles (if any) for each are still being worked out.  The document does not currently say that CA will be the go-to contact person for this (hence the ?); it just states their pre-existing authority, partly so it won't be misinterpreted as taking that away.


 * I'll let the drafters speak for themselves if they choose (partly because I don't want to imply this is their ideal draft). The drafters included at least one participant from a traditionally marginalized group, but more input to the draft (from everyone) is needed.  I'm not just asking for comments, but actual edits to the draft. Mattflaschen-WMF (talk) 04:29, 8 August 2015 (UTC)

Two questions

 * 1) Why is this needed? (What generally comes up now as problems, how do existing channels fail, and how will this resolve that?)
 * 2) Whose consensus will it come down to in order to actually approve, enforce, and modify this?

Thanks. -— Isarra ༆ 18:09, 7 August 2015 (UTC)
 * I'm very curious about the answers to these two questions as well. --MZMcBride (talk) 19:53, 7 August 2015 (UTC)
 * Re Question 1: This is a pretty good writeup: https://adainitiative.org/what-we-do/conference-policies/ Greg (WMF) (talk) 00:38, 8 August 2015 (UTC)
 * This is needed because harassment is a common problem in technical communities, and unfortunately, we are not uniformly an exception to that. Saying existing channels "failed" completely is overstating it, but they have not performed as well as they would have with a clear, binding policy.  This will provide a clear and explicit (albeit not 100% complete) list of forbidden behavior, and make clear how it is dealt with (understanding this may be a multi-step process in some cases).  We are still determining how this will become binding policy and who will participate in enforcing it. Mattflaschen-WMF (talk) 04:43, 8 August 2015 (UTC)

Rewrite based on Contributor Covenant?
suggested above to use Contributor Covenant's Code of Conduct as a starting point instead. I'm willing to do that. What do people think? Let's make this decision quickly (a week?), so we know what we're basing the draft on. Mattflaschen-WMF (talk) 04:30, 8 August 2015 (UTC)

recomendations
Change :Be catalytic – Tell what they should do instead. Occasionally this may be encouraging and motivating, better than a dense list of "rules". to: Be catalytic – Recommend what they could do instead. Occasionally this may be encouraging and motivating, better than a dense list of "rules" Jadeslair (talk) 07:15, 8 August 2015 (UTC)

Creeping bureaucracy
Stop it, just stop it. Everyone has been complaining for years of the ever-expanding bureaucracy and mass of rules in Wikipedia(s), which frighten new contributors. Yet new policies and side-processes keep being proposed everywhere, as in this example. I don't see any benefit in this document and I hope the proposal will be withdrawn as soon as possible to save us the burden of discussing it. --Nemo 16:17, 8 August 2015 (UTC)