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)
 * Sure, but it would be great if we could develop policies based on case studies of where things have failed before (Especially case studies of where we have failed) as opposed to more generic bad things can happen. Bawolff (talk) 21:46, 8 August 2015 (UTC)
 * Why? Why wait for something bad to happen to call it out instead of saying "these kinds of things are bad, don't do them here". Greg (WMF) (talk) 01:02, 9 August 2015 (UTC)
 * We already have that. See DICK. -— Isarra ༆ 02:36, 9 August 2015 (UTC)
 * this is a pretty succinct response to why "don't be a jerk" isn't enough to create a friendly atmosphere - the fact that the guidance you're linking to (which is just that; guidance. It isn't even enforceable) opens with a big picture of Wikipetan is...well, it somewhat undermines the point here. Ironholds (talk) 17:11, 9 August 2015 (UTC)
 * I'm not sure we even have the capacity to thoroughly identify where things have failed (discouraging contributors is usually not a very obvious phenomenon, because the persons getting discouraged leave, and no one is left to talk about it), so it's probably easier to build on the work of other communities which did that kind of investigation and came up with guidelines. It seems unlikely that the MediaWiki developer community would be so fundamentally different from the Ubuntu or Gnome or Python community that we somehow need completely different rules.
 * That said, I can share a case study, although I don't think it's the worst or most important type of harassment. During the second half of 2014, I have been triaging feedback on mw:Extension talk:Media Viewer/About, which some people have decided to use as a channel for venting over their dislike of deployment governance. You can get a picture of it just by skimming the page, although some of the meanest comments have been reverted.
 * I have eleven years of experience with the Wikimedia movement, much of it in some community leadership role; I have been advocate for a few fairly controversial initiatives. I generally consider myself to have thick skin. Even so, the experience was quite alienating. It did significantly influence my opinion of the Wikimedia community in the negative direction (even though most of the comments are anonymous, and anyway treating a handful of self-selected commenters as representative of a large community is totally unjustified, but that's just how human brains work), and it took me a while to recover from that. I'm fairly sure that if this would have been someone's first and defining large-scale interaction with editors, they would have quickly come to the conclusion that the community is a problem that needs to be fixed, not a partner to work with. I also wonder how encouraging the tone of that page was for someone who actually went there with the intent to report a bug or have a reasonable discussion. From what I have seen (from a distance), the feedback pages of other large-scale initiatives do not fare much better. --Tgr (WMF) (talk) 05:51, 10 August 2015 (UTC)

I guess, the biggest question I have along the why is it needed lines, is why (concretely) is the friendly space policy not enough, and what is the intended relationship between this policy and that one. Bawolff (talk) 21:48, 8 August 2015 (UTC)
 * This. -— Isarra ༆ 02:28, 9 August 2015 (UTC)
 * Not an author, just a random supporter of the ideas behind this policy, but; my feeling would be that the friendly spaces policy is very deliberately highly general, because it's designed to be cross-applicable to a lot of spaces, and is centred on "real-world" spaces. It does its job very well! BUt one of the costs of this is that it is not tremendously detailed; it does not set out (except in broad strokes) what is problematic, and it does not factor in tech-specific forms of microaggression or macroaggression. Another is that it does not provide any enforcement mechanisms for these kinds of online spaces. By having a code of conduct for technical spaces, both are addressed; we can be pretty specific in what we call out that isn't applicable to other spaces, and have an enforcement mechanism that is centred on technical spaces. Ironholds (talk) 17:11, 9 August 2015 (UTC)
 * Bawolff, if by friendly spaces policy you are referring to Friendly space policy, I don't really understand your question. That policy is quite clearly about acceptable behavior at IRL events, focuses on face-to-face interaction, and its enforcement relies on the organizational structure that such events have (but most online spaces don't).
 * Are you saying you don't see the need for having a policy on behavior in online spaces? Or are you saying that the friendly space policy is or could be usable in online spaces? How? --Tgr (WMF) (talk) 04:48, 10 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)


 * I do like it. --Brion Vibber (WMF) (talk) 23:35, 9 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)

Agree. This policy guarantees WMF control of volunteer discussion spaces (including spaces that are not operated by the WMF). This gives arbitrary control and is a potential censorship tool for employees or contractors to the WMF. There is no protection for a volunteer who might have fair cause to be raising critical or "non-positive" issues in a "technical space", there is no protection for whistle-blowers, there is no appropriate system of appeal, natural justice or governance for arbitrary actions taken under this code of conduct which may well be taken for debatable reasons of tone, misjudged jokes or confusion about who happens to be an employee using a non-employee account and is being mistaken for an unpaid volunteer (which happens all the time).

My reading of this policy is that it makes it possible for a WMF employee to choose to ban me forever from all the projects I am committed to as an unpaid volunteer, overruling community created project policies, for unknown reasons that may not even be provided to me so that I can correct any error, challenge them as a Joe Job attack, or ask for fair independent review. That makes it completely set against our values of putting the volunteer at the center of our projects. The idea that all Wikimedians should start officially reporting anyone "not being productive" I honestly find scary.

There is a need to do more about real harassment, this CoC confuses arbitrary allegations of "disruption" or being "non-positive" with harassment, and seems to make no attempt to ensure volunteers can appeal to elected volunteer peers for fair assessment of complex allegations of being thought by some to be disruptive, but not a criminal case that should be taken to the police if there is evidence to present, rather than unprovable allegations. --Fæ (talk) 19:33, 8 August 2015 (UTC)
 * My reading of this policy is that it makes it possible for a WMF employee to choose to ban me forever from all the projects I am committed to as an unpaid volunteer - If we're talking about you personally, I'm not sure I see what you mean. Most of your activity is on commons, which unless I misunderstand severely, is quite out of scope of this policy. Maybe this policy applies to tool labs (Does it? Its not entirely clear on that point), which would probably affect you more significantly. It would apply to in-person events, but people could already be banned without much appeal from such events anyways, so this is not much new on that front. (On the more general point though, I agree, fairness in enforcement is an important issue that is being hand-waved). Bawolff (talk) 21:31, 8 August 2015 (UTC)
 * And I just re-read the policy. Since my last reading the line "The Community Advocacy team also has the authority to investigate behavioral issues and recommend WMF global bans for individuals." has been added. So I guess I see where your coming from more. Bawolff (talk) 21:33, 8 August 2015 (UTC)
 * You may need to read the policy again. The CA team has always had that power - this policy does nothing about that. What it does is set out behavioural guidelines for technical spaces. Your objection to the policy around it chilling volunteers ignores an important line from the actual policy; "a healthy amount of constructive criticism and vibrant debate helps to improve our software and is encouraged". This is nothing to do with critiquing software changes in the sense of the community giving feedback on new extensions or features; this is to do with how people behave on phabricator, on gerrit, on wikitech-l, and making sure we have a welcoming community. I agree, for what it's worth, that "not being productive" is a bit vague, and probably needs fixing up. Ironholds (talk) 17:15, 9 August 2015 (UTC)

Other examples from industry
There's a nice code of conduct from the Electron project here that has a prominent link in the project's readme. Niedzielski (talk) 04:24, 9 August 2015 (UTC)

Safe spaces, incivility, and passive aggression
It seems that there's general agreement that a lot of outright "in your face" harassment on gender/sexuality/racial/religious/etc grounds is to be avoided -- which makes me happy to hear -- but it doesn't surprise me that there are more negative reactions over the idea of disruption being a problem than .... any other reaction at all.

This doesn't surprise me because passive-agressive dismissive incivility is absolutely rampant in our community [our community == everyone involved in Wiki*edia, yes if you are reading this it includes you], as well as many other FOSS and FOSS-like projects. I know I'm a part of that civility problem too, and try to avoid it but don't always succeed.

I really like the idea of a positive code of conduct that prescribes respect, civility, and a mindfulness that we're working on tools for people to use... Being actually productive is important, and with our communications channels it's easy to get sidetracked into bikeshedding, "well-actually"ing, "RTFM"ing, and accusations of who's the most disruptive.

The most radical act isn't pointing out others' failings, it's admitting that you're part of the problem, and that changing is required. I know I need to change for the better, and I hope you all will join on that journey. --Brion Vibber (WMF) (talk) 23:48, 9 August 2015 (UTC)

Unnecessary section
The part about the Community Advocacy team and global bans should just be removed (or alternatively replaced with language like "the Global Ban Policy also applies to technical spaces"), to avoid any potential confusion that the code of conduct makes a different set of standards for global bans than what is in the policy. The language of the particular section is also pretty unfortunate and reads like "the CA team will be policing technical spaces and getting anyone who violates the above globally banned", IMO. wctaiwan (talk) 03:34, 10 August 2015 (UTC)

Role of the document
I feel like this code of conduct is trying to be a set of guidelines for best social practices (no off-topic comments, discuss things in the open) and a set of binding rules (no harassment) simultaneously, with no clear delineation. This should be addressed either by structuring things differently and making it clear which things would lead to consequences, or just splitting it into a binding policy and a non-binding set of guidelines. The binding parts would also need to be concrete (in defining unacceptable behaviour) to be enforceable.

In what's been defined so far, I think the part about rejecting patches should just be removed—given the precedent of some developers being very determined to push through features against consensus, people really shouldn't be punished for rejecting patches, provided they do so without personal attacks and such. (Also, please don't use words like "catalytic".) wctaiwan (talk) 04:03, 10 August 2015 (UTC)

"including but not limited to"
As "technical spaces" could be almost anything, for example bug requests are discussed on email lists, main noticeboards on Wikipedia and Commons, etc. this is a potential bear trap. The list needs to be specific, and the communities it encompasses need to unambiguously agree with it and have the opportunity to discuss it and amend it. --Fæ (talk) 05:02, 10 August 2015 (UTC)

IRC
IRC is not operated by Wikimedia and has independent and long established harassment policies. If the IRC harassment policy is to be effectively superseded by this Code, then it needs to be presented to the IRC community and the channels that it applies to need to be spelled out. As it stands it is not clear if this applies to all IRC private messaging, if it only applies to an agreed set of "technical" IRC channels (which should then have this Code linked in the channel notices), or whether it applies to all self-identified Wikimedians whenever they are using an IRC channel. The text currently reads in a way that denies the possibility of anonymity on IRC, which appears to run counter to Freenode's IRC policies. --Fæ (talk) 05:02, 10 August 2015 (UTC)