Talk:Code of Conduct/Archive 1

Add discussion
Active discussions

Disruption of work

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)

@Bawolff: I based that on "sustained disruption of talks or other events" at wmf: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)

Added a heading. --MZMcBride (talk) 23:27, 10 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 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 wmf: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 meta: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)
'Don't be a dick' pretty thoroughly addresses the examples given. -— Isarra 18:42, 10 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)
But that's not development, that's other projects' responses to development. How would this help with that? -— Isarra 18:42, 10 August 2015 (UTC)y
At the very least it means don't come over here to development feedback pages and behave horribly towards others because to do so on your local project would likely get you into trouble there. As mentioned several times, there is no civility policy here which allows for enfettered nastiness and rage, often drowning out the important ideas and criticism related to the product itself rather than the ephemeral debates. This is extraordinarily unhealthy to the development process. I hope you can see how it helps in that context. Keegan (WMF) (talk) 18:27, 11 August 2015 (UTC)
Completely agree with Tgr's comments, particularly using the Media Viewer feedback page as an example of how such an uncivil environment is detrimental to software development as well as the humans behind it. Keegan (WMF) (talk) 18:27, 11 August 2015 (UTC)
"Sure, but it would be great if we could develop policies based on case studies of where things have failed before". I'm not going to call out specific people for specific incidents here in public, but if you want proof such incidents have occurred, feel free to email me privately. However, I'm sure there are incidents I don't know about as well. Isarra: meta:DICK is not binding; it's not even a guideline, just an essay. Mattflaschen-WMF (talk) 05:28, 11 August 2015 (UTC)
Normal practice is indeed to discuss such things in public. This is a public project. Why change this now when it's most important? -— Isarra 01:29, 12 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 wmf: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)
For my own part, you're right - I really don't see the need here. My experience with mw and wikimedia development as a whole has been such that these areas have overall come across as far more civil than most 'content' projects I've interacted with, and yet the latter tended to have policies out the wazoo. If anything these policies seemed to be giving some users more leeway for being giant asswads.
But maybe there is something here, and if so, it should be clearly documented so it can be properly addressed - because then maybe it would actually work, unlike the ones on other projects. -— Isarra 18:42, 10 August 2015 (UTC)
I think the main problem with the content policies is that (they/some of them) have such policies, but don't actually enforce them (there are probably aspects that those policies are missing too, but enforcement is the biggest issue). This draft policy tries to be specific about enforcement. Mattflaschen-WMF (talk) 05:32, 11 August 2015 (UTC)
Content projects tend to rely either on enforcement by consensus or enforcement by a large group of people none of whom are really responsible for it. Those methods work well for enforcing rules against unpopular violators; they don't work very well on popular ones. Verbal aggression from friends and vested contributors is regularly overlooked. --Tgr (WMF) (talk) 06:32, 11 August 2015 (UTC)
In the case of technical spaces, the 'vested contributors' are often WMF staff. -— Isarra 01:29, 12 August 2015 (UTC)
The main reason wmf:Friendly space policy (FSP) is not enough is that it not apply online at all. FSP is purely for in-person events ("Wikimedia Foundation events" to use its terminology). The relationship is that, for in-person technical events, you would have to comply with both of them. Mattflaschen-WMF (talk) 05:32, 11 August 2015 (UTC)
Maybe this policy should focus on online issues, and FSP should focus on in-person issues. E.g. Stuff about unwanted photographs (An in-person issue) would be in the FSP, and this policy would be about things that commonly come up online. With the understanding that if you're at a tech event, both policies apply. Bawolff (talk) 09:40, 12 August 2015 (UTC)

Recommendations

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)

  Done Thanks for the suggestion. Mattflaschen-WMF (talk) 04:57, 11 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)

The meta:WMF Global Ban Policy only includes extreme situations, and the WMF refuse to talk about those situations.
That will be appropriate for some 'Code of conduct' issues, however it seems like the 'reasons people will be banned' aspect of this CoC policy is intentionally more inclusive of incivility and bad behaviour than the Global Ban Policy, however the CoC is limited to parts of 'Wikimedia' that are 'paid work' spaces for people, esp. WMF staff.
I do worry that this CoC will mean 'the editing community' feels 'mediawiki.org' and other technical spaces has a more pro-WMF banning policy than meta or content wikis, and therefore withdraw from participating in these spaces. John Vandenberg (talk) 06:36, 10 August 2015 (UTC)
I hope that it's the opposite, and people see that codes of conduct are not something to be afraid of, but just reinforcement of good practices. Mattflaschen-WMF (talk) 05:59, 11 August 2015 (UTC)
I have no issue with that wording. I'll put it up and we'll see how it goes. Mattflaschen-WMF (talk) 05:59, 11 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. -- (talk) 05:02, 10 August 2015 (UTC)

We could consider removing "including but not limited to" from the 'virtual' section. Mattflaschen-WMF (talk) 06:31, 11 August 2015 (UTC)
On the presumption that unpaid volunteers are allowed to amend this draft in advance of whatever official WMF authorization you have in mind, I have been bold and made the change (diff). -- (talk) 14:50, 11 August 2015 (UTC)
I've asked people to help edit and work on the draft repeatedly, so it's not really a presumption. While I'm okay with removing it from 'virtual' (we could add any missing spaces we notice), removing it from the 'examples of harassment' is much more problematic. It's easy for someone to claim their abusive behavior is technically not listed. Common sense as to what constitutes harassment is still sometimes necessary. This is a necessary list, but not a complete one. I also think it should be next to 'physical'; however, there are possible alternatives there. I also think "Wikimedia-controlled" is overly narrow (#wikimedia-dev is definitely a Wikimedia technical space, but is it Wikimedia-controlled despite being hosted by Freenode servers?). Mattflaschen-WMF (talk) 02:56, 12 August 2015 (UTC)
By definition, #wikimedia-dev will become Wikimedia controlled if this policy is made part of its channel notice, as will any other channel that opts in per the IRC discussion below. In this way there is no need to include an open-ended wording in this policy that may be read as all channels where wikip/media is in the channel name (as any of them might discuss technical matters and have technical staff participating), as we can state it in a more specific way which avoids that reading. -- (talk) 07:40, 12 August 2015 (UTC)

"Unwanted photography"

Clearly this needs clarification. In the U.S., for example, it is entirely legal to photograph any person in a public place at any time. My main work here is for the Commons. I don't normally ask in advance before taking photos in public, nor do most U.S. contributors to Commons. Are we, or are we not, saying that if that person is a participant in a WMF project that they may now have a veto on having their photo taken and posted here? If, for example, that person is giving a speech, do they now (unlike anyone else) have a right to say that someone cannot photograph them during that speech? What if they were one of the many people bicycling naked in the Fremont Solstice Parade and decided they didn't like a photo someone took of them? Would they then have special recourse unlike anyone else in the parade? I don't think that's what we mean to say, but perhaps it is. If so I strenuously object; if not, there needs to be some clarification as to what is meant by "unwanted photography." - Jmabel (talk) 14:27, 11 August 2015 (UTC)

Certainly clarification is needed as the policy is open ended and non-specific at the moment.
Keep in mind that conferences are not necessarily public places and physical meetings might be in many countries, so there are several ways of interpreting personality rights and the nature of intrusion or reasonable expectations for privacy even when photographs are taken in a public place (I'm thinking of UK law here, rather than US law). This is where the policy would be much better split so that hard and enforced policy elements are clearly distinguished from best practice guidelines for participants. I doubt that anyone intends to create a policy which removes a citizen's right to free speech or the rights of journalists or "citizen journalists" to report events by threatening anyone that breaks it with punitive, publicly humiliating and permanent global bans. -- (talk) 15:00, 11 August 2015 (UTC)
Jmabel -- actually, Commons has been generally receptive on several occasions to requests for deletion of such photographs (don't remember any from Fremont Solstice Parade, but do remember one from Burning Man) as a matter of "courtesy deletion" (though the photographed person doesn't have a strict right to demand deletion). AnonMoos (talk) 16:05, 11 August 2015 (UTC)
The code of conduct says "unwanted photography", it doesn't say "photography without permission". It also doesn't say anything about publishing photographs (or a "special recourse")—thus personality rights are irrelevant to the discussion, as is Commons, as is the example about the Fremont Solstice Parade. As to your example of someone giving a speech, I think it is totally reasonable for someone to request that they not be photographed while giving a speech. For example, what if they are a Chinese citizen and speaking out against the Chinese government? In such a situation, repeatedly ignoring their request would be rightfully considered harassment, IMO. Kaldari (talk) 21:24, 11 August 2015 (UTC)
Jmabel requested clarification. If someone asks for photographs to avoided for a talk, we respect their wishes as a courtesy; this already happens. However making threats of global bans will not stop "unwanted" photographs of a notable person being taken by journalists or anonymous tweeters if a conference is in a public place, or has public access. Neither should anyone in fear for their safety be given an impression that a code of conduct for technical spaces makes it acceptable to take more risk. Were I organizing a conference I would consider it unethical to have the event used in a way that creates serious unnecessary risk of harm, such as future imprisonment by their government, for any attendee. -- (talk) 01:09, 12 August 2015 (UTC)
First, we need to distinguish between community policy and government law. There is no law in the U.S. against written personal attacks (unless they are libel), but the English Wikipedia still has a Wikipedia:No personal attacks policy. The primary goal of provisions like the unwanted photography one is to ensure people don't completely ignore the photography subject's intentions. If you just didn't know about their preference, I don't think that would be considered a violation. As far as WMF major public figures, I don't know any of them that have such a preference. If they did, and people felt that it interfered with e.g. documenting major speeches at WMF technical events, the right remedy would be to ask them to reconsider their preference.
I'm not sure how an unrelated public bicycle parade could possibly be considered a Wikimedia technical space. It's not based on who the person is; it's based on the space. So if you see Brion Vibber at some unrelated conference, you should follow their policy, not this one. And if you see him at the grocery store, it's between you and him (of course, being respectful is always good). Mattflaschen-WMF (talk) 02:08, 12 August 2015 (UTC)
So the issue is "unwanted photography" in the technical space, not "unwanted photography" of someone you might have interacted with in such a space? Because that is certainly not clear here. Also, "unwanted" is still hopelessly vague, especially if the sanction is a global ban. If it means "taking photographs of someone who has clearly and explicitly said not to take them" it should say so. If it means a photographer can get in trouble because someone decides the expression on their face doesn't flatter them, that is a very different thing. And, no, that's not just a hypothetical: things like that are by far the main reason for requests for courtesy deletions. I'm all for courtesy deletions, but not for sanctions against a photographer for taking (nowhere here does it even say publishing) pictures. - Jmabel (talk) 07:56, 12 August 2015 (UTC)
I think unwanted photography should be defined as taking photographs where the subject has either asked that their picture not be taken, or has a sticker saying no photos (Or I guess if the photographer is doing something creepy like specifically trying to sneak photos of someone). Bawolff (talk) 10:10, 12 August 2015 (UTC)
I've rephrased this line. 'Clearly inappropriate' is intended to mean basically what Bawolff described as creepy. Mattflaschen-WMF (talk) 20:31, 12 August 2015 (UTC)
The document says "follow this policy in Wikimedia's technical spaces", not "follow this policy anywhere you see a MediaWiki software engineer or bug-reporter". Mattflaschen-WMF (talk) 20:31, 12 August 2015 (UTC)

Encouraging others to behave badly

I was wondering if it would be worth adding the following bullet point under the "Do not harass contributors or users" section:

  • Encouraging others to do any of the above.

Personally, I think that encouraging harassing behavior is also a form of harassment. Thoughts? Kaldari (talk) 23:45, 11 August 2015 (UTC)

Is encouraging someone to do X the same as doing X? If so, I've won a bunch of professional sports games... Yaron Koren (talk) 00:14, 12 August 2015 (UTC)
No, encouraging someone to do X is rarely the same as doing X. But occasionally it is. For example, encouraging someone to commit a crime is often committing a crime. Kaldari (talk) 00:32, 12 August 2015 (UTC)
What is and is not regarded as a crime in various jurisdictions is not a meaningful metric, as completely ridiculous things find their way into legal codes all the time. As for the matter at hand, encouraging people to harass others is not inherently harassment. Don't call it what it isn't, just call it what it is - something that is also problematic, and should not be done. -— Isarra 01:19, 12 August 2015 (UTC)
What's a specific example of this? --MZMcBride (talk) 02:30, 12 August 2015 (UTC)
I would be fine with adding that. To address Isarra's point, rather than putting it in the "Examples of harassment" list, it could be a separate line item afterwards, saying "Do not encourage people to harass or personally attack others" or something like that. Mattflaschen-WMF (talk) 03:51, 12 August 2015 (UTC)

Rewrite based on Contributor Covenant?

Fhocutt (WMF) 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)
I just read <https://github.com/CoralineAda/contributor_covenant/blob/4905401/CODE_OF_CONDUCT.md> and I like it as well. It seems like a much better starting point. --MZMcBride (talk) 23:33, 10 August 2015 (UTC)
I think this is a good idea. We will need to modify it to take our specific processes, spaces, community standards, and ways to report a violation into account--specificity in these areas is one of the best practices for codes of conduct that are effective in practice--but it's a solid base to start from. Fhocutt (WMF) (talk) 05:44, 11 August 2015 (UTC)
I agree that there's also room for a separate set of guidelines on what respectful, productive, collaborative technical work looks like in practice, and would like to see momentum on this policy carry over to those guidelines as well. Fhocutt (WMF) (talk) 06:01, 11 August 2015 (UTC)
I like it as well. It's more focused and specific. wctaiwan (talk) 04:46, 12 August 2015 (UTC)
+1 here - the original proposal was a good start, but it seems like a better idea to build on something that has already gotten a lot of feedback from a wide variety of sources. —Luis (WMF) (talk) 21:32, 13 August 2015 (UTC)
+1 for the same reason as Luis. Something that's widely used just carries more weight. I think in general people who misbehave don't stop to carefully read codes of conduct. The more likely potential violators are to have encountered other communities that effectively defend themselves with the same policy, the better. Milimetric (WMF) (talk) 00:58, 15 August 2015 (UTC)
+1 ^ YuviPanda (WMF) (talk) 10:35, 17 August 2015 (UTC)

What about this:

  1. Fhocutt (WMF) publishes a first version based on Contributor Covenant's Code of Conduct at Code of conduct for technical spaces with a {{draft}} template at the top and a disclaimer saying that this is a proposal under discussion.
  2. All the better if Talk:Code of conduct for technical spaces has Flow enabled. It allows for better subscription to specific topics and for marking topics as Done (cc DannyH (WMF)).
  3. We keep this page & talk page here for background with disclaimers on top pointing to the current draft and discussions. Once we are confident that anything valuable has been moved to the new pages, we archive these pages here.

--Qgil-WMF (talk) 07:54, 14 August 2015 (UTC)

It could also be someone else--I care much more about getting something effective and workable together than who does it. Otherwise, fine by me. Fhocutt (WMF) (talk) 17:49, 14 August 2015 (UTC)
If there is consensus to rebase on Contributor Covenant (as looks likely) I plan to do so after at least a week from my post above. I will start with a clean copy of Contributor Covenant. Various people have ideas on how to update the draft from there, so I expect quick changes after we have the new baseline. I do not see any reason to start a new page at Code of conduct for technical spaces. We can just update the draft here, which is a more appropriate title since it's still a draft. If someone wants to request Flow, I suggest starting a new section about that. Mattflaschen-WMF (talk) 20:58, 14 August 2015 (UTC)
I've gone ahead and uploaded a clean copy. We can start refining it now. We should pull things we're agreed on from the old version, and some people have ideas for text to add to this base. Mattflaschen-WMF (talk) 00:00, 18 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. -- (talk) 05:02, 10 August 2015 (UTC)

The fact Freenode has a policy on harassment doesn't preclude use from having more specific guidelines. Harassment of women on IRC is well documented, so it's clear existing guidelines don't achieve the intended effect. I agree it would be good for the policy to be announced in the topic -- not for would-be harassers, but for people who are at risk for being harassed. They need to know we will not accept harassment. Valhallasw (talk) 07:48, 10 August 2015 (UTC)
Threatening WMF global bans for those accused of being in some vaguely defined way "non-positive" or disruptive is not an improvement on Freenode's harassment policy nor on existing community agreed policies for conduct enforced by trusted unpaid volunteers. This Code unnecessarily relies on a process with no possibility of appeal, nor any requirement for evidence to be examined by the accused or their elected peers. It puts an unaccountable faceless harassment police force of WMF employees at the centre of our community, rather than the WMF published strategy of putting the volunteer at the centre.
Just to be absolutely clear, the concept of a code of conduct I have no objection to whatsoever. Nor do I object to more being done about harassment (and not just harassment of women). However this code attempts to define "technical spaces" as almost everything where I might write about technical issues, then jumps into a solution of global bans which are completely unnecessary when there are plenty of volunteer driven systems available. Thanks -- (talk) 08:15, 10 August 2015 (UTC)
The point about the global ban policy has been rephrased. It's hard to see how it could apply to non-Wikimedia IRC channels ("self-identified Wikimedians whenever they are using an IRC channel") when it explicitly limits itself to "Wikimedia's technical spaces"; I don't know how e.g. the emacs channel could be considered "Wikimedia's technical spaces". Mattflaschen-WMF (talk) 06:42, 11 August 2015 (UTC)
No IRC channel is actually "Wikimedia's" as they are not run by Wikimedia, yet this policy asserts its authority on those spaces; if by "Wikimedia's" we means any channel with "wikimedia" in it, then that applies to #wikipedia-en and #wikimedia-commons whenever anyone wishes to assert that there was a technical discussion in those places.
Apart from presuming that "technical spaces" means any technical discussion anywhere, there is no definition so it is not limited. Unless the is accurate qualification of the scope of the Code, it seems fair to presume that users will apply it to all of the technical spaces mentioned where they may want to escalate a dispute, and it will therefore have the authority to bypass all local policies (as the ultimate sanction of a global ban is how it will be enforced). -- (talk) 06:48, 11 August 2015 (UTC)
For the IRC channel issue, what about the idea of having each channel's topic say whether this code of conduct applied there? Mattflaschen-WMF (talk) 01:48, 12 August 2015 (UTC)
I am an op on a couple of IRC channels and have set notices for a few. I agree that channels should be encouraged to opt-in to conduct policies beyond Freenode's standard. It is tricky to assess whether the specific community that are IRC users have a consensus for policies like this, rather than a few individuals who happen to be participating that week. Some channels benefit from highly specific behavioural guidelines, for example #wikimedia-lgbt has had a friendly "PG-13" language warning in its notice, which was added not long after it started, to encourage participants to stay friendly for potential minors. I guess discussion with channel participants a couple of times would probably be the way to go, or if there was an appetite to discuss it for a particular Wikimedia channel, a vote could run on a related wiki. However I suggest that in many cases we can encourage the more widely applied safe space guidelines as sufficient, and these have proved pretty uncontentious since their original creation (I think the version we put together at the UK chapter after some issues with real life events was the starting point back in 2012). -- (talk) 02:07, 12 August 2015 (UTC)
Which safe space guidelines are you referring to? Mattflaschen-WMF (talk) 04:01, 12 August 2015 (UTC)
Primarily https://wikimediafoundation.org/wiki/Friendly_space_policy though specific ones exist for some projects, such as meta:Friendly_space_policies and https://wikimedia.org.uk/wiki/Participation_policy which already apply to related spaces. -- (talk) 07:47, 12 August 2015 (UTC)
The Friendly space policy only applies to in-person events, not online. Mattflaschen-WMF (talk) 20:04, 12 August 2015 (UTC)
Yes, though some do specifically apply to virtual spaces, the distinction being slightly arbitrary as wiki-events invariably have significant virtual components and virtual participants for all related activities before, during and after physical events. Strangely enough, the harassment cases that spring to mind in relation to complaints in relation to friendly space policies, have involved virtual world actions such as deriding photographs online from events and outing participants online post-event. -- (talk) 05:19, 13 August 2015 (UTC)
Hi, This closes a major loophole in which Wikimedia IRC channels, notably #wikimedia-commons were used in most inappropriate way. Fae is very well aware of that, if not part if the issue, so it is not surprising that he opposes this policy. Regards, Yann (talk) 21:37, 11 August 2015 (UTC)
Please don't smear me with false allegations to make a point. I flatly and absolutely deny your snide claims about what I know, and heavy hints to make others believe I have some sort of evil motivation to scare me off asking basic questions about this proposed governance related policy. Please focus on the issues, rather than taking discussions off on a tangent through maligning participants. If you have evidence of harassment to present, please, please do present it in the correct forum where I would be happy to be held to account and answer any question based on evidence, rather than poisoning this discussion in an unhelpful and unpleasantly disruptive way. -- (talk) 01:30, 12 August 2015 (UTC)
What I find very interesting in this discussion is the notion that what pertains to the wiki, doesn't apply to IRC. This would further infer that on wiki status would not carry over to IRC, yet, virtually all of the IRC Ops are admins on Wiki, they frequently threaten people with bans from various IRC channels for either on Wiki justifications or for not doing what they, as admins/ops, say. Its also not uncommon for links to on Wiki essays and guidelines to be used as justifications for blocks or bans on IRC. So what this appears to me to be is a classic case of picking and choosing when to apply a policy or rule and when not too. For example, if an editor does something an admin doesn't like, the admin on the IRC channel can block the other person without cause or justification and the WMF won't get involved. This being the case, the WMF really just doesn't appear to care about blatant IRC disruptions caused by Ops/Admins like Yann who frequently block or ban editors from the channel for what they want. This is unfortunate and disappointing to me but not entirely surprising given the WMF's history of lack of control over admins and the abusive environment they enable to turning their backs on editors. Reguyla (talk) 01:50, 12 August 2015 (UTC)
I don't know the history of all the IRC issues being discussed here, so don't misunderstand me as taking sides. But I do completely agree that the Wikimedia IRC technical community is intertwined with the rest of the Wikimedia technical community (including MediaWiki.org). Mattflaschen-WMF (talk) 03:58, 12 August 2015 (UTC)

I believe that #wikimedia-commons as an irc channel is definitely out of scope of this. This is not the place to discuss etiquette guidelines for the entirety of the Wikimedia movement. If people want to do that, they should try their luck at meta. Bawolff (talk)

Without going into the specifics over whether WMF has reach over IRC channels, let me say that many channel operators, especially in the channels concerned, are not willing to ban someone unless they see clear evidence of actual wrongdoing in the channel. So even if WMF can do this, on a day-to-day basis, the existing operators may not be willing to enforce it.--Jasper Deng (talk) 18:44, 13 August 2015 (UTC)

We can agree that inappropriate behavior is equally inappropriate on-wiki, on-Phab, on-IRC, etc. Freenode's policies define the basic rules of Freenode. Our CoC cannot enter in conflict with such policies, but can build on top of them. https://meta.wikimedia.org/wiki/IRC/Channels#MediaWiki_and_technical should define which IRC channels are used as collaboration channels by the Wikimedia tech community (if the list is out of date, it can be updated). I don't think that an IRC channel related to the Wikimedia tech community can opt-out of a CoC or any other policy if it has been approved for all the tech community, just like I don't think a specific Phabricator project or a specific mailing list can opt-out either. In the "Enforcement" section I'm proposing that the first level of handling of complaints should be the own admins/maintainers of the spaces) affected by the complaint. If you agree with this idea, this would mean that a complaint about a situation in #wikimedia-foobartech would be handled first by the own channel operators. If the ops don't feel like solving the complaint alone or if the person claiming doesn't think that these ops will solve their problem, then a second level would take the issue (and that second level may or may not be formed by WMF employees, that is to be decided).--Qgil-WMF (talk) 08:13, 14 August 2015 (UTC)


Enforcement

I understand that this page is currently a draft. I'm curious when the enforcement-related question marks will be filled in. Specifically:

  • Alternatively, contact ? directly about the issue.
  • In the case of persistent disregard of these guidelines or if you are uncomfortable contacting the person directly, contact ? on Wikimedia IRC or send an email to ? and ask them to look into it.

If this proposed code of conduct is implemented, who will be responsible for handling complaints and how will this person or group do so across IRC, Phabricator, Gerrit, mailing lists, the wikis, etc.?

Assuming action is taken by this person or group, such as instituting a temporary or permanent ban of an individual, what will the appeal process be? --MZMcBride (talk) 23:26, 10 August 2015 (UTC)

I very much support moving forward and making progress towards putting this Code of Conduct for Technical Spaces into place. Thank you very much for spending the time and energy to create it and the time and energy to discuss, change and defend it - however I have the same questions as MZ has written out above (specifically about enforcement). It would also be good to know the difference between actions that would result in a temporary ban vrs ones that would result in a permanent ban and why. It is very clear at in-person events when people have willingly opted into the Friendly Space Policy (they must agree to the policy to register), decisions about enforcement are up to the event organizers and (more or less) fully left to their discretion. We have removed people breaking these policies from events in the past without issue. In this case if we don't have clear and **agreed upon** steps to take in order to enforce this we will run into issues. In case people have not seen what has been going on here, you should check it out: https://meta.wikimedia.org/wiki/Grants:Friendly_space_expectations It seems to be working well and very reasonable, but I think they had a slightly less complex problem to solve. Rfarrand (WMF) (talk) 22:58, 11 August 2015 (UTC)
This is an open issue. As far as "It would also be good to know the difference between actions that would result in a temporary ban vrs ones that would result in a permanent ban and why.", I think there is a role for discretion in this policy as well. It's hard to set a precise per-determined penalty for every grade of violation of every type of forbidden conduct listed. Mattflaschen-WMF (talk) 03:42, 12 August 2015 (UTC)
This seems to be the central and hardest question. Who exactly [has to/gets to] decide (A) what is "over the line", (B) what the outcome is in each instance?
The Ada CoC just says "Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by opening an issue or contacting one or more of the project maintainers." - Who is that, in our case? Who gets that burden/power/responsibility/role/unpleasant-chore? Who do we turn to, trust, and expect effort and investigation from?
Speculation: They can't be staff-only, because that would raise concerns about COI issues when the reporter/reported is a staff-member (and by god do some of the staff get verbally abused a lot, by anonymous and non-). They should be privacy-minded/discretion-trained/perhaps-even-NDA'd people, because they might be sent private evidence. They should be empathic and understanding of cultural and linguistic diversity. They should include experienced mediators/communicators, because they'll need to deliver warnings and decide on consequences, in a way that doesn't make the instance worse, nor fragment the communities. Constituting a proper group to review and respond is the critical factor in adopting any such plan that will work. –Quiddity (talk) 17:58, 12 August 2015 (UTC)
I think the points of contact and enforcement can be organized at two levels. The first level is formed by the administrators or maintainers of the space where the problem happens. All our technical spaces have individuals with permissions to ban a user, and that responsibility is acquired through experience and merit. This might not be as simple in practice, but as a principle I think it works. The second level should be used as escalation point if the first level is no good fit for addressing the problem for whatever reason. The simplest option would be to pick a related WMF team (Community Advocacy or Engineering Community being logical candidates). If this simplest option is seen as problematic for being in practice restricted to WMF employees (I personally don't think this is a problem, but such concern has been raised by some people) then a small committee could be formed with 3-5 people chosen among the admins and maintainers active in the first level.
The point here is not who exactly can be point of contact and enforcement, because we have enough qualified people with enough community trust to be in this role. The point here is to assure that there is people officially appointed to this role with community backing. This way a person willing to report knows where to go with confidence and trust, and a person being eventually warned or banned knows that the person warning / banning is doing that in a community role, not on a personal motivation.--Qgil-WMF (talk) 12:38, 13 August 2015 (UTC)
At the beginning of this thread it was asked "what will the appeal process be?" I cannot see this being addressed yet. Until there is a credible agreed appeal process to assure the community that our shared values of transparency and accountability are being addressed, this will remain controversial, regardless of whatever procedure is devised (presumably this process remains the choice of WMF executives, unless there is a shift to putting this in the hands of elected volunteers?) for appointing community prefects/collegiality monitors or whatever they are going to be called who are granted special banning powers. -- (talk) 14:59, 13 August 2015 (UTC)
@: , I have created a section to discuss the appeal process specifically. There is nothing in this CoC and its application that "remains the choice of WMF executives". In my proposal just above I'm not considering anyone "who are granted special banning powers". The Wikimedia tech community already has users that have these permissions ("administrators and maintainers" for simplicity). Even if we decide that we have a second level of enforcement (say a WMF team, an elected committee, etc) this should not grant to its members any "special banning powers". When such group would reach to a conclusion, they would ask the admins/maintainers of the affected space(s) to execute the ban. Note that this distribution of power would be an intrinsic appeal process in itself, because it will be effective only when there is enough consensus between the acting parts. All we agree that the last thing this CoC and Wikimedia tech community needs is a single person or a single entity with superpowers able to take executive shortcuts. In the way this proposal started and develops, I'm not seeing any risk of falling in this situation. If you have concerns, let's address them in the writing and implementation of this CoC.--Qgil-WMF (talk) 07:41, 14 August 2015 (UTC)
Thanks for setting up the section. With regard to your statement "nothing in this CoC and its application that "remains the choice of WMF executives"", I did not make this up, in fact the statement "Following approval from executive or legal staff, individuals who meet the criteria may be banned from all Wikimedia spaces, including technical ones" was added by Mdennis (WMF) on 7 Aug and eventually edited out by Mattflaschen-WMF on 11 Aug. Presumably this statement about global bans is entirely accurate, and while global bans remain an option then "executive or legal staff" will be part of how this policy will be implemented and interpreted. -- (talk) 10:01, 14 August 2015 (UTC)
OK, understood. I take the mention to the Global Ban Policy only as a reminder that it exists. This CoC and its handling should be compatible with that policy but independent from it. If someone in the Wikimedia tech scope is getting more points to receive a global ban, it would not be based on infractions against this CoC but on the criteria of the Global Ban Policy itself, and that would be handled according to the process of that policy.--Qgil-WMF (talk) 11:55, 14 August 2015 (UTC)
The interrelationship needs to be spelt out in the escalation process. As you infer, it would be best to avoid giving the impression that this policy is part of policies or legal documents controlling office locks and global bans, so the changes to this draft in the last week to move away from that hard line stance are a distinct improvement. This is the first time I have read "points" being part of the system. It would be a good step towards transparency if any system like this were made public and volunteers could ask about their own status if they are in doubt, and ask for review or start an appeal, rather than this being like expecting repercussions for asking about black ops. -- (talk) 13:41, 14 August 2015 (UTC)
"Getting more points" was just a casual expression written by this non-native English speaker. I think the process we need should be as transparent as possible taking into account privacy considerations (I can see how many times a three party private conversation can be more effective solving a problem than a fully public and transparent claim/appeal process). In any case, I don't think we need anything like w:Point system (driving) here.  :) I'll pay more attention to my casual phrasing in this discussion. And let me insist, we are designing a Code of Conduct to improve community health that must go through community approval, not a toolkit to recreate a police state.--Qgil-WMF (talk) 13:52, 14 August 2015 (UTC)

Bug management/Phabricator etiquette

If this code of conduct is adopted, what will happen to Bug management/Phabricator etiquette? --MZMcBride (talk) 23:55, 12 August 2015 (UTC)

Parts of the CoC might cover and hence supersede parts of the Phabricator etiquette, while other parts of the Phabricator etiquette are so Phabricator-only specific (e.g. status and priority fields) that they could remain and simply extend the CoC. --AKlapper (WMF) (talk) 10:35, 13 August 2015 (UTC)


"Sexual imagery or verbiage in public technical spaces"

I believe this example has been expressed oddly; possibly "verbiage" is used differently in modern British English compared to American English. Was the intent to say that sexual imagery and sexual texts are harassment, or was it actually intended that "verbiage" of any kind can be interpreted harassment? This reads as if writing a long complaint could now be called harassment just for being long-winded.

The adjective is meant to apply to both nouns. In other words, it's equivalent to "sexual imagery or sexual verbiage". If someone else finds this confusing, we could change it to that. Mattflaschen-WMF (talk) 23:47, 13 August 2015 (UTC)

As a secondary issue, the example concerns me as "sexual imagery" is vague wording, and in practice has been clearly interpreted on the English Wikipedia to include "sexuality", hence material like LGBT event photographs and historic material which might include partial nudity, such as 19th century ethnographic photographs. I understand what is probably intended, something like nudity or sexual photographs which are likely to cause offence when presented inappropriately. Could someone rephrase this so that the example is unlikely to be a cause of arbitrary future contention if we are discussing technical issues with topics like Wiki Loves Pride events or linking to categories for media in a medical education/history project and could include photographs or diagrams with partial nudity, such as the images from the Wellcome Library or diagrams from Cancer Research? Thanks -- (talk) 11:16, 13 August 2015 (UTC)

This is intended to be a code of conduct for technical spaces; it doesn't affect how Wikipedia chooses to cover e.g. 19th century ethnography. I think people will understand that if you are in the process of working on a technical problem, and incidentally have to link to an image or category with nudity, that would not be a violation (but it might be worth adding a NSFW on the bug report or whatever). Mattflaschen-WMF (talk) 23:47, 13 August 2015 (UTC)

Criticize ideas, not people

I am not a fan of that phrasing. First, there is not all that much difference between "your idea is stupid" and "you are stupid". There is an unfortunate misconception in certain circles of the community that the second is a personal attack but the first is fine, and we should not reinforce that. Second, publicly challenging improper behavior can be an important part of upkeeping community norms and socializing newcomers, and the "consequences" part explicitly suggests it as a first step of enforcement, but it would be itself a violation under this rule. --Tgr (WMF) (talk) 21:49, 16 August 2015 (UTC)

I think we can drop this now that we've rebased onto Contributor Covenant. They instead use different language with the same purpose, mainly "Examples of unacceptable behavior by participants include [...] derogatory comments or personal attacks [...]". Mattflaschen-WMF (talk) 00:08, 18 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)

I agree. I was a fan of the safe space policy going into effect for developer events, and that has since been extended first to Wikimania, then other Wikimedia events, and now recipients of WMF grants. With the board, Lila, CA, and others stating that looking into ways to address community collegiality is a priority for this year - this seems like a logical effort for the developer community. I agree it is not perfect, but I have yet to see an online community policy that was. ;) I endorse the idea of proceeding with refinements based on this page's discussion - but not delaying things for months and months in an attempt to achieve a perfection that will likely never come. However, Brion is correct that we must all also own up to our own role in this problem - and yes - there is a problem. --Varnent (talk)(COI) 02:46, 11 August 2015 (UTC)
I agree. I can admit that sometimes I have gotten more heated than I should have. None of us are perfect. Hopefully, this serves as a reminder for us to stay respectful. Mattflaschen-WMF (talk) 05:46, 11 August 2015 (UTC)

A tangent on wording; almost anything written online can be interpreted as passive aggressive. This is especially true in an international and multilingual context. For example written British English (at least for anyone educated before the 1980s) leans to self-effacing to be polite, this careful politeness in an online modern or Americanocentric context is easily interpreted as slyness, sarcasm, or passive aggressive. A general rule of thumb should be to double-check, as sometimes simple good faith and echoing back your reading in plain English, will quickly diffuse what might appear to someone from a different cultural background to be passive aggressive or annoyingly sarcastic. -- (talk) 02:14, 17 August 2015 (UTC)

Need clarification on the scope

I'm watching this discussion since someone posted a link in Commons' village pump. At first, I didn't see anything concerning to my activities there (my main project) and wonder how it affects a Commoner. Now I saw more Commoners raising concerns here. So I re-read the draft. It has two parts of scope; physical and virtual. "Physical" is noway relevant to Commons or any other WM projects as we are not physically meeting any. In "virtual", I see only "MediaWiki.org, Phabricator, Gerrit, technical mailing lists, technical IRC channels, and Etherpad". No other WM project like Commons is mentioned. My understanding is also a WM project like MediaWiki has no control over such projects. General policies like Global ban must be defined in Meta. So I wonder from where these concerns are coming?

I can understand MW has the right to block somebody if s/he misbehaved to a volunteer here on/off-mediawiki. But off wiki activities need investigations by some higher authorities like Arbcom. Commons doesn't such a setup and many people make benefit from it. But it is a "common" problem and not relevant here.

I also see "global ban policy" is mentioned in the draft. It only means people who apply global ban can consider the reasons which result a block here too, while considering a GB against a user. It is quite logical and I see nothing particular in it.

Am I correct? Let me correct; if I'm wrong. Jee 02:46, 12 August 2015 (UTC)

Yes, I think this is basically right. Some of the prior questions and comments were when it said, "virtual (including but not limited to MediaWiki.org, Phabricator, Gerrit, technical mailing lists, technical IRC channels, and Etherpad)". Now it says, "virtual (MediaWiki.org, Phabricator, Gerrit, technical mailing lists, technical IRC channels, and Etherpad)" (no "but not limited to", so no ambiguity about which web sites (or parts of them) it applies to). If there are problems in virtual technical spaces that are not listed here, the policy could be amended after further discussion. Mattflaschen-WMF (talk) 04:06, 12 August 2015 (UTC)
Thanks Mattflaschen for the clarification. Tgr's suggestion below is also very good. It is other project's responsibility to monitor their lists and IRC channels. Jee 04:48, 12 August 2015 (UTC)

Would it be fair to say that technical mailing lists are the ones listed under m:Mailing_lists/Overview#MediaWiki_and_technical, and technical IRC channels are the ones listed under m:IRC/Channels#MediaWiki_and_technical? Those lists seem fairly comprehensive (and if not, they should probably be fixed anyway). --Tgr (WMF) (talk) 04:27, 12 August 2015 (UTC)

I'm pretty sure a lot is missing from both those lists. Bawolff (talk) 08:05, 12 August 2015 (UTC)
True, but it is easier and better to update those pages than let people guess. The rebased text says "This is a code of conduct for Wikimedia technical spaces." I think we should spell out those spaces, right there after a colon or somewhere below. The list: mediawiki.org, wikitech.wikimedia.org, wikimedia.phabricator.org, gerrit.wikimedia.org, Wikimedia technical mailing lists, and Wikimedia technical IRC channels. Is the intention to keep this CoC for online spaces only, since events are already covered by the Friendly Space policy? If so, that should be explained as well, for context (now it's in the See also, I think it should be integrated to the text).--Qgil-WMF (talk) 11:26, 18 August 2015 (UTC)
No, it's explicitly for physical spaces as well ("Project spaces can be both physical, such as hackathons and other technical gatherings"), and has been since the beginning of the draft (though the wording has evolved). As far as IRC, I'm not sure whether it's better to use the topic (which can be controlled by the channel) or a Meta list that anyone can edit. Mattflaschen-WMF (talk) 20:41, 19 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)

FYI, The TODO code of conduct actively puts marginalized people in harm’s way. (...) This Code of Conduct is essentially legalese to protect the corporations and their cis straight white men contributors from accusations of sexual discrimination, racial discrimination, and with the recent EEOC ruling, homophobic and transphobic discrimination. - https://modelviewculture.com/news/todo-group-and-open-source-codes-of-conduct Valhallasw (talk) 07:35, 10 August 2015 (UTC)
That blog post falls very far from the standards of constructive and respectful communication it supposedly promotes, and is full of falsehoods (for example, check the pull request it links to and compare the actual discussion with the way it's characterized in the post). I don't think it should be taken seriously. --Tgr (WMF) (talk) 07:47, 11 August 2015 (UTC)
Another resource which helps explain why codes of conduct can help, is https://adainitiative.org/2014/02/howto-design-a-code-of-conduct-for-your-community/ . Mattflaschen-WMF (talk) 01:40, 20 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)

Agreed. --MZMcBride (talk) 23:16, 10 August 2015 (UTC)
All of it is meant to be binding with the possible exception of the first sentence, which is kind of a preamble laying the groundwork. I feel like "Communicate about technology in public where possible" is relevant to the document, even though it's kind of non-actionable due to "where possible", because this is an important part of the MediaWiki ethos. "Comments should be made with the intention of constructively contributing to our technologies." is actionable; it means e.g. comments that are purely unconstructive attacks are not appropriate. I would expect this would not be enforced for one-off insignificant off-topic comments, but only to deal with major disruption. It doesn't say patches can't be rejected; a lot of patches need to be rejected, for valid reasons (product, technical, or both). It just says "consistent and unwarranted rejection of patches" (emphasis added) is not appropriate. Mattflaschen-WMF (talk) 06:28, 11 August 2015 (UTC)
I certainly don't think it should be a policy that communication happens in the open (the foundation may wish to mandate that for WMF developers, but this shouldn't be binding on volunteer developers). Unconstructive attacks may be actionable, but as written it's too vague and too broad (e.g. foundation PMs may argue that debating whether a feature is wanted at all is "unconstructive"). "Unwarranted" also leaves a lot of room for interpretation.
I'm not fundamentally opposed to covering both best practices and actionable misconduct on the same page (e.g. first list the goals of a CoC and document best practices, and then list what is considered actionable), but I think the latter needs to be concrete and separate for it to be enforceable at all. wctaiwan (talk) 07:28, 11 August 2015 (UTC)
Not to mention the fact that banning someone from one or more MediaWiki forums (the only real enforcement available for these rules) would presumably make them more likely to communicate with others privately. Yaron Koren (talk) 17:47, 11 August 2015 (UTC)
This is not the only enforcement mechanism given. It explicitly makes clear that in some cases, just talking to them is the best way to go, and in other cases, issuing a formal warning may help. Even in the case of bans, there are different types given. Mattflaschen-WMF (talk) 02:03, 12 August 2015 (UTC)
I wouldn't consider a warning to be enforcement, but that might just be a semantic issue. Yaron Koren (talk) 02:33, 12 August 2015 (UTC)
It doesn't mandate solely public communication for anyone, WMF or otherwise. It just expresses that you should default to make it public (then consider the alternative, where appropriate), rather than go the other way. Mattflaschen-WMF (talk) 02:03, 12 August 2015 (UTC)
Anyway, as I said above, while I think the "Communicate about technology in public where possible" line is relevant, it's not really actionable due to 'where possible'. I don't have my heart set on keeping it. Mattflaschen-WMF (talk) 03:19, 12 August 2015 (UTC)

(outdent) My concern is less about the specifics and more about the enforceability of a code of conduct that is deliberately designed not to be specific. You mention the role of discretion below. I'm fine with, say, discretion as to whether to give someone another chance, or whether something constitutes a pattern of disruptive behaviour, but as it is there isn't enough clarity when it comes to the line between best practices and actual rules. wctaiwan (talk) 04:37, 12 August 2015 (UTC)

@Krenair: @Yaron Koren: Krenair put back "We also pledge to communicate about MediaWiki/Wikimedia technology in public where possible" and made it even stronger. I don't have a strong preference on the first part (though I respect the fact that it was removed before, and understand why), but I think "All written non-security-related discussion about changes to MediaWiki core and extensions and skins which are deployed to Wikimedia sites or included in the MediaWiki tarball releases must be public." is way too strong and I've removed it. Mattflaschen-WMF (talk) 01:23, 18 August 2015 (UTC)
I have no idea what a "pledge" means in the context of a code of conduct. Actually, I have no idea what "we pledge" means here at all - most people aren't pledging anything, so it just sounds like false information. Yaron Koren (talk) 02:19, 18 August 2015 (UTC)
As much as I agree with the importance of public communication, I'd rather keep the CoC within the core goal of "making participation in Wikimedia technical projects a respectful and harassment-free experience for everyone". Someone not communicating publicly will not automatically incur in disrespect or harassment. I would leave it out.--Qgil-WMF (talk) 11:15, 18 August 2015 (UTC)
I agree with Quim. We should keep this document tightly focused on identifying prohibited forms of harassment, rather than general good practices. I added a part about the Wikimedia mission because I think it strengthens the case that prohibiting harassment is core to our values, but on the other hand I think communicating in public is a different principle and should be discussed elsewhere.—Neil P. Quinn (talk) 22:23, 18 August 2015 (UTC)
+1. I think that a separate document on positive ways that we communicate respect for each other and for the movement (somewhat like the positive portions of the Phabricator etiquette) is a very good idea and that this would fit well in there, but I agree that it would be better to focus this on our core goal. --Fhocutt (WMF) (talk) 00:55, 19 August 2015 (UTC)
Okay, in that case I'll go ahead and remove it.—Neil P. Quinn (talk) 22:12, 19 August 2015 (UTC)

Enforcement in new draft

The enforcement and reporting are now way more detailed, which is both a good and a bad thing. It's good because there's less ambiguity, but that much text may distract from the rest of the document. Also, since it comes from multiple sources, there are consistency and redundancy issues to work out. We may want to separate it out to a subpage (both as a break-out page if the overall Code of Conduct is approved, and for discussion now). Mattflaschen-WMF (talk) 01:28, 18 August 2015 (UTC)

(((Comments have been moved to "Right to appeal"))).--Qgil-WMF (talk) 09:13, 20 August 2015 (UTC)
The current section Enforcement contains two lists of "possible responses: that, well, look too similar. Wouldn't it be better to consolidate a single list, and then have a new section "Appeal" with the details of the appeal process?--Qgil-WMF (talk) 09:49, 20 August 2015 (UTC)
@Qgil-WMF: Which two lists are you referring to? The "For a simple case" is for actions a single member can take on their own. The "Possible responses to a reported breach of the Code of Conduct may include" is a list of things the full committee can do. I've tried to clarify this. Mattflaschen-WMF (talk) 02:41, 21 August 2015 (UTC)


First line of enforcement

I would like to float an alternative proposal for first line enforcement. I suggest that there should be a small group (probably either 3 or 5) of people from our technical community (both volunteers and staff, based on their involvement in the tech community). There would be an OTRS or mailing list address pointing to that group. I think the steps would be something like that:

  1. Someone emails e.g. techcoc@wikimedia.org , or contacts one of the members on IRC. If it's OTRS, I think the email could auto-create a ticket, and maybe for IRC it could be created manually from the web interface?
  2. For a simple case (e.g. first offense, minor harassment in a single space), a single member could:
    • Defer to the space itself (e.g. MediaWiki.org admins in the case of an incident on MediaWiki.org, or event organizers for a hackathon), if they seem best-equipped to handle it.
    • Issue a public or private warning directly.
    • Decide to take no action (logging why and notifying the reporter)
  3. For a more complicated case (e.g. repeat offense, when a ban looks like like it will be required, or where there is cross-space harassment), the initial responder could ask other members of the group for feedback, and can also bring in people from the spaces involved (e.g. if it happens on both MediaWiki.org and IRC, bring in involved admins and IRC contacts).
  4. In case of even more complicated or urgent matters, or if the group is unable to reach a decision (e.g. the minority in the group objects to the decision), it can be escalated.
  5. After the initial outcome (which would always be logged, even if it's just 'deferred to XYZ' or 'no action taken'), the reporter should be notified.
  6. The reporter always will be notified of the initial outcome, and has the right to appeal (see separate discussion).
  7. If public action is taken on the basis of the CoC (whether by the group or by local maintainers of the space), the alleged offender also has the right to appeal.
  8. Appeals would be taken to the same group that the committee could choose to escalate to (which group is under discussion).

Part of the goal here is the person who feels harassed does not need to look up different policies and points of contact depending which space it happened in. They can always contact the same email (or IRC). Mattflaschen-WMF (talk) 21:21, 14 August 2015 (UTC)

Also, I suggest that all participants in the first-level group be required to be identified to the WMF. Exactly how the group is formed could be determined if people otherwise support this proposal. Mattflaschen-WMF (talk) 21:36, 14 August 2015 (UTC)
I think this is a good start. I think that the Engineering Community Team is a logical group for the second level response. I'd like to see this group made up of WMF staff, technical volunteers, and one representative from ECT, since ECT has considerable knowledge about community structures and dynamics. I think that an email ought to be a sufficient place to report to--IRC is likely to be more complicated to monitor, and I don't think it's necessary as long as emailed reports get a prompt response. --Fhocutt (WMF) (talk) 02:38, 15 August 2015 (UTC)
I don't have a strong preference to keep an IRC point of contact. People might still informally report stuff there, but the email can be the definitive way. Mattflaschen-WMF (talk) 00:12, 18 August 2015 (UTC)

Some notes and suggestions:

  • Anonymizing reports are terribly important here. Specially when it comes to sexual harassment. we need more explicit statements on this to ensure people to feel more comfortable. I think CA can help us.
    Yes, this should be addressed in the draft. Maybe, in case of private harassment, not allowing release of the victim/reporter's name (even in the course of a public apology) without the reporter's consent. In the case of public harassment (at least where it is not/can not be oversighted), the victim/reporter is already known, and since it happened publicly it can sometimes be important to speak out. Mattflaschen-WMF (talk) 00:26, 18 August 2015 (UTC)
  • In lots of cases people already made contact with local maintainer of space (e.g. someone harassed me in mediawiki.org and initially I will contact admins of mediawiki.org but in some cases they don't handle it well. Lack of experience from admins, influential friends, being "too" valuable, etc.) So we need to determine a way to handle such cases.
    Yes, this is a good argument for having a central point of contact (techcoc), plus an appeal process in case even that fails. Mattflaschen-WMF (talk) 00:26, 18 August 2015 (UTC)
  • Punishment vs. protecting the system: Imagine I offended someone in pywikibot code review. What is the best action? Do you think I should be banned for a while or I should be stripped off from my owner rights or both? this states "Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the project team." Should we have something like this?
    We have language about this from Contributor Covenant now. Not sure how much we'll tweak this; we will probably need a Wikimedia-specific enforcement section at any rate. Mattflaschen-WMF (talk) 00:26, 18 August 2015 (UTC)
  • Removal of comments: you didn't define anything about this. e.g. the CoC says: "Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this project." Ladsgroup (talk) 08:22, 15 August 2015 (UTC)

From the perspective of a maintainer

In other sections, others have already clarified why a code of conduct is a good idea from the perspective of potential contributors and victims, but I'd also like to share the perspective of a maintainer. On the Pywikibot mailing list, we have had our fair share of behavior that is not OK, but I've always been reluctant to actually put the users on moderate, or to ban them from the mailing list altogether. Why? I wasn't sure whether that was the right thing to do, and I was afraid of the backlash that would probably follow.

Having an explicit policy makes policing behavior also much easier. From one side, it's much easier to say 'hey, you are violating the code of conduct', and from the other side, having the policy means we //have to// intervene. It's much easier to act on a previously agreed policy than acting off the cuff. Let's make clear rules, and let's use them to make this environment more fun to work in. Valhallasw (talk) 21:31, 16 August 2015 (UTC)

Mailing list etiquettes already exist. --Nemo 07:17, 21 August 2015 (UTC)
Are you referring to m:Mailing lists/Guidelines? I added this link to See also.--Qgil-WMF (talk) 09:00, 21 August 2015 (UTC)

Harassment

In the "Unacceptable behavior" section, we start of by saying that unacceptable behavior includes a variety of things, one of which is harassment. We then continue by saying harassment includes a whole list of things, which includes all the other unacceptable behaviors we listed in the first place. How about we simplify this by saying the following?

All forms of harassment are unacceptable in Wikimedia technical spaces, both online and in person. This includes but is not limited to the following behaviors:

  • Inappropriate or unwanted communication, including on-wiki messages, private or public IRC messages, email, texts, and chats.
  • Sustained disruption of discussion, talks or work, for example by personal attacks, constant interruption, trolling or consistent and unwarranted rejection of patches.

Neil P. Quinn (talk) 22:16, 18 August 2015 (UTC)

@Neil P. Quinn-WMF: I see what you mean. I think it's important to state that we do not want our technical spaces to include "sexual language or imagery, derogatory comments or personal attacks, trolling, public or private harassment, insults", regardless of whether they rise to the level of harassment or not--even if these things are drive-by one-off comments, they make technical spaces less welcoming for many people. How about mentioning that harassment can include any of the above and removing them from the list of potentially harassing behaviors instead? --Fhocutt (WMF) (talk) 00:46, 19 August 2015 (UTC)
Take a look now--I think this version is clearer. --Fhocutt (WMF) (talk) 01:17, 19 August 2015 (UTC)
@Fhocutt (WMF): I think that looks good. I'm going to rearrange it to put the section about non-harassment unacceptable behavior below the list of examples of harassment.—Neil P. Quinn (talk) 17:54, 23 August 2015 (UTC)
Oh, wait. Someone else already did that.—Neil P. Quinn (talk) 17:55, 23 August 2015 (UTC)
The edit summary re-adding "rejection of patches" seems to go out of its way to point out that it's happening elsewhere. I don't know of this ever being a problem in Gerrit or Phabricator or Special:CodeReview. Why should this be included? --MZMcBride (talk) 02:35, 19 August 2015 (UTC)
Because it's a good thing to build processes around problems we have seen in similar spaces with similar dynamics and similar base populations so that we have a way of handling them if and when they happen. This question or something very likes it comes up a lot, particularly in regards to codes of conduct; "why do we need to protect X? I've never seen X happen". And the answer is that if X does happen in communities similar to ours it's hubris to believe it couldn't happen here, and we should protect against that - and that the lack of the appearance of X, when there is no process for X, can also be indicative that the lack of process caused an absence of any ability to productively surface it. Or to put it another way, a problem without reporting looks the same as no problem at all. Ironholds (talk) 19:20, 19 August 2015 (UTC)
This sounds very much like you're trying to prove a negative. --MZMcBride (talk) 02:01, 20 August 2015 (UTC)
Not really. Again, this happens very commonly in communities very like ours; I'm not trying to prove a negative, I'm trying to avoid the hubris of assuming we should not ward against things we have seen appear in similar spaces. If it was entirely a thought experiment it would be potentially problematic because then we're just adding stuff in an unfounded way, but by definition worrying about things identified in near-identical entities is not unfounded, it is very well founded. Ironholds (talk) 14:16, 20 August 2015 (UTC)
I'm a bit lost in this discussion. Are you proposing a specific change in the "Unacceptable behavior" section?--Qgil-WMF (talk) 09:03, 21 August 2015 (UTC)

Strings attached

I removed this text about trying to coerce users into apologizing through threats and intimidation. Ironholds seemed to want a discussion about it. Perhaps it's a cultural difference, but it seems/seemed pretty obvious to me that this type of behavior is inappropriate and I don't think we should be encouraging it. --MZMcBride (talk) 02:54, 19 August 2015 (UTC)

That isn't what it says. What it says is "The group may, if it chooses, attach "strings" to this request: for example, the group may ask a violator to apologize in order to retain their membership on a mailing list or their Phabricator privileges." That's not "threats or intimidation"; it's saying that in order for you to retain the privileges that you have after violating the behavioural standards that the group has, you must demonstrate that you understand that you violated these standards and that doing so was wrong. This is pretty fair, to me (I'm not sure what cultural difference there is here; yes, I'm a European, but I've also been living in the United States for quite a while now) - such a demonstration serves as evidence that misbehaviour will not occur again. It's also pretty standard; looking just at enwiki, almost every discussion around unblocks and unbans requires some assurance that the person who was sanctioned understands what they did wrong. Requiring that understanding to continue is...precisely what we do, we're just shuffling the order here. Ironholds (talk) 19:18, 19 August 2015 (UTC)
This is from the jQuery enforcement manual. I think realistically this is something that is already done in certain situations informally (and not just in tech communities); they just chose to spell it out. Without this, either it could still happen informally, or the only option is to directly ban them in a case where the string option would be considered. Mattflaschen-WMF (talk) 21:46, 19 August 2015 (UTC)
I also don't see any problem with requiring users to apologize as a condition of their remaining part of the community. The whole point of this code is to provide a mechanism for coercing toxic users to either change their behavior or leave the community. We can certainly argue about what makes a user toxic or how the mechanism should work, but it seems pretty obvious to me that a reasonable degree of coercion is the whole point.—Neil P. Quinn (talk) 22:22, 19 August 2015 (UTC)
I don't really like the strings language. I kind of feel like it reduces the value of an apology when it is so forced. Apologies should be free admissions of wrong doing. I feel like a forced apology doesn't shows that the user understands s/he violated standards, it shows the person understands that they are being required to apologize in order to continue to participate. However I think its fine for the committee to take the presence of an apology (Or any other action the offender takes to make amends/demonstrate regret) into account when deciding appropriate reprimands or to strongly suggest that somebody apologize. Bawolff (talk) 07:16, 23 August 2015 (UTC)
Demanding apology is an old antipattern. Apologies are valuable because they signal a change of beliefs (as opposed to a mere change of behavior). By making them obligatory most of that value is lost. Besides, giving a group the power to force belief changes is kind of creepy.
Asking the violator to promise that they will honor the code in the future (possibly as a condition of lifting the ban), which is the enwiki practice Ironholds was referring to, is a very different thing and entirely reasonable. Although I am not sure if there is any benefit in doing it in public. --Tgr (WMF) (talk) 08:32, 23 August 2015 (UTC)
I agree that a required apology is not a 100% sincere apology. As I said above though, I think these kinds of required apologies are common in other areas of life. That said, I don't object to removing the strings part, and changing it to something like "The committee may recommend that someone apologize, and take into account whether they do so. They also may require that someone explicitly agrees to comply with the code of conduct before unbanning them." Mattflaschen-WMF (talk) 23:30, 23 August 2015 (UTC)
This is actually not currently in the draft, but it's worth discussing whether to put something else back in (see my last suggestion). Mattflaschen-WMF (talk) 00:08, 24 August 2015 (UTC)

Trolling

I removed trolling as it seems to be problematic to define. I wouldn't want to see rickrolling to be considered a violation of this document, for example. I've also heard some people reclaim and embrace the term trolling as a positive behavior/attribute/skill. If someone wants to re-insert this, I think it first warrants discussion and perhaps a clearer definition. --MZMcBride (talk) 03:05, 19 August 2015 (UTC)

"In Internet slang, a troll (/ˈtroʊl/, /ˈtrɒl/) is a person who sows discord on the Internet by starting arguments or upsetting people, by posting inflammatory,[1] extraneous, or off-topic messages in an online community (such as a newsgroup, forum, chat room, or blog) with the deliberate intent of provoking readers into an emotional response[2] or of otherwise disrupting normal on-topic discussion.[3]". I think that firmly falls within the set of behavior we don't want to see. In addition, it is noted explicitly in the Contributor Convenant, so I think it makes more sense to place it back while the subject is being discussed. As for Rick Rolling: I think that generally is also counterproductive, and thus something we don't want in our technical spaces either. Valhallasw (talk) 08:02, 19 August 2015 (UTC)
Trolling is defined in Wikimedia terms at Manual:Glossary#T and m:What is a troll?, and in case of doubt w:Internet troll is also an interesting read. I think in most cases it is a behavior simple to recognize. "consistent and unwarranted rejection of patches" is not an equivalent of trolling but a much more narrower case, therefore I think that we should bring "trolling" back instead.--Qgil-WMF (talk) 09:50, 19 August 2015 (UTC)
Agreed, and let me say that people reclaiming trolling as "a positive behavior/attribute/skill" have no place here. Ironholds (talk) 19:09, 19 August 2015 (UTC)
I agree with Valhallasw. There was unanimous consent to start from the Contributor Covenant. While we have made changes from there, 'trolling' is one of the few things the concise Contributor Covenant addresses, which shows they view it as important. I agree it is important to forbid, and I see no reason to remove it from our versions. Rick-rolling is a prank, not trolling. While pranks can waste time (which is why I try to restrict mine to April Fool's), pranking is not the same thing as trolling. Mattflaschen-WMF (talk) 20:59, 19 August 2015 (UTC)
Thanks for re-adding it, Matt. Ironholds (talk) 14:14, 20 August 2015 (UTC)
Trolling is not defined anywhere and has never proved useful as an explicit charge to make to anyone, hence I support the removal of its mention. m:What is a troll? is a mere essay for a reason. --Nemo 06:59, 21 August 2015 (UTC)
The question is, are the behaviors identified as "trolling" already mentioned in clear terms (making the addition of "trolling" redundant) or is "trolling" covering other behaviors that are still not mentioned? I would be fine removing that single word, but only if the behaviors we want to address are well covered in the CoC. Currently we have:
  • Inappropriate or unwanted communication
  • Sustained disruption
  • Offensive, derogatory, or discriminatory comments
  • deliberate intimidation
  • derogatory comments
  • personal attacks
Anything missing?--Qgil-WMF (talk) 09:21, 21 August 2015 (UTC)

Qgil-WMF: If we remove "trolling," as I think we should, we would be left with:

The following behaviors are also unacceptable, regardless of whether they rise to the level of harassment and whether online or in person: inappropriate use of sexual language or imagery, insults, and other unprofessional conduct.

I think "unprofessional conduct" is similarly problematic as it's incredibly vague. And is "insults" needed? Are insults different from "personal attacks" or "offensive, derogatory, or discriminatory comments"? I'd be inclined to remove these three pieces (maybe moving "insults" up into a bullet, though it seems unnecessary). That would leave us with:

The following behaviors are also unacceptable, regardless of whether they rise to the level of harassment and whether online or in person: inappropriate use of sexual language or imagery.

This seems pretty awkward/weird to be in its own separate paragraph. --MZMcBride (talk) 00:45, 23 August 2015 (UTC)

Trolling used to have somewhat positive connotations back in the newsgroup era, but has that changed pretty definitively since then. Partly because its meaning changed to encompass any kind of deliberate manipulation, and to imply malicious intent; and partly because most newsgroups weren't communities in the sense the MediaWiki tech community strives to be one (they weren't about building things), so different behaviors were problematic there. Trolling, as used today, fits well into the list of non-acceptable conducts. If there are non-hypothetical persons in our community who are trying to reclaim it, that might be worth a discussion; otherwise, I wouldn't worry much about it.

Qgil: something like hostile tone maybe? A code of conduct might not be the best place to address that, though. --Tgr (WMF) (talk) 09:06, 23 August 2015 (UTC)

"Tone" was specifically raised under #Creeping bureaucracy. It could be a rationale to block anyone for writing almost anything "non-positive". There are no community agreed policies which rely on bad "tone" in order to justify blocks or other sanctions; it would be worrying if there were. -- (talk) 14:31, 23 August 2015 (UTC)
I thoroughly disagree with the assertion that it is not possible to write about a negative thing in non-hostile tone. I also don't think it differs fundamentally from WP:CIV (how much the latter gets followed is another matter). --Tgr (WMF) (talk) 18:52, 23 August 2015 (UTC)
I agree. I don't think we need a point specifically about tone. Mattflaschen-WMF (talk) 23:41, 23 August 2015 (UTC)
People have defined 'trolling' above. I completely disagree with removing it. There is a reason it's in Contributor Covenant. In both their and my experience, it's a serious problem in communities like ours (and I have seen examples of it in our community). If people really think a definition needs to be incorporated into the CoC, I'm fine with quoting the definition from Wikipedia (which Valhallasw quoted above). I think it's clear that while there may be some overlap, not all the items from that definition (e.g. "provoking readers into an emotional response") is in the list Quim quoted. I think "unprofessional conduct" should be kept; it basically means the kind of disruptive behavior that is incompatible with getting things done in a respectful way. I'm okay with removing "insults", as I think "personal attacks" is a superset of "insults". Mattflaschen-WMF (talk) 22:15, 23 August 2015 (UTC)
+1. Ironholds (talk) 14:45, 24 August 2015 (UTC)

Inappropriate or unwanted communication

"Inappropriate" was mentioned above; I agree that it does not seem very useful - it includes everything but explains nothing. There are generally three functions for the list of unacceptable behaviors: they inform the enforcers; help a concerned community member decide whether something they are about to decide or something someone just posted is acceptable or not; and tell a potential newcomer whether they can trust that the community is a safe space. "Inappropriate X" doesn't seem terribly useful for either goal. And I am not sure what unwanted even means. If it means that once someone tells you to stop communicating with them you must do comply, that is fine, but should be spelled out more explicitly. --Tgr (WMF) (talk) 09:14, 23 August 2015 (UTC)

I think there are some kinds of inappropriate messages that most reasonable people would agree are inappropriate and should not be sent. As far as "unwanted communication", I've clarified that similarly to how we did for unwanted photography. Mattflaschen-WMF (talk) 23:35, 23 August 2015 (UTC)
I think simplicity is more effective. Somehow we have grown an own list that is far more dense and extensive than the original Contributor Covenant, and I'm not seeing a good, practical justification for that. We already have several instances of inappropriate / unwanted communication. That first point could be removed without creating any new gap for actual harassment.--Qgil-WMF (talk) 10:56, 24 August 2015 (UTC)
Specificity, as has been covered repeatedly in this discussion, is a pretty good way of ensuring there isn't wiggle room or ambiguity. I don't feel we should be treating the Contributor Covenant as the baseline here except in the sense of 'the minimum acceptable`. It's widely used because it's not objectionable. That makes it a good template; it doesn't mean we should pin ourselves to the belief that it is ineffable. Ironholds (talk) 16:41, 24 August 2015 (UTC)
@Qgil-WMF: I don't think it's too long (especially if we just consider the length of the sections prior to Reporting and Enforcement). There are advantages to being specific. It helps avoid gamesmanship and wikilawyering. One thing "Inappropriate or unwanted [...] communication" may address that the other points don't as well is written harassment. This might be written sexual harassment, or just some other form of persistent communication you don't want to receive (and ask not be sent to you). Mattflaschen-WMF (talk) 02:28, 26 August 2015 (UTC)
Actually, gamesmanship and wikilawyering might be helped by lengthy policies inviting to have lengthy discussions driving most people away (an actual problem in Wikimedia). If the principles are clear and the committee is trusted, then this process will be accessible and strong. Now the text of the Principles proposed is shorter, but I bet we are offering the same actual coverage as before. "Inappropriate or unwanted communication" has been connected to "following, or any form of stalking", and in that context I think its function is clearer.--Qgil-WMF (talk) 07:39, 26 August 2015 (UTC)
@Qgil-WMF: : Much of the added list comes from policies that have been working in WMF spaces so far: the Grants Friendly Space Expectations and the Friendly Space Policy. Also, what Ironholds said. --Fhocutt (WMF) (talk) 17:26, 24 August 2015 (UTC)
One thing is being specific, another thing is having overlapping concepts spread in different points, making the whole list more dense and confusing than needed. I have just posted #Reorganization of types of harassment, a simpler proposal that doesn't lose specificity, that may address the problem exposed here and in the discussion about trolling.--Qgil-WMF (talk) 06:10, 25 August 2015 (UTC)

Substantive v Procedural

The draft is a confusing mix of Substantive law and Procedural law.

  • Substantive law declares which types of conduct lead to which types of penalty;
  • Procedural law defines how cases are handled.

Please place the procedural law into a separate paragraph. That paragraph should define:

  • the judicial body (e.g. committee membership and powers);
  • how cases are to be filed (e.g. identify the parties, state the facts, state which substantive law was breached, request remedy);
  • the rules of evidence (e.g. original documents and testimony is admissible; hear-say is inadmissible);
  • how cases are adjudicated (e.g. read charges, determine facts, determine applicable substantive law, decide penalty);
  • how decisions are announced (e.g. three brief paragraphs: findings of fact, findings of law, and penalty).

Procedural law is about the judicial system. If the work load grows, it may become necessary to have many such committees. Procedural law is our guarantee that the substantive law is applied in a uniform manner across many cases and many committees.

Uniform handling of cases is an important component of fairness. Moreover, public perception of uniform handling of cases contributes to public perception of fairness. Wp mirror (talk) 03:09, 19 August 2015 (UTC)

Agreed they should be split into different sections but they should be considered part of the same document, jurisprudence aside. This is not intended to be a legal system and should not be read as a legal document; as you say, fairness is important, and uniform handling and transparency are important parts of that fairness, but speaking as a former lawyer another element of fairness is to ensure that justice is efficient. Replicating a legal system down to the level of specifying the determination of "applicable substantive law" and every single possible type of evidence that is and is not acceptable does not necessarily help with this. Ironholds (talk) 19:38, 19 August 2015 (UTC)
An example might help. Procedural law, for many not-for-profit organizations, includes a reference to RONR 10th ed, Chap XX Disciplinary Procedures. The draft contains no such reference. Procedural law for the Conduct Committee should be gathered into one or more paragraphs, and thought through. Otherwise, committee members will find themselves having to improvise when they receive their first few cases. Improvisation leads to an aggrieved party claiming that committee members act in an arbitrary and capricious manner, which in turn injures the public perception of fairness and shrinks to pool of volunteers willing to serve on the committee. Wp mirror (talk) 05:29, 20 August 2015 (UTC)
In short, should we create a section "Code of Conduct Committee" and move there the details about its creation, membership, second level...?--Qgil-WMF (talk) 09:45, 20 August 2015 (UTC)
Yes, I think it's fine to create separate (sub)sections for that. Mattflaschen-WMF (talk) 02:38, 21 August 2015 (UTC)
I have never seen a reference to Robert's Rules (which are incredibly US-centric) in any code of conduct for this sort of community. Could you point me to an example of a code of conduct for a technical or online community that contains such a reference? Quim: yes, I am reading this as a request to create a dedicated section about the entity tasked with enforcing it, and endorse that request (although Code of Conduct Committee may not be the best name, since it leaves ambiguous whether that is an enforcement body or an amending body or or or). Ironholds (talk) 14:13, 20 August 2015 (UTC)
What part of the substantive six-step process do you feel is unclear? I agree the committee may have to choose certain non-substantive manners themselves (e.g. do they meet by private chat room, or telephone, who takes notes?) but the substantive matters should be addressed here in the policy. Mattflaschen-WMF (talk) 00:21, 21 August 2015 (UTC)

@Mattflaschen-WMF: Would anyone object to my starting a page called "Conduct Committee Charter/Draft". The idea is this: There should be two pages:

  • Code of conduct for technical spaces/Draft - contains substantive law (definitions of unacceptable behavior, penalties);
  • Conduct Committee Charter/Draft - contains procedural law (committee structure, membership, responsibilities, procedures).

I would be happy to provide a first draft to get the conversation going. The outline would look like this:

  • Purpose of Conduct Committee
  • Membership and selection
  • Responsibilities
  • Procedures and process

Wp mirror (talk) 00:28, 21 August 2015 (UTC)

They should not be separate pages, they should be the same page, as I thought we'd all agreed on. I am loathe to set more than the high-level elements of the appeals process due to the potential (in fact, the certainty) that we would get bogged down in that debate. The committee should determine, within the restrictions of the code of conduct, their own policy (and transparently document it). Ironholds (talk) 00:58, 21 August 2015 (UTC)
I agree with Ironholds on both points. The committee will quickly gain a sense of what is effective in practice; let's provide a reasonable blueprint and clear goals here and let them do their job. --Fhocutt (WMF) (talk) 01:44, 21 August 2015 (UTC)
Yes, I do object to drafting a new charter from scratch. There are already important procedural aspects in the main document. The key procedural questions should be described in the Code, but I do not support drafting our own very-detailed procedure in a vacuum. Many of the procedural elements (including resolutions) are based on https://github.com/jquery/jquery.org/blob/master/pages/conduct/reporting.md and https://github.com/jquery/jquery.org/blob/master/pages/conduct/enforcement-manual.md . This in turn is based on https://www.djangoproject.com/conduct/reporting/ and https://www.djangoproject.com/conduct/enforcement-manual/ . The key insight here is that we are benefiting from the procedural experience of real organizations (Django, and the others they adapted from, such as PyCon) that have dealt with these problems. Making our own elaborate procedural system based on Roberts Rules of Order, but without practical experience with dealing with this, will lead to an unwieldy procedure that does not solve the problem.
As already noted, I expect the committee to answer some non-substantive procedural questions on their own. It is also possible they will ask for some substantive procedural changes, in which case they may request to amend the CoC. But in either case, we'll be benefiting from practical experience in this kind of committee, which we can't if we draft our own based on Robert's Rules of Order. Mattflaschen-WMF (talk) 03:44, 21 August 2015 (UTC)

Physical contact

MzMcBride removed the parenthetical in "Inappropriate or unwanted attention, touching, or physical contact (sexual or otherwise)" with the rationale that it felt "awkward and unnecessary". To kick off a discussion about that:

Sexual versus non-sexual touching has different levels of acceptability within western society (speaking very broadly, there). Sexual contact is seen as obviously inappropriate for professional spaces, and non-sexual totally fine if both parties are comfortable with it. This split in characterisation should be called out when we're talking about how to handle unwanted contact. Ironholds (talk) 19:30, 19 August 2015 (UTC)

I think the key point is that unwanted or inappropriate touching is prohibited either way (sexual or otherwise). I agree it's worth calling out, since sexual harassment is one of the problems this is trying to address. I've put it back. Mattflaschen-WMF (talk) 21:27, 19 August 2015 (UTC)
Which split in characterization should be called out? I don't follow what you're saying. I also still don't see the need to parenthetically clarify that physical contact can be "sexual or otherwise." --MZMcBride (talk) 02:16, 20 August 2015 (UTC)

This area seems more than slightly over-egged, possibly this is a cultural gap of some sort between Europe and the US. If I were at a lunch at a Wikimedia sponsored hackerthon, and a fellow volunteer started choking on their chicken sandwich, I would like to avoid feeling so awkward about potential embarrassing claims of inappropriate touching, that I never tried to slap their back or attempt abdominal thrusts to clear their airways before they lose conciousness. At the moment I'm thinking that I would step back and wait until someone else helped out, especially if the person choking were half my age (which is quite likely). -- (talk) 09:50, 20 August 2015 (UTC)

In the event that somebody was choking to death would your read genuinely be that the Heimlich was unwanted? Ironholds (talk) 14:06, 20 August 2015 (UTC)
I think this is unhelpful hypothetical argument. I'll respond to this one direct question, but I prefer to avoid getting into replying to more of this type.
The way the draft is being extended in ways that only relate to thought experiments, rather than case history for our community, is of concern and especially the emphasis on "touching" as a reason to apply this policy. My feelings on this are from the last few years of targeted sexual and sexuality related abuse/vandalism on and off the Wikimedia projects (one of these attacks was on my Commons talk page in the last 24 hours, and has been deleted from the page history). This past does make me concerned about the risks of socializing at physical Wikimedia events, and has made me concerned about practicalities of things like sharing rooms when I attended Wikimedia events.
If I take your comment literally, then there is plenty of precedent and I note that preferred description is "abdominal thrusts" as other terms can be confusing or controversial depending on what you read. -- (talk) 15:11, 20 August 2015 (UTC)
I concur the choking example was unhelpful and I'm glad we're in agreement on that. You seem to be making a false distinction, here; that there are "thought experiments" and "things we have seen in our community" and nothing in-between. What we are talking about is not thought-experiments that could never happen, or could happen but never do happen; we are talking about things that absolutely happen in communities incredibly similar to ours in terms of focus, demographics and process. It is hubris for us to take the position that because instances of this have not been reported - in an environment similar to those where it has, and an environment lacking an existing enforcement mechanism in many ways - they cannot, or will not, happen.
I am deeply sorry for your past experiences of harassment in this community, along those axes or along any other axes. Ironholds (talk) 16:43, 20 August 2015 (UTC)
With regard to "axes", sarcastic apologies that are deliberate personal attacks are just as unhelpful. We should all expect better behaviour of WMF employees if the Wikimedia community is to provide them with special trust and authority. -- (talk) 16:56, 20 August 2015 (UTC)
That was not sarcastic, nor do I see where it was a personal attack. I was genuinely saying that I am sorry for your experiences. I apologise if what I wrote was badly written or ambiguous and so came off as an attack in any way; I will endeavour to be more precise before hitting save. Ironholds (talk) 18:05, 20 August 2015 (UTC)
I've now realised the ambiguity might be around "axes"; I meant it in the sense of "the plural of axis" not "the plural of axe". Apologies for the ambiguity :(. All data visualisation and no play makes.... Ironholds (talk) 14:41, 21 August 2015 (UTC)
@: The precedent you cited is from Weekly World News, a fictional tabloid publication. I'm sorry about any harassment you've received on any of the projects. This draft code of conduct does address communication ("Inappropriate or unwanted communication", "Offensive, derogatory, or discriminatory comments", etc.), not just touching, in the covered spaces. Mattflaschen-WMF (talk) 00:09, 21 August 2015 (UTC)


Canvassing

By the way, this whole discussion seems dominated from the start by a cherry-picked pre-determined very small subset of the community, which convened in external places and then started this concerted effort. In our wiki culture, this smells of so-called canvassing, which by definition makes a discussion and decision invalid and void. --Nemo 06:46, 21 August 2015 (UTC)

This proposal, just like most proposals in our community, was started publicly by some people who cared about this topic, and others equally interested have been involved since then. Nobody has been sherry-picking anybody, and nothing has been pre-determined. Trust me, I have been following this process and its collateral discussions and initiatives since phab:T87773#998422 (2015-01-28), both in public spaces and in the casual private conversations where I have been CCed.--Qgil-WMF (talk) 08:05, 21 August 2015 (UTC)
I learned of it from wikitech-l (2015-08-07) which is one of the technical spaces that would be covered by the proposed Code of Conduct. If anyone is aware of a technical space not notified, we should remedy that now. Wp mirror (talk)
Basically what Matt said; I heard about this from the Wikitech thread and to my knowledge it started on a phab task and with a public meeting at Wikimania. That's about as far from canvassing as you could get. Ironholds (talk) 14:35, 21 August 2015 (UTC)
I learned about this from the same Wikitech thread as Ironholds and Wp mirror.—Neil P. Quinn (talk) 05:24, 22 August 2015 (UTC)
I learned about this draft by personal email from a deeply concerned long term technical contributor. They have not contributed here themselves, from my understanding of their history, the most likely reason being that they do not want to be seen to be 'non-positive' about any WMF driven initiative, and with weaker English skills their voice would be lost in the wiki-lawyering. Without the email, I would never have known that this draft had been created. -- (talk) 08:21, 22 August 2015 (UTC)
I don't think I would say canvassing - but it certainly does seem as if it is being pushed by a rather small group of interested people, and being pushed rather hard. I am somewhat concerned in how the discussion doesn't seem to have all that many voices among the long term mediawiki/core developers (Since that is one of the main groups this document plans to regulate), but there is a long thread on wikitech-l, so its not like the relavent parties don't know about it. If the people commenting are the people interested, I guess that is that. Bawolff (talk) 06:48, 23 August 2015 (UTC)
As other people have noted, this work started publicly on Phabricator, and I've sent multiple notifications to wikitech-l. Architecture committee/2015-08-12 indicates the architecture committee members (i.e. long-term contributors) are aware of it; I would expect anyway they're aware from wikitech-l. If you feel it should be sent out to another public forum, please do so. Mattflaschen-WMF (talk) 20:57, 23 August 2015 (UTC)


Governance

jQuery's Code of Conduct Committee is a creature of the jQuery Foundation's Board of Directors:

  • the board appoints and reviews the committee members;
  • the committee is empowered to speak on the foundation's behalf to contact witnesses and to stop ongoing situations;
  • the committee reports the outcome of each case to the board;
  • deadlocked cases are escalated to the board; and
  • public statements are issued by the board, never the committee.

This is documented in their Enforcement Manual.

  • appeals go to the jQuery Foundation's President and Executive Director.

This is documented in their Reporting Guide.

No equivalent language appears in the draft Code of Conduct under consideration here. These are issues of governance; and they need to be addressed. Is there any reason why the proposed Conduct Committee should not be a creature of the WMF Board of Trustees? Wp mirror (talk) 17:59, 21 August 2015 (UTC)

Time, existing org structure, and lack of technical background, mostly. The jQuery Foundation is very different from the WMF and the two organizations and their boards focus on different tasks. This proposed committee's purpose (to promote and maintain a healthy technical community) is well within the Engineering Community Team's purview and skillset and I think it is a more natural fit. --Fhocutt (WMF) (talk) 00:38, 22 August 2015 (UTC)
That seems unsatisfactory. Members of WMF technical staff will be actively working in spaces where this code is in force, and subject to its provisions. It cannot be right for the ECT to sit in judgement on, or take appeals from, its own members or fellow-worker -- the clear failure of natural justice implied would completely undermine the credibility, acceptability and authority of the Code in all its applications, not just those that might involve a member of the WMF engineering staff. The authority of the Code must surely emanate from the Board, which is the ultimate authority and embodies the community consensus through its elective structure. It seems unlikely that there will be large amounts of business for them to transact and if it prove burdensome, I am sure the Board is fully capable of managing its own business either by delegation ad hoc or to a standing subcommittee. Rogol Domedonfors (talk) 18:53, 23 August 2015 (UTC)
Presumably the WMF's HR department should also not be involved in WMF employee behaviour, nor their lawyers, nor their managers, since they're all "fellow workers", and the committee should not contain any technical people since then the technical contributors they're tasked with checking the behaviour of will be "fellow workers" too. There are conflict of interest and recusal provisions practically by default for entities like this. The Board does a vast amount of work already and is not a particularly technical body; it also has little to no exposure to work within the technical spaces. Your proposal is that to avoid conflicts of interest we abstract the task away so far it lands on the plate of a group of people with absolutely no expertise or lived experiences that pertain to the space-specific problems. Ironholds (talk) 14:43, 24 August 2015 (UTC)
I am sure that the trained professionals in the HR and Legal departments are fully capable of handling those issues. That is of course of marginal relevance to this discussion and I presume you knew that when you dragged it in.. My proposal -- that is, what I actaully wrote rather than your mis-statement of it -- is based on the belief that the Board has the authority, the independence, the community support, that it is fully capable of understanding the issues of human interaction, fully capable of managing or delegating its own business and fully capable of obtaining technical advice should it see the need to do so. Apparently you disagree and it would be interesting to know why? It seems that you find independence a disadvantage in dealing with these governance issues -- I would see it as a positive advantage. Rogol Domedonfors (talk) 08:39, 25 August 2015 (UTC)
I don't see any problem in asking the Board for their opinion once this draft is more consolidated. If they say "Yes, we want to be the ones enforcing this Code of Conduct directly", I don't see any strong reason not to agree with them. However, I find this possibility unlikely for practical reasons, and we'd rather have an alternative proposal where the Board is either not in the picture or basically nominally, with their duties delegated to an executive body, aka a committee. In any case, the first step is to consolidate this draft, which we are doing at #Proposing Intro + Principles + Unacceptable behavior and related sections.--Qgil-WMF (talk) 09:41, 25 August 2015 (UTC)
I don't have any issue with independence; I have a problem with independence to the point of lacking context, and concerns about the time the board has available. But in any case, I endorse Quim's comment on this. Ironholds (talk) 14:40, 25 August 2015 (UTC)
I think there is in fact language addressing the same questions. It's just that the current draft has different answers. The draft is quite clear about who speaks (e.g. "A private reprimand from the committee", "A public reprimand. In this case, the group chair will deliver that reprimand", etc.), and it's also clear about the appeals process ("To appeal a decision of the committee, or if you have concerns about how it was resolved, contact the Engineering Community Team at ect@wikimedia.org and they will review the case"). The main question not addressed is how the committee will be formed. There is already active discussion about that.
I think ECT has better understanding of day-to-day life in the technical community than the Board of Trustees does, and is thus better suited as the appeals body. Mattflaschen-WMF (talk) 22:47, 23 August 2015 (UTC)


Outing

Hi. Re: this edit, "outing" actually has a different meaning in the context of Wikimedia wikis (cf. w:en:WP:OUTING). --MZMcBride (talk) 00:29, 23 August 2015 (UTC)

I agree. Without looking at the link, I would assume the other definition was meant in this context. Bawolff (talk) 06:23, 23 August 2015 (UTC)
Agreed. I've pointed the link to the enwiki project page you linked.—Neil P. Quinn (talk) 18:05, 23 August 2015 (UTC)
The original Contributore Covenant says "Publishing other's private information, such as physical or electronic addresses, without explicit permission". This is plain English, and very clear. I propose to go back to this original sentence. "Outing" and "doxing" are not part of everyday's vocabulary. If you prefer, we can add the concept of "person's identity": "Publishing a person's identity or other private information, such as physical or electronic addresses, without explicit permission".--Qgil-WMF (talk) 10:46, 24 August 2015 (UTC)
The version of Contributor Covenant we based this on does not have that text (see revision link in See also). That said, it seems fine to use more plain language for this. Mattflaschen-WMF (talk) 02:20, 26 August 2015 (UTC)
It should be amended as you suggested, since unlike some communities, in ours name/identity is often private, which is not addressed in your first quote. Mattflaschen-WMF (talk) 02:22, 26 August 2015 (UTC)
  Done taking the wording proposed at #Reorganization of types of harassment since it is directly based on the previous sentence, just removing the very specialized terms.--Qgil-WMF (talk) 06:12, 26 August 2015 (UTC)


Remove "Principles" section?

The "Principles" section as currently written seems both incorrect and pointless. There's a reason why the coding conventions pages, for instance, don't say "As Wikimedia developers, we all believe that tabs should be used instead of spaces." If there are rules, fine; but there's no point pretending there's unanimity behind them.

The first sentence of the section is simply incorrect: "As members of Wikimedia's technical community, we work together to build technology that makes free knowledge available to humanity." There are plenty of MediaWiki extension developers, myself included, who have never worked on code used on any of the major Wikimedia sites; we thus make no real contribution to free knowledge for humanity. (Why this sentence belongs there, even if true, I don't know. If the goals were less lofty, would harassment be okay?)

The second two sentences, starting with "We welcome" and "We pledge", are actually similarly nonsensical. Did everyone pledge? (Did anyone pledge?) What does it mean to pledge? Do you have to pledge repeatedly, or only once?

I don't know why you need a set of principles to explain rules in the first place. It feels like this whole section could just be removed. Yaron Koren (talk) 18:44, 24 August 2015 (UTC)

I disagree that there is no point to this section although I accept that you don't see one. The point of this is the same as the point of any preamble anywhere; to provide a context within which the document can exist and be interpreted. So that people reading the code of conduct can understand not only what specific activities are proscribed but the principles under which the community is organised.
As for the 'there's no unanimity behind them' or 'who pleged?' - that is about the principles, not the individual rules. Excepting the working together section, do you disagree that the community should be a respectful and harassment-free experience for everyone, say? Ironholds (talk) 04:34, 25 August 2015 (UTC)
I think Yaron's point, is that pledging is usually defined as an active action. Almost akin to signing something. Regardless of whether everyone agrees with the statements to be pledged, its not true to say that everyone has pledged it, unless they've actually pledged those principles, which they haven't, and there is no plan to make everybody pledge it. A policy we all agree with, is different from a policy we have all pledged to uphold. Bawolff (talk) 05:30, 25 August 2015 (UTC)
For what is worth, this section is basically an adaptation of the first paragraphs of the Contributor Covenant this Code of Conduct is based upon. "Pledge" is being used there. Today nobody has pledged anything, but the approval of this Coc implies that the Wikimedia Tech community endorses it. To me this reads as a linguistic detail, and in general I think that deviations from the original Contributor Covenant benefit from a strong justification. As per MediaWiki-not-Wikimedia contributors, anybody participating in the Wikimedia tech infrastructure is considered a Wikimedia tech contributor, and does contribute in a way or another to Wikimedia's mission. So yes, it is a preamble, it might sound a bit redundant for those knowing the details, but it is informative and usefl to set everybody in the same page.--Qgil-WMF (talk) 06:21, 25 August 2015 (UTC)
Ironholds - I agree that respect is good and harassment is bad. Now, if you can get everyone who's ever contributed code to a Wikimedia project to agree with that, you'd have a stronger case...
Qgil - I simply don't see how someone who writes, say, a Google Ads MediaWiki extension is contributing to free knowledge for humanity. Right now the wording makes it seem like such people don't even count; is that really "welcoming"?
Seriously, though - instead of "We pledge to make participation in Wikimedia technical projects...", what about "Participation in Wikimedia technical projects should be..."? Yaron Koren (talk) 14:10, 25 August 2015 (UTC)
If there are people who can't agree on that they shouldn't be members of our technical community, full stop. I have no issue with the people who are concerned by individual clauses and the edge cases they might introduce, but if you do not believe that, as you put it, respect is good and harassment is bad you have no place here. I don't have a problem with your rewording. Ironholds (talk) 14:41, 25 August 2015 (UTC)
Well, that's refreshing. People have been wasting time arguing about warning levels, arbitration committees and so forth, when it turns out that all we needed all along is just an immediate lifetime ban. Yaron Koren (talk) 15:10, 25 August 2015 (UTC)
I really don't want to spend my energy with us digging ever-deeper into this, so I'm going to back off at this point, but I really don't see how you concluded that a comment consisting entirely of deliberate facetiousness was helpful. Ironholds (talk) 18:08, 25 August 2015 (UTC)
Yaron's valid point refers to the part of the community focusing on MediaWiki-not-Wikimedia. It's a topic that we are considering in other areas, and can be considered here as well. The incidence on the mission and purpose of Wikimedia is not essential in this Code of Conduct. In the original Contributors Covenant, the "pledge" is used in a slightly different way. All in all, here I don't see strong reasons to depart from the original writing, so I will edit the Principles section proposing a writing closer to the original. Feel free to revert if you prefer to discuss further.--Qgil-WMF (talk) 20:51, 25 August 2015 (UTC)
I think it's better now, yes. Yaron Koren (talk) 22:42, 25 August 2015 (UTC)


Reorganization of types of harassment

The list of types of harassment has grown to a point where I don't think it is serving its original purpose as good as it could. Having two levels (a bullet list and an extra sentence) doesn't help. Having similar concepts in different points doesn't help either. We can be just as specific with a clearer organization and self-explanatory descriptions. Here is an attempt:

Harassment and other types of inappropriate behavior are unacceptable in all public and private Wikimedia technical spaces. Examples include but are not limited to:
  • Personal attacks, violence, threats, deliberate intimidation.
  • Offensive, derogatory, or discriminatory comments.
  • Inappropriate use of sexual language or imagery.
  • Unwanted attention, touching, or physical contact (sexual or otherwise).
  • Unwanted communication, following, or any form of stalking.
  • Unwanted photography or recording.
  • Disclosure of a person's identity or other private information without their consent.
  • Trolling through sustained disruption, interruption, or blocking of community collaboration.
  • Other unethical or unprofessional conduct.
Project administrators and maintainers have the right and responsibility to...

What do you think?--Qgil-WMF (talk) 06:08, 25 August 2015 (UTC)

They're in different sections because some of them are inappropriate but not actively harassing. 'inappropriate use of sexual language or imagery' is grossly inappropriate and should not be tolerated but I wouldn't describe it as harassment necessarily. You've also categorised anything unprofessional as harassment, which, again, is not always the case. Ironholds (talk) 06:17, 25 August 2015 (UTC)
I would also consider some forms of trolling to not be "harrasment" (but still problematic). Bawolff (talk) 06:18, 25 August 2015 (UTC)
Fine, but the goal of this CoC is not to define Harassment as in w:Harassment, but to identify types of "unacceptable behavior" in our community. The distinction between "technically harassment" and "other" is superfluous here. I have fine tuned the description.--Qgil-WMF (talk) 06:27, 25 August 2015 (UTC)
@Qgil-WMF: Some of the changes seem okay. Others I disagree with.
  • I strongly disagree with only forbidding certain forms of trolling, which I think the new wording does. The Contributor Covenant forbids all forms. I don't object to adding a parenthetical definition of trolling, but I also don't believe that's genuinely necessary. If you want to merge in the others (from Sustained disruption), it could be done with "Trolling, for example by" (I'm not sure those are 100% the same as the definition of trolling, but it's probably close enough).
  • Your list keeps "unwanted communication" (albeit moved, which is fine), but removes "inappropriate [...] communication". This is somewhat hard to define, but basically I think of creepy, harassing, or upsetting communication (especially private communication) that is not appropriate in this setting. I would prefer to put that back.
  • No problem with shortening "Offensive, derogatory, or discriminatory comments"; it should be obvious it includes offensive comments related to the listed characteristics.
  • "threats" should be changed back to "threats of violence". If someone threatens to stop editing Wikipedia, that should not fall under this.
  • Would prefer to put back "Inappropriate or" before "Unwanted attention". Similarly, it is possible for touching to be clearly inappropriate without someone explicitly telling you it's unwanted.
  • The definition of Unwanted photography or recording was put in response to feedback, but if most people don't have a problem with this wording it could be kept simpler.
  • Personal attacks might now be ambiguous. We have to forbid both verbal and physical personal attacks (physical is handled by violence, though), but a reader might now think it only refers to physical. Maybe clarify it.
Other than that the changes seem alright. Mattflaschen-WMF (talk) 02:56, 26 August 2015 (UTC)
Take a look to the current version. I think I have addressed your concerns. I have left the "Inappropriate or unwanted" pairs, although I still think "Unwanted" alone is clearer for everybody and more straightforward to act upon. In these sentences "unwanted" clearly implies "inappropriate". The "or" conjunction opens the possibility to deal with "inappropriate but not unwanted" behavior, which might be a can of worms. When not unwanted, what is appropriate/inappropriate differs a lot between individuals and their social contexts. In order to consider a behavior unwanted, we don't need "someone explicitly telling you it's unwanted". Social norms exist that define the lines of the unwanted, which are the same lines that define socially appropriate vs inappropriate. Those lines are fuzzy across cultures and individuals, but adding "inappropriate" to "unwanted" in our CoC does not solve that fuzziness either.--Qgil-WMF (talk) 06:57, 26 August 2015 (UTC)
@Qgil-WMF: I think the new version is okay, as long as we clearly understand that personal attacks includes verbal and written personal attacks, such as insults. Mattflaschen-WMF (talk) 23:19, 27 August 2015 (UTC)


Right to appeal

The right to appeal has been mentioned in several places. As a general principle, of course anybody being accused of breaching the CoC must have the right to appeal. The first ones having to excel at Conduct are the ones using it to file a complaint and the ones using it to enforce it on someone. The exact implementation of the appeal process can be defined only after the processes for starting and handling a complaint has been defined, though. For instance, complaints filed privately probably will have an appeal process that is equally private, unless one of the parts wants to bring the issue to the public. Let's agree first on how to file a complaint and how to handle it?

Let me add that the root of the questions about an appeal process seem to be based on the assumption or fear that this CoC and its enforcement will be authoritative and unfair by nature. If this is the concern, then let's focus on this concern in the first place. This CoC and its application in the Wikimedia technical spaces can only become a reality if the Wikimedia technical community embraces it and maintains it. If there is anything suspicious and unfair in this CoC, it will not be approved, it will not become a policy.--Qgil-WMF (talk) 07:25, 14 August 2015 (UTC)

(((moved from "Enforcement in new draft")))@Fhocutt (WMF): Also, "Only permanent resolutions (such as bans) may be appealed" (proposal in the current draft) should be clarified. Is it intended that only permanent actions (e.g. lifetime ban) can be appealed, or any ban (possibly temporary)? This should also clarify how the reporter's appeal rights are (un)affected. Mattflaschen-WMF (talk) 01:31, 18 August 2015 (UTC)
It's intended that only permanent actions can be appealed, but that the reporter's appeal/feedback rights are unaffected. I'm not terribly attached to this; I'd also be ok with something like "actions with effects that last for longer than three months" as well. The things I'd like to see balanced are not wasting the committee's time with specious appeals (such that the second step to any given action taken becomes "deal with the inevitable appeal") and allowing the flexibility to deal with genuine mistakes, particularly cases where the violator is using the CoC enforcement mechanisms as a way to further harassment of their target and the committee does not initially recognize that. --Fhocutt (WMF) (talk) 21:42, 18 August 2015 (UTC)
Okay, I think three months is a good compromise. I've added that. Mattflaschen-WMF (talk) 20:44, 19 August 2015 (UTC)
I still think this sounds odd: "Only resolutions (such as bans) that last 3 months or longer may be appealed by the reported offender." I think everybody should have the right to appeal, and the Committee should have the tools to avoid that this right is being abused in bad faith. For instance: "Resolutions may be appealed. For simple cases, the committee may decide to start the enforcement during the appealing process to avoid an artificial obstruction to the process. In more complex cases implying a ban of three months or more, the enforcement must wait until the appeal has been resolved."--Qgil-WMF (talk) 09:24, 20 August 2015 (UTC)
It feels like something is missing in the current draft -- notifying or talking to the reported offender. If I'm reading this correctly, it looks like the Code of Conduct Committee reviews the report and makes a decision, and the only time the reported offender is mentioned is the line about being able to appeal a 3+ month long ban. Sometimes the evidence is entirely public and easy to corroborate, and sometimes it's not. When it's not, you probably want to talk to the person and see what they have to say about it. Maybe that's obvious and doesn't need to be in the policy? DannyH (WMF) (talk) 00:22, 21 August 2015 (UTC)
I agree. However, it has to be done carefully. You don't want a scenario like:
  1. Someone feels they are being harassed, and reports it.
  2. The Committee contacts the alleged offender to get their side of the story, naming the reporter (who did not expect to be named).
  3. The Committee ends up taking only minor action (or none at all).
  4. The offender retaliates against the reporter for the report.
The jQuery CoC is ambiguous on this front. The Reporting page says, "All reports will be kept confidential. In some cases we may determine that a public statement will need to be made. If that's the case, the identities of all victims and reporters will remain confidential unless those individuals instruct us otherwise.", but the Enforcement Manual says, "The committee is empowered to act on the jQuery Foundation's behalf in contacting any individuals involved to get a more complete account of events." Contacting those individuals could itself be a breach of confidentiality. I added a sentence that tries to balance these concerns (needing the facts and avoiding revealing information against the reporter's wishes). Mattflaschen-WMF (talk) 01:26, 21 August 2015 (UTC)
@Qgil-WMF: Even if enforcement begins during the appeal process, your proposal does not do anything to deter people from appealing every single case (no matter how minor the penalty). We have to consider ECT's time. Mattflaschen-WMF (talk) 01:19, 21 August 2015 (UTC)
ECT's time is a factor I'm considering, trust me. I worry more about people complaining for having no right to appeal than about people trying to game the process. It is likely that the latter will put themselves in evidence with little community support. As for the former... they have a chance to drag more time and energy from all of us and, who knows, maybe even for a good reason because everybody can make mistakes, a committee too. (Note: I'd rather leave this discussion about appealing later, as proposed at #Next steps).--Qgil-WMF (talk) 08:47, 21 August 2015 (UTC)
Matt -- I agree with the need to strike a balance between involving the reported offender and not violating the reporter's confidentiality. That's a good point, and I think your changes to that section make a lot of sense. DannyH (WMF) (talk) 21:10, 21 August 2015 (UTC)
  • The wording is unclear as to who has the right to appeal -- who is the "you" in "if you have concerns"? Possibilities include anyone sanctioned in the case, any party to the case, anyone involved in any way at any stage, or anyone at all. Which is it to be? Rogol Domedonfors (talk) 20:52, 25 August 2015 (UTC)
    I think it's "anyone at all". But this should not be used as a back-door appeal (by either offender or reporter). It should only be to notify them of opinions, e.g. "I think the committee has developed a pattern of being too lax; this case is an example". Also note that under the current draft, either offender or reporter can ask for reconsideration ("After being notified of the outcome, the reporter or alleged offender may raise objections to the resolution. These will be considered by the committee."), but only offender can appeal to the separate level, and only under restricted circumstances. Mattflaschen-WMF (talk) 03:25, 26 August 2015 (UTC)
Then "you" is the wrong term, and should be in a separate sentence, reading "In addition, any member of the community may raise concerns about a case ...". The wording will still not explicitly forbid it being used as a second appeal. I also note that it is at least implicit, and perhaps needs to be explicit, that only a party sanctioned may appeal. Is it clear that we do not wish an aggrieved party to appeal on the grounds that their complaint has been dismissed or that sanctions are too light? Rogol Domedonfors (talk) 06:59, 26 August 2015 (UTC)
I've attempted to clarify this, partly based on this feedback. Mattflaschen-WMF (talk) 00:09, 28 August 2015 (UTC)
  • Is a reprimand in a permanent form a penalty that lasts more than three months? Rogol Domedonfors (talk) 20:52, 25 August 2015 (UTC)
    My interpretation was that reprimands are not appealable (but you could still ask the committee for re-consideration). I can see how this is a relevant question for public reprimands. Mattflaschen-WMF (talk) 03:25, 26 August 2015 (UTC)
I would suggest that there needs to be the possibility of an appeal against a reprimand which is public and delivered in a way which forms part of a permanent record. Rogol Domedonfors (talk) 06:51, 26 August 2015 (UTC)
  • The grounds of appeal are not limited in any way. That may be right, but it is a choice. Is there any appetite for restricting grounds of appeal, and if not,, itmight be helpful to spell out that an appeal may be made on any of the grounds that procedure was not correctly followed, that the decision was wrong on the factgs or that the penalty was disproportionate. Rogol Domedonfors (talk) 07:04, 26 August 2015 (UTC)
    I don't see any need to restrict the grounds, but if someone does, they can suggest which grounds should not be allowed. I would guess pretty much everyone eligible to appeal will do so, but the 3-month minimum means minor penalties won't go through a time-wasting appeal process. Mattflaschen-WMF (talk) 00:13, 28 August 2015 (UTC)


Membership of the committee and ECT's role

The CoC doesn't explain how the committee is formed and how are their members renewed. Following with Wp mirror's comment on Substantive v Procedural (thank you, I learned something), I'm not sure whether such information should be included in the CoC itself or in an attached document, but we need to define it.

Then, as ECT member I would like to understand what is the role the community wants us to have here. Especially when it comes to escalations, public statements and very ugly cases in general, I think it is useful to have a speaker paid for doing their job, saving some stress to those volunteering in the committee. However, I don't see the need of ECT to be involved in the regular work of the committee. If they would want our help, they could simply "escalate", as defined by the CoC. I think having a committee of equal members chosen through the same process by their own merits would give this team more credibility, independence, and strength.--Qgil-WMF (talk) 10:27, 19 August 2015 (UTC)

Why is there a presumption that the appeal body must be the ECT? An elected group such as Stewards or Oversighters, positions of trust open to both unpaid volunteers and appointed WMF employees, would be in-line with putting the volunteer at the centre. -- (talk) 16:07, 19 August 2015 (UTC)
Neither the Stewards nor the Oversighters necessarily have technical accumen, and this duty is not something they've volunteered to take on. One of the things to make sure of here is that the people doing the job are deeply knowledgeable about technical spaces and discussions and thus capable of recognising tech-specific forms of harassment for what they are.
Quim: it would probably be included in the document. The jQuery CoC, for example (which got passed today!) sets out this sort of thing very specifically, which I think works well. Ironholds (talk) 19:05, 19 August 2015 (UTC)
@Qgil-WMF: If I understand right, you're saying ECT does not necessarily need a reserved spot on the first-line committee, as the document currently lays out. Is that correct? I agree we will have to specify how the committee is formed, either in this document or a sub-document. I have added a note to this effect. Mattflaschen-WMF (talk) 21:08, 19 August 2015 (UTC)
Agree that we will need to specify more about the committee. I think that ECT should have a reserved spot for several reasons: ECT's job is community expertise, and there is substantial gathered knowledge and resources on that team, including easy consultation with other community teams; all-volunteer committees are vulnerable to gaps in institutional memory (and as tough a time as we have with our technical documentation and continuity of project knowledge, we need a way to ensure this doesn't happen here!); and CoC response and enforcement is a difficult and sometimes draining position, and having at least one person whose job this is part of should mean the committee has more support and structure. --Fhocutt (WMF) (talk) 23:41, 19 August 2015 (UTC)
for what is worth ECT also wants to be sure that the role this CoC gives to us is the role the community wants us to have. Any big social problem in the tech community has been and will continue to be a problem that we ECT need to help solving, with or without CoC. How exactly should we involved, you tell us. A pragmatic approach would be to define the process to form the committee (leaving the hypothetical ECT seat out for now) and to know the opinion of those interested to be part of it. At the end, these are the people that need to work comfortably with us.--Qgil-WMF (talk) 09:35, 20 August 2015 (UTC)
Note that I did not mention ECT's participation in the committee, only the nature of the appeal process. I would think it natural that some ECT members would volunteer to be part of the proposed committee, and if they end up going through a community election I doubt they would be likely to fail to get in considering the case. See below for my follow up on the choice of appeal body. -- (talk) 09:56, 20 August 2015 (UTC)
@Mattflaschen-WMF: Yes, I think that having an appointed and immutable ECT member in that first-line would set a default point of gravity that would influence how the committee operates. Also, this permanent seat would not help in cases where pro/anti WMF attitudes are part of the problem (not an unusual situation). Having all the members of this first-line appointed equally through a community-driven process would make this first-line stronger in many ways. Whenever the committee members feel that they need ECT's help (or help from anyone else at the WMF), we would be there to support them and to call anyone else that needs to be involved. No less, no more.--Qgil-WMF (talk) 10:02, 20 August 2015 (UTC)

Let me make a specific proposal for the committee membership, to prompt some discussion.

  1. Once we form consensus to enact the code of conduct, we (the people interested enough in this issue to be discussing it here) discuss amongst ourselves and nominate a slate of five trusted community members. I also think one seat should always be reserved for a member of the ECT, to help provide capacity and institutional memory, but if Quim doesn't think that's a good idea I don't think I can force him :)
  2. That slate gets ratified by the same process we used to enact the code.
  3. People serve on the committee as long as they want (unless they're forcibly removed). When a member leaves, the other members simply use their judgment to replace the departing member with another trusted community member. The code will explicitly mandate that they focus on keeping a wide variety of perspectives on the committee—which primarily means gender and geographic diversity—and that at the very most 2 (3?) members can be employed by the WMF.
  4. At any point, the community could use the same process used to enact the code to form a consensus to replace a committee member (this would essentially be a constructive vote of no confidence, requiring consensus on a replacement to remove someone). This means that as long as the committee does a good job (which, given that it's composed of trusted community members, I expect it almost always will), the rest of the community doesn't have to spend any time worrying about it.

Unanswered questions:

  • Should there be other mechanisms for removing a committee member? I imagine this would come up very rarely, so a community-wide discussion would be sufficient, but perhaps 4 members of the committee could vote to remove the fifth, or the ECT could step in to remove people.
  • What kind of process do we use for the community-wide discussions necessary to enact the code, select the first set of members, and remove them if needed?

My main objective here is a lightweight process. There's no need to institute the equivalent of enwiki's ArbCom elections when we will likely have far less conflict to deal with here. Also, I move that the committee be called the Conduct Committee, so we can call it ConCom for short :)—Neil P. Quinn (talk) 06:43, 20 August 2015 (UTC)

The question of why the appeal body must be the ECT is actually still floating here. There have been no solid reasons put forward as to why no alternatives are possible, or more desirable. -- (talk) 09:33, 20 August 2015 (UTC)

For what is worth, I don't think ECT or whoever is at the "second-line" should be the automatic appeal body. The first-line is in charge of receiving reports, and also appeals. If the committee or the person(s) appealing think that the first-line is no good fit in a specific case, then they can go to the second-line.--Qgil-WMF (talk) 10:10, 20 August 2015 (UTC)
I have difficulty comparing your reply against what is currently written in the draft document. It might be helpful to stick to the same use of words. -- (talk) 10:16, 20 August 2015 (UTC)
Sure, this is because we are all discussing and drafting, still with different opinions. We will get there. What is your take?--Qgil-WMF (talk) 09:28, 21 August 2015 (UTC)
To use the same terminology as the document, in a "case where the committee disagrees with the above initial response", the Committee already has the right to revisit a decision by a single Committee member. I don't think there should be a general right to appeal to the Committee again. However, I will broaden the 'objection' stage to reflect that the alleged offender can also object. Mattflaschen-WMF (talk) 01:38, 21 August 2015 (UTC)
Ironholds answered the question about why ECT above ("Neither the Stewards nor the Oversighters necessarily have technical accumen, and this duty is not something they've volunteered to take on. [...]"). Mattflaschen-WMF (talk) 01:38, 21 August 2015 (UTC)
I strongly disagree with this proposal for membership. My primary concern is very simple; you are assuming that people confident and certain enough to publicly comment in this discussion are adequately representative of the community, its concerns, and the nuances around problematic behaviour - and the members of the community who have left due to the inadequacy of existing codes of conduct, where they exist, and/or people who have not joined yet. That does not seem in any way a safe assumption to make. If we limit the pool of candidates and how they are evaluated to the people on this talk page we end up with a pool of people acceptable to the existing community - the existing community that in some elements is still discussing whether a code of conduct is even necessary much less what it looks like. This repeated idea that those who turn up represent the full gamut of opinions, or the opinions worth listening to, is problematic, and the assumption that the pool of people discussing it represents the pool of people who care about it is inaccurate (I know several people who have strong opinions here but are not comfortable commenting publicly) and honestly rather offensive. People not commenting do not "not care", they are in some cases simply not comfortable, and that should be something that causes us to re-evaluate how we hold these discussions, not dismiss factoring them in. Ironholds (talk) 14:12, 20 August 2015 (UTC)
What Ironholds said. I've personally heard from a fair handful of people who've been intentionally avoiding these discussions for reasons that include discomfort and lack of trust that their opinions will be thought to matter. --Fhocutt (WMF) (talk) 03:27, 21 August 2015 (UTC)
Ironholds, Fhocutt (WMF): My thought behind that idea (and maybe this is naive) is that it's not incredibly hard to find people who would do a good job in the role of a ConCom member. It's certainly not something I would entrust to anybody off the street, and it certainly requires sensitivity and empathy for the type of people we want to include with this code. But I think there are enough good options that even an unrepresentative discussion would come up with pretty good choices. For example, I think that both of you would do a great job—and despite the limitations of this discussion, you're already here.
That said, it's still a fair criticism, and it seems like the provision for private comments in Matt's plan would give people who are not comfortable discussing this in public a chance to make their voice heard. The only problem is that private comments means the ultimate decision on committee membership has to be entrusted to a third party—in this case, ECT. I don't think that would be a bad outcome, since I trust them and think they would make good choices—and since they are ultimately accountable to the community through the Board of Trustees. However, the Wikimedia ideal is fairly direct community semi-democracy and I would be disappointed if we couldn't find a way to make that work in this case.—Neil P. Quinn (talk) 06:05, 22 August 2015 (UTC)
I just reread what I wrote and saw where I put "the people interested enough in this issue to be discussing it here". You're right—that's misguided. There are many reasons why someone might be interested yet not be commenting here.—Neil P. Quinn (talk) 06:17, 22 August 2015 (UTC)
And actually, to modify my comment again, I've actually thought of some ways to make anonymous comments compatible with discussion-based consensus decision making (see #Next steps below). I also don't think giving ECT the ultimate authority to approve the people initially selected by the community would be bad—this isn't very different from the CA team having ultimate control of the global ban process, which I don't find concerning.—Neil P. Quinn (talk) 06:52, 22 August 2015 (UTC)
@Neil P. Quinn: I would be worried if the CA team claim to control global bans, as this has always been a community driven process. You may be conflating Global Bans with WMF Global Bans. -- (talk) 08:02, 22 August 2015 (UTC)
@: You probably know a lot more than I do about the global ban process; as I understand it, it's primarily community driven, but the CA team does intervene in extraordinary circumstances. I like the idea of a similar role for the ECT team here. For example, I wouldn't make them directly responsible for selecting Conduct Committee members, but I might well give them veto power over the community's picks, to be used only when strictly necessary.—Neil P. Quinn (talk) 01:14, 23 August 2015 (UTC)
I disagree with the proposal that 4 members could vote to oust the fifth. That would meant they could do that to prevent that 5th member from escalating (which the current draft explicitly says a minority could) the issue. I also think the idea of the community ousting members at any time risks politicizing it (think 'recall election'). I need more time to think about the rest. Mattflaschen-WMF (talk) 00:33, 21 August 2015 (UTC)
Yeah, on reflection, recall discussions do seem like a bad idea.—Neil P. Quinn (talk) 06:05, 22 August 2015 (UTC)
I also object to the idea of limiting the number of WMF employees to 2/5. I do think there should be non-WMF members, but I don't think you've made a case for why most (at least 3/5) members should be required to be non-WMF at all times. Mattflaschen-WMF (talk) 00:38, 21 August 2015 (UTC)
Agree on both counts. Recall elections get nasty easily, and if we're instituting quotas I don't think that WMF/non-WMF should be the only characteristic we filter on. Let's not open that up. --Fhocutt (WMF) (talk) 03:27, 21 August 2015 (UTC)
  • I disagree on the formation of any such committee. Existing Wikimedia projects processes should be used, such as sysops and stewards. --Nemo 06:40, 21 August 2015 (UTC)
    Existing Wikimedia projects processes have failed pretty thoroughly in this regard. As you yourself noted earlier, wikis which have behavioral policies are even more toxic then the Wikimedia tech space. Replicating that failure one more time does not seem like a worthwhile endeavor. --Tgr (WMF) (talk) 07:07, 21 August 2015 (UTC)
    I'm not aware of said processes being attempted for the cases presented and in the only cases I remember of blocks etc. in the MediaWiki community our processes worked perfectly. --Nemo 07:30, 21 August 2015 (UTC)
    Existing Wikimedia projects processes are designed to be effective on specific tools, and they don't attempt to be cross-tools. There are no stewards specific to "Wikimedia technical spaces", and it will be interesting to ask them what they think about enforcing a CoC in places like Phabricator, Gerrit, etc. I do think some stewards could be very capable committee members, though. As for sysops, only mediawiki.org has close to 200 users with that role. We cannot expect such group to deal efficiently with delicate situations privately. So no, I don't think the existing Wikimedia processes you are referring to have been effective to address the problems this CoC aims to address, and I don't think they are designed for this task.--Qgil-WMF (talk) 09:46, 21 August 2015 (UTC)
@Tgr (WMF): "Existing Wikimedia projects processes have failed pretty thoroughly..." is this really what the WMF believes and is trying to fix here? I have seen some anecdotes and ridiculous amounts of over dramatic grandstanding, but a lack of measurable evidence to show that if today we abandon community driven collegiate processes and force an untested WMF procedure from the outside, that this would result in attractive and healthier Wikimedia project communities, or be more effective for handling harassment. -- (talk) 08:12, 22 August 2015 (UTC)
I am not sure what gave you the idea that I am expressing the WMF's beliefs here. As for my beliefs, I do think the Wikimedia movement has a chronic problem with conduct, both with occasional harassment and with a constant background noise of hostility and microaggressions; and existing processes could not fix it, neither in the tech spaces nor in the content projects. This proposal borrows elements from other tech organizations, who had some success with them. In general, replacing a method that has failed for us with one that worked for others seems common sense to me; and implementing it and then comparing two processes that we actually tried seems more reasonable than trying to somehow measure theoretically how well something will work before we implement it. Maybe it will fail, and then we can scrap it; it doesn't seem like a particularly risky experiment. --Tgr (WMF) (talk) 08:21, 23 August 2015 (UTC)
A big +1 to that. It's worth considering, when people summarise WMF employees' opinions as "the WMF's opinion", that one of the components of being an employee at the WMF is that people are usually (as part of their job) spending more time in technical venues, if they're in technical roles, than is the norm. When the most regular contributors to and users of technical discussions are saying "we have a problem", "they're being paid to say they have a problem" is not the read to have there. Ironholds (talk) 14:39, 24 August 2015 (UTC)

It looks like there is more agreement than disagreement on the idea of giving the Committee the possibility to escalate complex issues to the Engineering Community team. I have added this bit in the draft. Whether ECT has a member in the committee or not is still open, but this can be discussed in the context of how the committee is formed.--Qgil-WMF (talk) 09:28, 2 September 2015 (UTC)

Conduct Committee v Legal Counsel

The draft mixes two classes of unacceptable behavior that must be handled differently.

  • Unacceptable behavior
    • Class 1 - violence, threats of violence, intimidation, stalking, inappropriate touching;
    • Class 2 - inappropriate communication, sustained disruption, offensive comments, unwanted photography, outing.

In many jurisdictions, class 1 behavior is a crime, and must be handled by the authorities. Not to inform the authorities would make one an accessory. Only class 2 behavior is properly handled by a WMF Conduct Committee.

  • Procedure
    • Class 1 - inform law enforcement, inform WMF Legal Counsel;
    • Class 2 - report to technical space moderator, file case with WMF Conduct Committee.
  • Penalty
    • Class 1 - WMF Legal Counsel recommends: ban, suspension without pay pending investigation, termination;
    • Class 2 - WMF Conduct committee issues: warning, timeout, suspension, ban.

Wp mirror (talk) 18:10, 19 August 2015 (UTC)

'Class 1' behavior can be handled by the authorities, but it is up to the victim to decide whether to report it to the authorities or not. The WMF and the conduct committee must not report what happened to the authorities, unless explicitly asked to do so by the victim.
There is no need to distinguish the two classes for this code of conduct; our (civil) response to a criminal act is seperate from a potential criminal investigation. Valhallasw (talk) 19:00, 19 August 2015 (UTC)
Agreed with Valhallasw. I'd also say that your argument very nicely demonstrates one of the problems with this kind of distinction; some of the acts you have categorised as "class 1" are not crimes in some places, but are in others, or have totally different standards in different jurisdictions. I absolutely agree that in the case of situations where we believe a crime has been committed, counsel should be notified. I disagree that the need to provide that notification precludes civil enforcement in addition (and would argue there are going to be cases where filing legal reports, straight off the bat, is not in the interests of the victim). This seems like an area where counsel should be consulted if there are legitimately worries that not reporting constitutes making the Wikimedia Foundation (or the committee, or anyone else involved in the reporting chain) an accessory. Ironholds (talk) 19:41, 19 August 2015 (UTC)
Nothing in this document discourages reporting to the authorities (and that is exactly as it should be). However, I think it is still worth reporting to the conduct committee as well (remember, the authorities may not be able to take legal action, but that doesn't mean we want that person in our community). There is also a clear statement, "If you believe anyone is in physical danger, please notify appropriate law enforcement first and email emergency wikimedia.org", which is an additional way the WMF could be informed about such serious matters. Mattflaschen-WMF (talk) 21:19, 19 August 2015 (UTC)

The draft states that one of the penalties is "public reprimand". This does create a need to distinguish the two classes. For a class 1 case, if the Conduct Committee issues a public reprimand, the following charges could be filed against the members:

  • Libel. If the Conduct Committee got the facts wrong (e.g. deceived by a vengeful X), the announcement could ruin the reputation of the reprimanded party, who would in turn seek remedy.
  • Accessory. If the Conduct Committee got the facts right, but did not inform the authorities, the announcement would alert the authorities, who would in turn want to question the members (what do you know, how long have you known about it, why did you not notify the authorities).

For a class 2 case, these concerns do not arise.

From time-to-time, the Conduct Committee will get the facts wrong. Why? No rules of evidence. The committee can not insist upon sworn testimony. The committee will sometimes have to rely upon hear-say. If we wish to claim that no distinction exists between the two classes, then perhaps we should choose penalties less likely to cause blowback. Wp mirror (talk) 08:48, 20 August 2015 (UTC)

Again, you are introducing a distinction that is not found in the actual draft, and these questions are best handled by actual lawyers. Ironholds (talk) 14:08, 20 August 2015 (UTC)

If the proposed Conduct Committee issues public reprimands, then we should expect that, sooner or later, actual lawyers will get involved. Shall we ask WMF Legal Counsel to look over the draft before this happens? Wp mirror (talk) 11:05, 21 August 2015 (UTC)

WMF Legal has reviewed this document for the Foundation. It is required that any reports involving WMF employees in any way be reported to WMF HR and potentially WMF Legal. VBaranetsky (WMF) (talk) 01:26, 28 August 2015 (UTC)

I am puzzled about what "It is required" can mean here. It is in the passive: by whom is it required? Do they mean that they, WMF Legal, require the Committee to pass on all such reports and if so by what right do they claim to require the Committee, which might well consist entirely of non-employees, to do something? Rogol Domedonfors (talk) 06:47, 28 August 2015 (UTC)
@VBaranetsky (WMF): Please rephrase in order to describe who is supposed to report and how those supposed to report can actually contact "WMF's HR". Also please explain what the abbreviation "WMF" stands for as it's the first time it's mentioned in the document. Thanks in advance! --AKlapper (WMF) (talk) 12:42, 28 August 2015 (UTC)
@VBaranetsky (WMF): This intervention is not entirely hepful. Firstly, WMF Legal is not in a position to simply dictate arbitrary unexplained and obscure additions to this code, which is in the middle of a community discussion aiming at consensus. Secondly, the addition is surprisingly vague, as pointed out just above. Thirdly, it is incompatible with at least two other provisions of the Code, which states in other sections that All reports will be kept confidential and mandates of the Committee that before revealing any confidential information from the report, they must get consent from the reporter -- are you now attempting to order the community to alter those provisions? Fourthly, it is potentially incompatible with legal requirements in other jurisdictions, where these events may take place, which mandate certain privacy procedures for the protection of complainants and suspects in certain kinds of crime. Fifthly, it is unenforceable, as WMF has no authority over non-employee actions. This requirement needs to be restricted to areas in which the WMF HR and Legal departments have authority, which is over their own employees. Simply make it an internal rule that WMF employees and contractors are required to report to line management if they are involved in a complaint under this code. That is proportionate and enforceable. Rogol Domedonfors (talk) 19:29, 28 August 2015 (UTC)
This can certainly be edited as needed. My understanding is that under California (USA) law, organizations are liable in various ways when their employees are harassed, whether by employees or third parties (like customers or, in our case, volunteers). I am personally ok with including whatever reasonable provisions are needed to make it easy to comply with employment laws or reduce the probability that the WMF could be sued for allowing a hostile work environment. I do share concerns about confidentiality and not forcing victims to report, however. That said, I suggest waiting to hash this out for when we are focusing on reporting/governance. --Fhocutt (WMF) (talk) 21:57, 28 August 2015 (UTC)
Unfortunately this cannot "be edited as needed" since we have no idea what it is trying to achieve, why it is necessary or what alternative forms of wording or processes would meet whatever it is that WMF Legal "requires". It is probably counter-productive to guess without having a clear statement from them of their rationale. I have proposed a alternative form of words to meet what I guessed to be that rationale, and which preserves the independence of the Committee. It is disappointing that VBaranetsky (WMF) has edited the page again, albeit in a minor way, without addressing those points. Waiting is certainly an option but since there is currently a fundamental contradiction in the Code as written (between confidentiality and requirement to report to WMF), and confidentiality is a rather important principle to get settled, it seems to me important to resolve it sooner rather than later. I may say that my inclination is to accord more weight to confidentiality of the proceedings than to the currently unexplained demands of WMF Legal. If it is indeed the case that this requirement stems from their legal duty to protect their staff, then it would seem that they have no confidence in the ability of this Code to do so, which is rather sad news for the rest of us who are not protected by the WMF in the same way. Rogol Domedonfors (talk) 06:35, 29 August 2015 (UTC)
"Simply make it an internal rule that WMF employees and contractors are required to report to line management if they are involved in a complaint under this code." In my opinion, this (without a check) is not enforceable, even if the alleged offender is acting in good faith. First, confidential information from the report is not given to the alleged offender unless the reporter agrees. If the reporter does not agree, the alleged offender may never know about the complaint (though this may impede investigating it, as the draft notes), but my understanding is that HR still needs to know. Then, of course, what if the alleged offender is not acting in good faith? What happens if they don't report the Committee proceedings to HR? Who will be in a position to verify this is done? Mattflaschen-WMF (talk) 20:16, 2 September 2015 (UTC)
  • A couple of scenarios.
  • A participant in a hackathon at Wikimania 2016 is sexually assaulted by another participant. A third participant is a witness and is able to give clear evidence that the incident was an assault. The victim is embarrassed to describe the nature of the assault but does so in the assurance that the description will remain private.
Now we discover that the witness is a WMF contractor. Under the required rule, the Committee is required to report to the WMF Legal department. They cannot help in any way, and the victim is further distressed by having the details of their assault pointlessly communicated to unknown parties in another country.
  • A participant in a hackathon at Wikimania 2016 is sexually assaulted by another participant. A third participant is a witness and is able to give clear evidence that the incident was an assault. The victim is embarrassed to describe the nature of the assault but does so in the assurance that the description will remain private.
Now we discover that the perpetrator is a WMF contractor. Under the required rule, the Committee is required to report to the WMF Legal department. The victim will now be faced with the details of their complaint being given to a team of lawyers at a multi-million-dollar organisation who have been given this information in order to protect the interests of the perpetrator.

Do we believe that either of these scenarios will encourage victims to step forward and complain formally to the Committee? Or do we believe that the requirement in question will have a chilling effect on the reporting of serious breaches of the Code? What benefit is there to counterbalance the harm done to the community? Rogol Domedonfors (talk) 09:06, 29 August 2015 (UTC)

@VBaranetsky (WMF): : Since your edit does not address where reports concerning people affiliated to other organisations should go, it's been reverted. --Krenair (talkcontribs) 20:39, 29 August 2015 (UTC)
That question is already addressed: the answer is nowhere, since it is twice stated that all reports will be confidential. It is only the WMF that has asserted, without explanation, the requirement to breach that confidentiality and the right to order the Committee to do so. It is not at all clear what will happen should a member of the Committee decline to pass on this confidential information because it violates the privacy laws in the country where an incident took place, or because it violates their personal or professional code of ethics, or because they resist being told what to do by an outside party without authority over them. Rogol Domedonfors (talk) 21:47, 29 August 2015 (UTC)
Rogol: I've replied below. I share some of your concerns, but I also don't want, say, the only information that HR has to work from to come from the offender, as might happen with only having an internal policy that mandates involved parties report. What I mean to say in suggesting we handle it later is that it falls under enforcement/reporting, not under principles/unacceptable behavior/re-use and so it doesn't block Qgil-WMF's suggestion to approve this by stages. --Fhocutt (WMF) (talk) 18:38, 1 September 2015 (UTC)

Double jeopardy

I think it's implicit in some of the preceding discussion, but I think it worth stating explicitly. By double jeopardy I mean the issue of whether sanctions under the Code should be applied in cases where other proceedings and penalties, possibly legal, are also applicable to the conduct in question. For example, some forms of harassment are legal crimes. Some people take the view that one should not be proceeded against or punished twice for the same offence. I personally take the view that the Code is here to protect the community and that the additional privileges and benefits of being a member of this community justify the imposition in principle at least of imposition of additional penalties for conduct that disrupts or damages this communty. I further think that this is the consensus view of this discussion. It might be worth discussing exactly what that means in the case og, for example, criminal proceedings. For example: "If the conduct complained of is or becomes the subject of formal legal proceedings, then the Committee will suspend its final decision until the results of those proceedings is known, but may make an interim ruling for the protection of the community. At the conclusion of those proceedings, the Committee will decide whether to continue with its own decision or to rule that further action is unnecessary.". Rogol Domedonfors (talk) 08:54, 29 August 2015 (UTC)

I agree that we do not want to exempt someone from a Code of Conduct penalty due to a separate legal proceeding. I'm not sure suspending decision during a separate process is necessary, but it might work if the Committee still has its full powers for the "interim ruling". I also disagree with deciding "further action is unnecessary" on the basis that a separate body (e.g. a court of law) has taken action. There are cases where the court could impose a severe penalty but we would still certainly want to take action. But even if the court takes relatively minor action, we may still choose to take action since the Code of Conduct is a different set of rules with different consequences. If by "rule that further action is unnecessary", you mean "decide that the interim decision is sufficient, and simply making the interim decision final should conclude the case" that might be appropriate in some cases. However, the penalties imposed by other bodies (if any) should be irrelevant to the Committee's decisions. Mattflaschen-WMF (talk) 23:30, 31 August 2015 (UTC)
Most legal systems are terrible at handling harassment. This policy is about what behavior we want to accept and support in our community, and I'm fine with other communities and policy systems having their own say about what behaviors they want to accept. Legal proceedings are often long enough and vary enough by location that I don't think there's a reason to mention them explicitly. --Fhocutt (WMF) (talk) 17:59, 1 September 2015 (UTC)

Proposed additions

i suggest the fllowing addition to Principles:

This code is published by Resolution of the WMF Board of Trustees, which acts as the authority for its implementation on behalf of the community.

and under Enforcement:

The WMF Board authorises a Code of Conduct Committee to manage reported infractions of the Code! Constituted as follows ...
The WMF Board will hear appeals from the decisions of the Committee, either directly or through a committee formed ad hoc.

A draft resolution for the Board would be needed. Rogol Domedonfors (talk)

Except it's not, it hasn't, and it doesn't. If there's a desire to have the board as the appellate body or authorising body the board should say "Yes, we're comfortable doing that". Ironholds (talk) 18:07, 25 August 2015 (UTC)
You will need to explain the various values of "it" in your first sentence: the tricolon loses in rhetorical power by the unclarity of the referents. The proposal is however exactly as you say in your second sentence. To achieve the situation outlined in this proposal would indeed involve putting the proposed Code formally to the Board and having them formally adopt it by Resolution. Of course a prelininary informal approach and agreement in principle would be needed first, so to that extent we seem to be in agreement. Rogol Domedonfors (talk) 20:38, 25 August 2015 (UTC)
It's ordered by your original order. If we're in agreement that informal approach/agreement in principle is needed first then somebody should be doing that; we should not be adding language which presumes acceptance and makes the entire draft ride on board agreement. Let's draft without presumption; if the board later decides to adopt it they can pass a resolution that contains whatever modifications are necessary to confirm the board is doing it. Ironholds (talk) 20:51, 25 August 2015 (UTC)

Its a community initiative not something being imposed from above. I don't think the board really has any place here. Bawolff (talk) 20:55, 25 August 2015 (UTC)

This doesn't belong to Principles but to Committee. Rogol Domedonfors, if you are in a rush willing to include the Board in this initiative, feel free to contact them and ask their opinions. I still think it is better to wait to have a more consolidated draft, though.--Qgil-WMF (talk) 21:01, 25 August 2015 (UTC)
The rush is being imposed by those who do not wish to proceed with a draft along these lines without asking the Board in conjunction with those who want the draft in order to consult the Board. So I have anyway, at meta:Wikimedia_Foundation_Board_noticeboard. Rogol Domedonfors (talk) 21:12, 25 August 2015 (UTC)
This does not require a Board resolution, and I disagree with asking for one. The Terms of Use (which is Board-approved) says, "The Wikimedia community and its members may also take action when so allowed by the community or Foundation policies applicable to the specific Project edition, including but not limited to warning, investigating, blocking, or banning users who violate those policies. You agree to comply with the final decisions of dispute resolution bodies that are established by the community for the specific Project editions (such as arbitration committees); these decisions may include sanctions as set out by the policy of the specific Project edition." Mattflaschen-WMF (talk) 03:13, 26 August 2015 (UTC)
Then you will be pleased to see that I did not ask for one. As discussed here, I asked for informal views about how the Board viewed the proposal that thry should be the authority behind this code. If they wish to do so, they would eventually enact it by formal Resolution, but that is a long way off. If they indicate their views informally at this stage, it will make drafting easier. Rogol Domedonfors (talk) 07:08, 26 August 2015 (UTC)

It makes me feel sad to see that Board involvement is asked for. This is exactly the place where I thing the affected community should deliberate, find a consensus, agree on wording and implement such a policy. A code of conduct only works if it is backed up by those who have to follow it. A top-down-manner is not the best idea to create this ownership feeling. Lyzzy (talk) 15:47, 1 September 2015 (UTC)

Being Lyzzy Vice Chair of the Board of Trustees, I think we can take her comments as a good indication that we should keep the Board away from this draft. If they want to have a role here, they know where to find us. :) Thank you Lyzzy for your feedback.--Qgil-WMF (talk) 08:06, 2 September 2015 (UTC)


Protection of Conduct Committee members

A volunteer serving on the Conduct Committee must consider the possibility that an aggrieved party will sue for libel. To attract qualified volunteers to serve on this committee, one should consider how best to protect them. The main methods are:

  • D&O Liability Insurance. Many not-for-profit organizations purchase a D&O policy that extends coverage to chapter members and volunteers. It is not clear if the WMF has such coverage. Nothing relevant appears when one searches wikimediafoundation.org.
  • Limited disclosure. To take away the grounds for a libel suit, many not-for-profit organizations follow RONR 10th ed, Chap XX Disciplinary Procedures, §61: "If (after trial) a member is expelled, the society has the right to disclose the fact that he is no longer a member—circulating it only to the extent required for the protection of the society or, possibly, of other organizations. Neither the society nor any of its members have the right to make public the charge of which an expelled member has been found guilty, or to reveal any other details connected with the case. To make any of the facts public may constitute libel."

For the protection of Conduct Committee members, please:

  • procure D&O liability insurance, and post the terms on your site;
  • specify, in the procedural law for the Conduct Committee, how to report the outcome of cases; and
  • reconsider the "public reprimand" penalty clause stated in the draft.

Wp mirror (talk) 07:12, 20 August 2015 (UTC)

The Wikimedia projects are not organised as a society of members. Again, these concerns are best surfaced to and handled by counsel, not pseudorandom members of our technical community (I include me in that). Ironholds (talk) 14:07, 20 August 2015 (UTC)
What open source code of conduct committee offers D&O insurance to all members (both staff and volunteer)? Unless you can show a significant number of them do, I don't think it's reasonable to pursue this. I also can not think of any cases where someone has successfully sued an open source project or related organization for libel after being banned from participating or reprimanded. Can you? Mattflaschen-WMF (talk) 00:43, 21 August 2015 (UTC)

I have in mind the following libel cases:

The last three are sometimes called cyberlibel cases. Consider the following:

  • If the proposed Conduct Committee got its facts wrong and publicly reprimanded someone for a crime he did not commit, Zenger (1735) would not apply, and WMF General Counsel would seek another defense.
  • If WMF General Counsel disavows the Conduct Committee, then Cubby (1991) might be a defense. But then the Conduct Committee would not have authority to enforce the Code of Conduct.
  • If the WMF Board of Trustees acknowledges the Conduct Committee (e.g. if the Conduct Committee reports to the Board of Trustees, like say the Affiliations Committee does), then Stratton (1995) might apply and WMF would be liable.

As to D&O Liability Insurance:

  • members of the WMF Board of Trustees are indemnified (see Bylaws Article VIII - INDEMNIFICATION);
  • the WMF Chief of Finance and Administration is responsible for purchasing the coverage (see seventh bullet under ADMINISTRATION).

The need for coverage is real.

  • If coverage is not provided, qualified volunteers might be hard to find, and even WMF employees would be prudent to hesitate.
  • If WMF employees are covered, but not volunteers, then committee membership should be restricted to employees.
  • If WMF General Counsel needs to be able to disavow the Conduct Committee, then WMF employees must be excluded from the committee.

This is why potential committee members need to see a copy of the policy. The WMF Chief of Finance and Administration is only one e-mail away. Shall we ask him? Wp mirror (talk) 03:33, 21 August 2015 (UTC)

I asked some specific questions, with the goal of comparing to similar situations (open source or at least similarly-minded organizations with code of conduct enforcement). None of the libel cases you mentioned show that a good-faith ban or reprimand can lead to a successful libel suit. I am not convinced libel suits are a real problem other communities have faced in connection with their codes of conduct.
Similarly, you have not shown that D&O insurance is something other similar committees have had. It's not always affordable or realistic to buy more and more insurance, and it certainly doesn't seem to be legally required (or you would cite an example of a community that had bought it). Mattflaschen-WMF (talk) 04:04, 21 August 2015 (UTC)

Example: The w:Association for Computing Machinery is a publisher, has chapters and special interest groups that also publish, hosts public speaking events, and has on-line communities. The ACM also has a code of ethics, breach of which may result in termination of membership (see section 4.2). When I was a member, the ACM had a D&O Liability Insurance policy that extended coverage to all its chapter members and volunteers worldwide. As an officer of one its chapters, I had a copy of the policy. When the conduct of one of our members created a legal liability, we initiated a disciplinary process. We followed RONR 10th ed., as stated in our Bylaws. Charges were drafted, the board went into executive session, and we do not disclose the facts of the case.

Following RONR plus D&O coverage is why libel is not a problem for the ACM. The ACM is not unique in this respect. Indeed, the formula is widely used in the not-for-profit world. Public reprimands for breach of professional ethics are issued by governments and governing boards (e.g. legal, medical). Non-profits, however, quietly dismiss an unethical member.

D&O premiums are low. Cost is not the issue. Nor is having a list of court cases. Getting people with executive experience to serve is the issue. This is why WMF trustees are indemnified. They would not serve otherwise. Wp mirror (talk) 06:52, 21 August 2015 (UTC)

We should definitely check this with WMF Legal before it takes effect. There may be other approaches to dealing with any potential liability arising from participation on this committee. --Fhocutt (WMF) (talk) 23:10, 21 August 2015 (UTC)
The ACM Is only loosely comparable. It's not an open source organization, but a publisher. Unlike us, they also have a clearly delineated set of 'members'. Moreover, their bylaws say, "The Association shall have power to purchase and maintain insurance or to self-insure on behalf of any person who is or was a director, officer, employee or agent of the Association". You'll note that it says nothing about having the power to purchase insurance for all ACM-related volunteers. In fact, it doesn't even authorize them to purchase insurance for all paying members. That suggests that if they ever covered all volunteers or all members, they no longer do. No one has suggested that 'executive experience' is required to serve on this committee. I am confident we can get people to serve on this committee, including volunteers. Mattflaschen-WMF (talk) 21:38, 23 August 2015 (UTC)
In order to resolve some of these issues, it will be necessary to have a decision from WMF Legal. Is the WMF willing to take steps to give legal protection to members of the Committee (and the appeal body)? If so, this discussion can proceed on the basis that WMF Legal will know what to do and will do it effectively: it may be that they will wish to advise on procedural matters to make that protection most effective and efficient. If not, then the discussion will need to proceed on the basis that individual Committee members and indeed individual community members are legally at risk in these proceedings, and again WMF Legal may be able to help by advising on how to manage those risks (although I do not know whether their remit extends to advising non-WMF people or entities, of course). Personally speaking I would not advise anyone to undertake this is sort activity without adequate legal protection, but other community members may have a different appetite for risk (or better legal insurance). @VBaranetsky (WMF): as one who has been taking an interest in the legal relationship between the WMF on the one hand and this Code and its Committee on the other, can you please help here? Rogol Domedonfors (talk) 20:33, 28 August 2015 (UTC)

Is the CoC introducing any novelties here? User bans and other types of measures already exist, and with them the risk of upsetting someone to the level of retaliation. If anything, the CoC provides a bit more structure and a bit more protection to the ones taking action. The existence of a Committee allows admins and maintainers to not be the main actors when i.e. banning someone. The Committee can delegate ugly cases to professional employees at ECT. WMF Legal does protect WMF employees legally, but so it does with Wikimedia volunteers as well. In the case of someone receiving some retaliation for enforcing a CoC resolution, I think the situation with CoC will be better than the current situation without it.--Qgil-WMF (talk) 10:09, 2 September 2015 (UTC)

"Public reprimands" (one of the penalties Wp mirror took issue with) also already exist in Wikimedia communities. Specifically, this is what happens when an admin posts on someone's talk page something like "You have done Xyz which is a violation of our policies. Please do not do so again, or you may be blocked." Mattflaschen-WMF (talk) 20:40, 2 September 2015 (UTC)

Proposing Intro + Principles + Unacceptable behavior

As proposed in #Next steps, let's focus on agreeing Intro + Principles + Unacceptable behavior up to a point where we can make a wider call to wikitech-l and whatever channels we decide. These sections define the scope of this Code of Conduct, and have an intrinsic value.

Please do not discuss these topics or new ones here. Use the existing or new sections instead. Here we are only coordinating the work of proposing these three sections of the draft CoC to wikitech-l.--Qgil-WMF (talk) 10:25, 24 August 2015 (UTC)

I think the current version of these sections is solid. We could leave a bit more time until Thursday evening / Friday morning Pacific to see whether there are still major changes proposed, and if not, then proceed with the call for feedback at wikitech-l. Does this sound sensible?--Qgil-WMF (talk) 07:25, 26 August 2015 (UTC)
The plan and the timing sound good to me. --Fhocutt (WMF) (talk) 19:05, 26 August 2015 (UTC)
Yeah, that seems reasonable. Mattflaschen-WMF (talk) 00:21, 28 August 2015 (UTC)
We have got conduct-discussion wikimedia.org and this is good to go. Mattflaschen-WMF, whenever you want.--Qgil-WMF (talk) 09:42, 1 September 2015 (UTC)
The email address is not yet ready. The privacy settings need to be adjusted. I will send out an announcement to wikitech-l when it can be used. Mattflaschen-WMF (talk) 00:28, 2 September 2015 (UTC)
Email is ready, settings have been adjusted, and wikitech-l has been emailed. --Fhocutt (WMF) (talk) 22:05, 4 September 2015 (UTC)

Level of experience

"We are committed to making participation in Wikimedia technical projects a respectful and harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sex, sexual orientation, disability, physical appearance, body size, race, ethnicity, national origin, age, political affiliation, or religion."

I feel the inclusion of "level of experience" in this list is problematic, if that is implicitly "level of technical experience". The other attributes in this list are identity attributes which have no bearing on someone's contributions, and should never contribute to someone being less respected, welcomed, encouraged, etc, etc that anyone else.

However level of technical experience does influence how respected, welcomed, and even encouraged that a participant will be, especially when at the coal-face of code review.

I can appreciate that our technical environment should be "harassment-free" for everyone, and especially for juniors. (This is especially critical in physical spaces, however that is covered with a different policy.) In the context of technical interaction in online spaces, the term "harassment" can be interpreted much more broadly by participants. Broad definitions of "harassment" are a good thing in the event that the behaviour appears to be discriminatory to identity attributes. They are not good if someone is reaching to find a reason why their technical contributions are not being accepted, and wanting to shift the blame from their inexperience or poor quality onto others.

I have similar concerns about the inclusion of "consistent and unwarranted rejection of patches", as "unwarranted" can also be a situation where code submitter vs reviewers have view different perspective of expectations wrt quality, and ultimately review of patches should be a consensus or stalemate of available +2'er, and this policy is unlikely to be a useful tool in preventing stalemates between +2'ers.

I believe that level of technical experience, if that is the objective here, should be handled separately from identity attributes.

I suspect that "level of experience" is trying to get at either/both of the following, which I agree with:

  1. newness of the contributor (i.e. number of years involved in this community) shouldn't be a discriminatory aspect
  2. power relationship games are completely unacceptable

Sorry I don't have answers for how to rephrase this yet. John Vandenberg (talk) 05:33, 26 August 2015 (UTC)

I think part of what its trying to get at, is making fun of people for lack of skill, is not ok. I think there's also a dual meaning of the word "respect". It can mean being a decent person, but it can also mean how seriously you treat their ideas or how likely you are to defer to their decisions, etc. I believe its important to be nice to everyone. But if someone wrote on wikitech-l proposing to rewrite half of MW, I'm going to treat their email much more seriously if somebody like Tim Starling is writing it, than if someone I don't know is writing it. Bawolff (talk) 05:55, 26 August 2015 (UTC)
"a respectful and harassment-free experience for everyone, regardless of level of experience" means that we commit to avoid that someone shows lack of respect and/or harasses someone else because of their level of experience. If I open a discussion in wikitech-l about rewriting MediaWiki from scratch as a Lua template (!), the community has all the right to ignore me or tell me that I have no idea what I am talking about, but according to this CoC I will still have the right to be respected and not harassed. Same if my knowledge of written English is poor, I write emails as if they were txt mssgs, use all-caps too much, top-quote, use a vague subject in my new email thread, ask every other minute on IRC because I don't know better yet, and many other very realistic cases. These behaviors are annoying and require certain patience and dedication to fix, but no one deserves "Offensive, derogatory, or discriminatory comments" because of this.
For the rest, look at the new version; I think that it has solved your concerns as well.--Qgil-WMF (talk) 07:15, 26 August 2015 (UTC)
There is a genuine choice here about what sort of Community to be. Consider the situation where a novice makes a suggestion that is apparently reasonable but has been tried before and is known not to work, or is unworkable for some other, not obvious, reason. In some communities I have known, it would be acceptable to say "no, you don't know what you're talking about" or "Wrong. End of" and to respond to the obvious followup question with an accusation of trolling. In others, it would be regarded as rude to reply with anything less than "we tried at out in such a date and it didn't work as you can see on such a page" or "that sounds reasonable but the buffer is updated asynchronously and you can't be sure that the data is there although it almost always is, and we have decided to design code for the unlikely cases as well.". In other words, some communities choose to be learning communities, which takes more time, and others choose a model in which experience and expertise buys you the right to be brusque with newbies. Which do we want to be? Rogol Domedonfors (talk) 07:29, 26 August 2015 (UTC)
"an open and welcoming community" (as described in Principles). We already are (or at least want to be) open and welcoming. There are many examples, although we can always improve. In any case, I don't think this discussion would bring any changes to the current proposal.--Qgil-WMF (talk) 07:44, 26 August 2015 (UTC)
We want to be a learning community. Experience is never a justification for rudeness; in fact, it undermines any defence. Ironholds (talk) 18:15, 26 August 2015 (UTC)
One step further: if we want to make it so that "every single human being can freely share in the sum of all knowledge", and not just the human beings whose backgrounds we understand and whose expertise we already respect, we must be a learning community. It takes more work, yes, but it's work worth doing. --Fhocutt (WMF) (talk) 18:56, 26 August 2015 (UTC)
I think we ought to be the kind of community that tries to engage new people and learn together. Besides basic respect, another advantage of the "that sounds reasonable but the buffer is updated asynchronously" approach is that maybe a few months later, they will post to wikitech-l "But what if the asynchronous update triggers an event using this mechanism..." (or whatever), which might turn out to be a really good idea. Bringing new people into the community also brings in new ideas and experience (they might not know anything about wiki software, but what if they know a lot about algorithmic optimization, or UX, or...)? Mattflaschen-WMF (talk) 00:28, 28 August 2015 (UTC)
@John Vandenberg: : both of those, yes, but also what Qgil-WMF mentioned. Knowing the social conventions of an open source project (or how to find them out) is not actually trivial, though we tend to forget it the longer we participate in a given community. Open source has a long and unfortunate tradition of "RTFM, n00b" and this point is intended to address that. Specifically, I'm aware of someone who was turned off MediaWiki development after seeing their early contributions discussed uncharitably on IRC. Learning doesn't happen when people are afraid they'll be mocked or insulted for making mistakes, and many people will just go away when they feel unwelcome. --Fhocutt (WMF) (talk) 19:29, 26 August 2015 (UTC)

Thanks for the responses, which help clarify the intent. Also thanks for removing "consistent and unwarranted rejection of patches".

However the inclusion of level of experience, in this list, bothers me as raises it to the same level as discrimination based on identity attributes. In many countries, including mine, there are discrimination laws that explicitly address the majority of these identity attributes. Those laws are usually full of complicated aspects, and typically only apply to employees, differ per country, and often dont handle online spaces well, so it is wonderful to have a community consensus which unreservedly and strongly rejects all forms of identity based discrimination and harassment, using broad language, in our shared online environment.

To me, adding 'level of experience' in this list trivialises all of the other items in the list, which are all identity based. 'level of experience' (broadly speaking) does deserve being highlighted in the CoC, somewhere else, but it fundamentally is not the same as the others in this list. Including it weakens our commitment against identity based discrimination and harassment, when it should be using stronger language for those. Dealing with contributors with seemingly low competence/familiarity can become quite hard, especially if they are not hearing the sometimes too subtle cues, and we all struggle with how to support newcomers effectively - there is always room for improvement here (IMO not reviewing patches in a timely fashion is not respectful). Of course extreme reactions, such as mocking a contributor, is unacceptable, however "RTFM, n00b" is a completely different type of problem to responses that focus on a person identity. Any complaint lodged relating to identity attributes, irrespective of how trivial it is, should result in strong community rejection, and rapidly escalating enforcement. Non-trivial complaints lodged relating to primarily to 'level of experience' are typically going to be complex to untangle, and will often be unresolvable due to difference in perspectives of the events in question. If isolated, complaints related to 'level of experience' will need to give the accused the benefit of the doubt. Repeated bad behaviour related to 'level of experience' will need more careful handling, and possibly even providing training if the accused is a valuable technical resource. John Vandenberg (talk) 08:22, 27 August 2015 (UTC)

Would it help to have "level of experience" at the end of the list instead of the beginning? Level of experience is a known target of certain types of unacceptable behavior that we don't want to see in our community. Identity is a tricky concept and I don't think it is worth entering into this debate. Some people won't care much about their own political or religious views, but they might feel stronger about their "geekiness" or "non-geekiness". Also, maybe "level of experience" is not the best wording. Someone can be an expert in several fields of humanities and sciences, be a great family and social partner organizing all kinds of stuff, but have little experience in the context of a free software project. "technical skills" might be a better label for that.--Qgil-WMF (talk) 08:56, 27 August 2015 (UTC)
I'd be much happier if our treatment of newcomers / competence levels / skills is clearly separated from the others. IMO it is worthy of its own sentence/paragraph in the Principles section. Putting it at the end doesnt address my concern. If there is any interest in separating it, I'd be happy to put in some effort to try separating it from the others in a way that highlights it as an important problem. If not, so be it.
"technical skills" is IMO better. John Vandenberg (talk) 09:25, 27 August 2015 (UTC)
I think one of the things we're trying to say here is that established contributors do not get special consideration or licence in matters of conduct on account of the claimed value of their contributions. (This is a principle which the English-language Wikipedia continue to struggle with.) Is that indeed what we are agreed on? If so, is there is suitable form of words? Something like "The behavioural standards expressed in this code apply equally to all members of the community irrespective of status". Rogol Domedonfors (talk) 06:47, 29 August 2015 (UTC)
I have tried to address your feedback in this edit.--Qgil-WMF (talk) 14:05, 31 August 2015 (UTC)
That is pretty much what I believe the consensus here to be. Rogol Domedonfors (talk) 16:52, 31 August 2015 (UTC)
@Qgil-WMF: @Rogol Domedonfors: I completely agree with the principle behind "The behavioural standards expressed in this code apply equally to all members of the community irrespective of status" (not saying we necessarily need that exact sentence in it, but I support that idea). However, I don't think that's all it should mean. It should also including the ethos of (these are ideas, not proposals for the draft) "Treat newcomers in a welcoming way" and "Try to make interactions with them educational where possible, rather than devolve into RTFM, or just 'Won't Work'", and "Don't harass them because they're new". Mattflaschen-WMF (talk) 23:15, 31 August 2015 (UTC)
Now? (I thought I know everything about wikitext discussions, but I'm getting lost with bullets, colons, and indentations...)  :) --Qgil-WMF (talk) 09:34, 1 September 2015 (UTC)
Yeah, the current text for this looks fine. Mattflaschen-WMF (talk) 23:40, 1 September 2015 (UTC)
Yes, I like the phrasing in the draft now. --Fhocutt (WMF) (talk) 17:47, 1 September 2015 (UTC)

Much appreciated everyone who helped fix this. The current wording is great! John Vandenberg (talk) 06:06, 5 September 2015 (UTC)

Who is going to approve this/how?

It's not clear to me how we expect this draft to be made into policy. Are we going to vote on this? If does eventually become policy, what would be the process for amending it? --Krenair (talkcontribs) 21:00, 29 August 2015 (UTC)

It was suggested above under #Governance that it be formally adopted by Resolution of the WMF Board of Trustees. Rogol Domedonfors (talk) 21:37, 29 August 2015 (UTC)
I think who approves and how depends on the final draft, and this is why I'm focusing on pushing the draft further as proposed in #Next_steps. I would personally prefer to try first a process of discussion and consensus.--Qgil-WMF (talk) 14:09, 31 August 2015 (UTC)
I agree with Qgil-WMF that consensus here on this talk page is the best way. A Board resolution is unnecessary. See my last comment at Talk:Code_of_conduct_for_technical_spaces/Draft#Proposed_additions ("This does not require a Board resolution, [...]") for why. Mattflaschen-WMF (talk) 23:44, 31 August 2015 (UTC)

Authority/power of committee?

It's not clear how a committee is going to work unless they are either actually given the power to issue bans etc. themselves, or can convince local technical space admins to give effect to their decision in every single controversial case (of which there will hopefully be few/none, but that can't be assumed) --Krenair (talkcontribs) 21:04, 29 August 2015 (UTC)

Local technical space admins are subject to this CoC just like anybody else. There is a specific sentence mentioning them in the Principles section. They should apply the decisions of the CoC or have a good argument for an appeal.--Qgil-WMF (talk) 14:16, 31 August 2015 (UTC)
There is also specific text ("The committee can also bring in people from the spaces involved (e.g. if it happens on both MediaWiki.org and IRC, bring in involved admins and IRC contacts).") about bringing in local space admins when appropriate. In such cases, the local space admins have a direct opportunity to participate in discussion, and thus better understand the basis for the committee's decision. Mattflaschen-WMF (talk) 23:50, 31 August 2015 (UTC)

IdeaLab/Community discussion on harassment reporting

Has this discussion take full account of the parallel meta:Grants:IdeaLab/Community discussion on harassment reporting? Rogol Domedonfors (talk) 11:29, 30 August 2015 (UTC)

Do you see specific points that we could take in our CoC draft?--Qgil-WMF (talk) 14:24, 31 August 2015 (UTC)
It contains a lot of useful material. The section What types of harassment have been reported on Wikipedia is revealing (and depressing). Not all are explicitly covered here. That's just one example. Rogol Domedonfors (talk) 16:50, 31 August 2015 (UTC)
Looking at "Community claims" and "What types of harassment have been reported on Wikipedia", I think the cases mentioned there would be covered by our CoC, even if they are not necessarily spelled out with the same words here. If someone finds an actual gap, please report it.--Qgil-WMF (talk) 09:40, 1 September 2015 (UTC)
I don't know if that specific document has been used. However, Grants:Friendly space expectations has been, so we are taking some lessons from their experience. As far as the specific list of things that happened on Wikipedia, this is partly why we have "Examples include but are not limited to". Mattflaschen-WMF (talk) 00:07, 1 September 2015 (UTC)

Unacceptable behavior

In the beginning of the "unacceptable behavior" section, the phrase "unacceptable behavior" (which I just changed to "Behavior that is unacceptable") linked to the Terms of Use. What exactly are we trying to communicate with the link? That we consider all the behavior mentioned to be harassment and therefore prohibited by the terms? If so, we should make that statement explicit (and check that it's legally okay too, although I'm not sure the WMF legal team could give us an opinion).—Neil P. Quinn (talk) 22:06, 18 August 2015 (UTC)

That was taken from meta:Grants:Friendly Space Expectations. My reading was that it is a reminder that harassment is already legally prohibited for Wikimedia-hosted projects, rather than a statement on the specific behavior listed here. If it's confusing, I'm fine with removing it. --Fhocutt (WMF) (talk) 01:03, 19 August 2015 (UTC)
The link is inappropriate, in my opinion. I already removed it once. --MZMcBride (talk) 02:36, 19 August 2015 (UTC)
I moved the link to the "See also" section as that seemed reasonable. --MZMcBride (talk) 02:44, 19 August 2015 (UTC)
I think that's a good place for it, especially as this applies to spaces outside of WMF resources. --Fhocutt (WMF) (talk) 19:21, 19 August 2015 (UTC)
Clarify "outside of WMF resources"? --Nemo 07:16, 21 August 2015 (UTC)
The technical IRC channels, for example; the WMF doesn't "own" those. Ironholds (talk) 14:36, 21 August 2015 (UTC)
Indeed, which also means it can't legislate over them. Hence the statement "this applies to spaces outside of WMF resources" appears to be an oxymoron. Nemo 16:45, 10 September 2015 (UTC)
Not in the slightest; sure, you can't kickban someone from IRC for creating a tremendously harassing experience for contributors (well, not necessarily, although I'd like to think the channel admins would do something about it) but you can absolutely factor that into whether they get to wander around other spaces when they've demonstrated that kind of behaviour. Ironholds (talk) 20:31, 11 September 2015 (UTC)

Another membership proposal

I'd like to propose a self-perpetuating committee, boot-strapped by the Engineering Community Team (ECT).

  1. We open up self-nominations (if you think someone would be a great candidate, you can ask them to self-nominate). These self-nominees can make a statement up front.
    As part of self-nominating, each nominee must agree to comply with the full code of conduct, including the Reporting and Enforcement procedures. Mattflaschen-WMF (talk) 23:55, 31 August 2015 (UTC)
  2. People would then comment on nominations, both publicly and by emailing ECT (as they prefer).
  3. ECT consults with Community Advocacy on the candidates. The past behavior of the candidates should be in the spirit of the Code of Conduct.
  4. The ECT will then select five candidates, considering their involvement in the community, background, and experience that would inform their Committee work (if any; this is not a hard requirement).
  5. Every 6 months, the Committee will vote on a new Committee to replace it (Nominations are opened one month before this month; re-nominating yourself is allowed). Majority approval (3/5) of the overall slate is required, but unanimity is encouraged if possible. Re-selections are possible, but no one can be on the Committee for more than 12 consecutive months, unless the Committee unanimously agrees that an exception to this is necessary because suitable new candidates are not available.
  6. ECT can remove Committee members, but this should be only be exercised in case of severe problems.

It is required that the Committee can never be 100% WMF staff, and it's encouraged to choose various affiliations.

I think the main benefit here is that the Committee will have some knowledge about the community, and problems we face, so they can use that to help inform their decisions on the next Committee. Mattflaschen-WMF (talk) 04:23, 21 August 2015 (UTC)

I find this proposal a starting point more interesting than candidates + votes, a model that I don't think suits well for this committee. Some comments.
  • Self-nominations or just open nominations? I think it is everybody's interest to see as many potential names as possible. Some people might discover that they are considered good committee candidates only after someone else sends an open invitation to a mailing list (happened to me once, ended up in the GNOME Foundation board even if I had no preconceived plans for it).
    • With open nominations, someone can suddenly nominate you, opening you to a possible flood of negative feedback. Maybe you didn't want the position anyway, or not now but maybe later. If so, you're forced to read all that negative feedback about how you'd be bad at a position you don't even want. Mattflaschen-WMF (talk) 20:31, 2 September 2015 (UTC)
      • Additionally, if you do want it later, declining the nomination once can be used as evidence of disinterest. --Fhocutt (WMF) (talk) 03:06, 3 September 2015 (UTC)
        • OK, self-nominations have been added to the draft.--Qgil-WMF (talk) 09:53, 3 September 2015 (UTC)
  • I don't see why ECT / CA should have such privileged role. We shouldn't receive private positionings about candidates (anonymous comments on-wiki work fine), we shouldn't decide (the community should, and the own candidates nominated should). If we have, say six candidates but only four of them look like having wide support, I'd rather start with these four, allowing them to fine tune the team whenever it's time to refill/renew.
    • Given that we're accepting private email feedback for the CoC itself, why can't we accept it for candidates? This proposal gives ECT and CA a role in the first committee because right now, they probably have the best knowledge of conduct issues in the tech community. Once the Committee is up and running, probably the Committee will have the best knowledge of that (hence why the Committee elects its successors). Mattflaschen-WMF (talk) 20:31, 2 September 2015 (UTC)
      • Yes, precisely. There is no reason to require someone to post about their negative experiences with a candidate on-wiki, where their story and reactions will be picked over and discussed at length, in order for that information to be taken into account by those choosing. I know that Community Advocacy knows a lot more about various bad actors than I ever want to, and a lot more than is appropriate to ever post on-wiki. I value that knowledge and want there to be a way for it to be taken into account when the committee is chosen. I think that asking ECT to use their trusted position to help bootstrap the committee is very reasonable. --Fhocutt (WMF) (talk) 03:06, 3 September 2015 (UTC)
        • Mmmok. So private feedback about candidates will be provided. Still, we are mixing private channels here. Private reports about CoC violations will go to the committee. Private feedback about candidates will go... where exactly? The committee yes/no? ECT yes/no? I'm reluctant to include CA or anybody else, just to avoid them an automatic new responsibility (they have enough) and to assure to the senders of private feedback a small cosy audience. If ECT feels like sharing/asking more information to CA or whoever, we can, keeping the privacy barriers as needed.--Qgil-WMF (talk) 10:01, 3 September 2015 (UTC)
          • @Qgil-WMF: Private feedback on candidates should go to whoever chooses the committee. If we go with some version of the above, ECT will choose the first committee (and thus get the first round of private feedback). The committee itself will choose its successor committees, so it should get the private feedback for those rounds. Mattflaschen-WMF (talk) 03:50, 9 September 2015 (UTC)
  • Reopening the membership every six months sounds unnecessarily demanding. Becoming a good CoC committee member probably takes longer than that even if you already are a good candidate.
  • Why forcing someone to leave after 12 months? There are no strong reasons to remove a member if they want to stay and everybody is happy about them. I don't even think we would have enough good candidates for such refresh rate.
    • We could consider tweaking the timeline. Maybe elections every 12 months, max duration of 2 years. There are a couple reasons for this idea: Avoiding burnout, and making sure the committee continues to represent the whole community without being too identified with individual people. Mattflaschen-WMF (talk) 20:31, 2 September 2015 (UTC)
    • Burnout is a serious concern for positions like these, and people tend to stay in them out of a feeling of obligation even as they become less effective and more burnt out. Having a mechanism that forces members to reconsider and take a break is a good thing, although I'm open to different implementations. --Fhocutt (WMF) (talk) 03:06, 3 September 2015 (UTC)
      • What about bootstrap + 12 months + changing at least one member every six months, and leaving to the discretion of the committee to change more positions in every refresh? Looks like a good compromise between continuity and change. Other than the principle of at least one change every 6 months, I don't think the CoC needs to get into details such as 3/5 votes for approving new members. The committee should be entitled to decide the best way to renew itself.--Qgil-WMF (talk) 10:07, 3 September 2015 (UTC)
        • @Qgil-WMF: Can you elaborate on your proposal? Does "12 months" mean elections every 12 months? If so, how would a member change every six months? Are you suggesting staggered terms? I recommend we do specify the rules for the committee electing its successor. This is a substantive issue. I assume you don't want 2/5 or 1/5 to choose the next committee. So the question is whether it should be 3/5, 4/5, or 5/5. 4/5 and 5/5 are supermajorities. The well-known downside is that supermajorities allow a minority of the committee/parliament to control all forward progress. E.g. if the committee required elections to be unanimous (5/5), any one committee member could block the election unless their friend was assured a seat in the next committee. Mattflaschen-WMF (talk) 03:57, 9 September 2015 (UTC)
          • I mean 12 months in the first term, then always 6 months -- see #Bootstrapping the committee. I still think "trust the committee" is a better principle than trying to define numerical rules in advance. A committee trusted to enforce the CoC should be trusted to handle its own functioning. If a specific committee cannot be trusted on the latter it probably won't be trusted on the former, and we will have a bigger problem than supermajorities anyway.--Qgil-WMF (talk) 17:39, 9 September 2015 (UTC)
We have the model of the Architecture committee, which is similar to this case (experience, trust, complex issues...) The CoC committee should be transparent in their initial formation and their renewals, but other than that I think a model based on empowering the committee to maintain themselves will work. If the committee misbehaves there will be crisis and loss of trust, and if that happens then we will surely discuss how to move forward.--Qgil-WMF (talk) 09:52, 2 September 2015 (UTC)
  • On the capacity of ECT to remove members, I don't think this is a good idea. If a committee member deserves to be removed, the case should be clear enough for the committee fellows to take action. If ECT wants to remove a member when the rest of the committee is opposing, that means that we all have a deep problem that no rule will solve.--Qgil-WMF (talk) 10:33, 3 September 2015 (UTC)
  • On the permanent seat for an ECT member (something not mentioned in this proposal but discussed elsewhere without a clear conclusion) I still firmly think that ECT should have no privilege. If one of us wants to go for it, then self-nomination and selection should be the process like for anybody else. And if an ECT member is in the committee but for whatever reason it is thought that it is better to leave, the process to refresh seats every six months could be used for that.--Qgil-WMF (talk) 10:33, 3 September 2015 (UTC)
    • The Engineering Community team members agree that ECT should not have a permanent seat or power to veto committee members.--Qgil-WMF (talk) 01:02, 9 September 2015 (UTC)
      • Okay. I do think there needs to be a way to remove members, for very serious problems. However, I agree that in most cases, it should be sufficient for the committee to do so. I've added this (requiring a supermajority because unlike regular elections, removing someone mid-term isn't something that should be required often). If this isn't (e.g. the committee is turning a blind eye to one of their members), a procedure could be developed then. Mattflaschen-WMF (talk) 04:16, 9 September 2015 (UTC)
        • I also think we need to allow resignations mid-term, so I've added that. Mattflaschen-WMF (talk) 04:18, 9 September 2015 (UTC)

Next steps

We need a bit of organization. Even when the discussion is being shared basically by just a few people, it is becoming harder to follow and get involved productively (even more for volunteers with little time available). The goal of this exercise is to draft a proposal of an enforceable Code of Conduct to be approved by the Wikimedia technical community. We can slice the drafting in modules, allowing for a lighter process of discussion and consensus:

  1. Intro + Principles + Unacceptable behavior define the scope of this CoC, and have an intrinsic value. If those of us active in this Talk page now focus on these points, we should be able to reach a level of agreement good enough to send a proposal to wikitech-l.
  2. A new section "Committee" (that I will create now unless someone is faster) comprising all the details about this committee will need some more iterations. We can work on it while the community has time to discuss the points above. Hopefully by the time that the points above are stable and clear, we could share our proposal about the committee to wikitech-l.
  3. With the previous points on its way for agreement, Reporting, Appealing, and Enforcement should be relatively simpler to deal with, as they are mostly a matter of process. Once we have a draft we are happy with, we would share it with wikitech-l, adding that this is the last chunk of the CoC and we are seeking general consensus for the approval of the entire document.
  4. The CoC would become official as soon as it is approved. Then we would proceed to the creation of the committee.

The trick here is that the most active contributors to this discussion would focus on the topics that need more urgent approval, leaving he rest for later. Sporadic contributors can comment anywhere, of course.

There have been some comments about a self-selection (for a lack of a better word?) of people participating in this draft, in this discussion page, and in the related threads in wikitech-l. In order to help capturing a wider range of opinions, we could offer an email alias i.e. coc-discussion wikimedia.org that would relay emails to, say, three identified people that will commit to treat this feedback with confidentiality and channel the contributions received to the public discussion. Three is big enough to be reliable (a single person might miss an email, be away, etc) and small enough to maintain personal trust.--Qgil-WMF (talk) 08:36, 21 August 2015 (UTC)

I really like this proposal. One implication it has, though, is for the approval process; the problem with a consensus-driven approach is that it is very hard to identify the trend of agreement or disagreement when confidential feedback or disapproval or approval is being factored in. What are your plans for dealing with that? Ironholds (talk) 14:34, 21 August 2015 (UTC)
I like this staged approach, although I share Ironholds' concerns about how to make consensus (or its lack) apparent. I do think that offering the opportunity for anonymized input is important in this discussion. --Fhocutt (WMF) (talk) 00:53, 22 August 2015 (UTC)
I think anonymized feedback can still be taken into account in reaching consensus, as long as it is posted to the page (in anonymous form). Mattflaschen-WMF (talk) 22:53, 23 August 2015 (UTC)

I also like this plan—it isolates what seems to be the hardest part of the discussion: the composition of the Committee. Ironholds: I think there are two routes we could take to deal with confidential feedback:

  1. Have the trusted parties channel it into the discussion, but have it impact the discussion by (hopefully) affecting the positions of the people taking part directly.
  2. Allow people to send their positions anonymously to the trusted parties, and have those parties paraphrase it, confirm that the senders haven't !voted publicly in the discussion and have some basic level of involvement in the Wikimedia technical community (I don't think this should be high—for example, a preexisting Phab account should be sufficient, even if it hasn't commented), and add it to the discussion on the same level as an identified comment.

I lean towards 2, personally.—Neil P. Quinn (talk) 06:39, 22 August 2015 (UTC)

I like 1 better. I appreciate that some people may be reluctant to publicly state their positions, but I think its important to make sure that their is no question about the community support for the proposal (In order to ensure the entire community feels bound by it), and part of that is being able to verify that the vote isn't being controlled by a sock puppet army. Bawolff (talk) 07:23, 23 August 2015 (UTC)
@Bawolff: I did think about that, so in option 2 I mentioned that the trusted parties receiving the anonymous feedback would take some basic steps to guard against sockpuppets (essentially the same steps that anybody would take take when checking public comments): checking that the sender has a Phab/mediawiki.org account that predates the discussion and that they haven't already commented. Do you think these wouldn't be enough?—Neil P. Quinn (talk) 18:09, 23 August 2015 (UTC)
Its more I would like to err on the side of caution. Its a complicated issue, I'm not 100% sure where I stand. Bawolff (talk) 19:27, 23 August 2015 (UTC)
It's not trivial to cross-check someone's email address with their MediaWiki.org or Phabricator account. First, some accounts don't even have email addresses associated (but the anonymous feedback might still come from an email). Even if there is an email associated, you would need to use Special:EmailUser to send them a message to confirm the previous email came from them (otherwise, you don't know their email address and don't know if the from address of the original email was forged). Mattflaschen-WMF (talk) 23:45, 23 August 2015 (UTC)
OK, then let's start applying this sequence. About anonymous feedback, I think we should go for 1 as long as consensus is build through discussion (and not votes). If we decide to go for votes, then the scenario changes, but there should be enough time for anonymous feedback in any case. Good ideas are good ideas, regardless of where they come from. If they are influencing, so be it. The fact that such ideas come from a techie sockpuppet, someone alien to Wikimedia tech, etc, it doesn't matter. Considering that users can post here anonymously already (with an IP or a newly created account), users of the private channel would probably be people willing to make a point without having followed the entire discussion or without willing to pick a fight publicly.--Qgil-WMF (talk) 09:51, 24 August 2015 (UTC)
Who should be the three people publicly identified as recipients of coc-discussion wikimedia.org? Once we have the names Matt or I can create the request in Phabricator. We should offer this email address when sending our next email to wikitech-l (see #Proposing Intro + Principles + Unacceptable behavior so I hope we can go through this step quick.--Qgil-WMF (talk) 08:14, 26 August 2015 (UTC)
I am willing to be one of those people. Also, I suggest "conduct-discussion wikimedia.org", as abbreviations can be confusing. --Fhocutt (WMF) (talk) 19:09, 26 August 2015 (UTC)
No more volunteers so far? Then I will join as well. Two people are enough to get this started. I have requested the conduct-discussion wikimedia.org email alias to WMF Office IT and I have also CCed Mattflaschen-WMF, so he knows when this email address (the last blocker for the announcement) is ready.--Qgil-WMF (talk) 07:53, 27 August 2015 (UTC)
The email address is not yet ready. The privacy settings need to be adjusted. I will send out an announcement to wikitech-l when it can be used. Mattflaschen-WMF (talk) 00:28, 2 September 2015 (UTC)
The email address is now ready. Kalliope from CA has agreed to be a third person receiving the conduct-discussion emails. --Fhocutt (WMF) (talk) 22:04, 4 September 2015 (UTC)

Step 2 has started with Code of conduct for technical spaces/Draft#Committee (a new section with existing content) and #Proposing the Commitee section.--Qgil-WMF (talk) 08:48, 2 September 2015 (UTC)

Removal of commits and code

"Project administrators and maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, tasks, and other contributions that violate this code of conduct."

Are there processes/tools in place to remove commits from Git, and code or comments from Gerrit? As a maintainer, I have no idea how I would go about this. John Vandenberg (talk) 05:38, 26 August 2015 (UTC)

Messing with public git history causes significant problems. We should not be removing commits from git once they reach master, except in rather extraordinary circumstances. I think that making a new commit that reverts problematic things, and banning users as needed will have to be sufficient. Bawolff (talk) 05:46, 26 August 2015 (UTC)
Ideally, commits that violate this code of conduct would be rejected just like any other inappropriate or unworkable commits. If they make it in, I think that Bawolff's suggestion is a good way to move forward. --Fhocutt (WMF) (talk) 18:51, 26 August 2015 (UTC)
Added "revert" here. Mattflaschen-WMF (talk) 20:37, 27 August 2015 (UTC)
This is still a bit problematic. If there was a commit that changed code in a good way but personally attacked someone in the commit message, none of the required actions ("remove, edit, revert, or reject") are any use. --Krenair (talkcontribs) 20:57, 29 August 2015 (UTC)
The idea is that admins and maintainers have the right and responsibility to take action wherever something is wrong, within their possibilities and in a reasonable way. If a case is technically complex, the committee will have to find out the best compromise. I think the current sentence is just fine.--Qgil-WMF (talk) 14:14, 31 August 2015 (UTC)
It is already the case that the developer community rejects perfectly functional code because the commit doesn't meet agreed-on community standards. If I submit a JS patch that isn't written in the code style we've agreed on, it will be rejected and I'll be asked to make those modifications before it can be merged. I don't see why this hypothetical commit couldn't be similarly rejected until the entire commit (message, comments, code) meets these standards. --Fhocutt (WMF) (talk) 22:09, 4 September 2015 (UTC)
I came in to read and support the current wording but found this sentence to be a bit problematic. I think what is better is rejection of unmerged / future contributions vs. removing already accepted contributions. The wording is ambiguous on that note and removal, especially of code where already merged can cause more disruption. Could this be reworded to indicate that all unaccepted / future contributions are what will be removed? Or, thinking about this clarified? SSastry (WMF) (talk) 15:55, 10 September 2015 (UTC)
I agree with everyone above that this sentence is particularly problematic and basically impossible. Nemo 16:27, 10 September 2015 (UTC)
What about "Project administrators and maintainers have the right and responsibility to take action on any communication or contribution that violates this code of conduct."? Shorter, clearer, with the same meaning, and flexible about the best way to solve each situation. There will be a reporting process and a committee to deal with unclear cases.--Qgil-WMF (talk) 22:09, 10 September 2015 (UTC)
Quim, Works for me. SSastry (WMF) (talk) 23:45, 10 September 2015 (UTC)

Qgil, that is less problematic, but IMO it is more vague. I think it is helpful to articulate that +2'ers are expected to ensure that 'commit messages, code comments, etc., are part of this responsibility. I would say this +2'ers responsibility is heightened as inaction will result in a policy violation being baked into a VCS where hiding the violation is technically not desirable. Commit messages for example can be written to include quite snarky criticism of pre-existing code, and the original author may feel it is 'personal attacks', 'offensive', or 'derogatory' - these terms are not defined by this policy, so can be interpreted by each party in a dispute quite differently in order to create quite different perspectives. If (when) it happens, this policy also needs to be clear that 'project administrators' and maintainers not are not expected to rewrite the VCS history because they, or someone else, believes this policy was violated in a commit...

I think we should split this component into 'preventative actions' and 'enforcement'. In this "Unacceptable behaviour" section, it should only talk about preventative actions. i.e.

"Project administrators and maintainers have the right and responsibility to take preventative action on any communication or contribution that violates this code of conduct [by the technically available means such as editing, reverting, or removing depending on the norms of the virtual space.]?"

Then under "Enforcement", more permanent and invasive solutions may be considered as required, depending on the circumstances. If a commit message is really nasty, and somehow slipped into a repo, merely punishing the committer and merger doesnt make newcomers feel more safe about their code not being ridiculed, permanently, forever, without recourse.... If we cant go all the way, beyond 'comfortable' to actually removing commits if that is the appropriate response, then git commits (and by inference Gerrit) is not really covered by this policy, and this policy shouldnt claim it covers that space.

Will a repo be pulled offline and refactored if required? If not, are we being serious about this? John Vandenberg (talk) 03:02, 12 September 2015 (UTC)

Speaking only about the "Unacceptable behavior" section, I think the sentence I proposed is clear and accomplishes its basic mission in that section, explaining that it is OK to take action when unacceptable behavior occurs. In your sentence, I don't know what "take preventative action" means in practice. On the enforcement part, I'd rather not go there before finishing Committee (sorry, nothing against your argument, just a problem of mental bandwidth).  :) --Qgil-WMF (talk) 01:57, 13 September 2015 (UTC)
If a commit comment is really nasty, I am sure we would find a way to remove it. But it's probably better to keep this document focused on preventing abuse similar to what has actually happened (here or at other organizations), not preventing abuse that could theoretically happen but is unlikely to. --Tgr (WMF) (talk) 02:05, 13 September 2015 (UTC)
I agree with this whole comment. Mattflaschen-WMF (talk) 01:06, 17 September 2015 (UTC)
By preventative action (and appreciate that isnt necessarily the best term), I refer to immediate actions that can and should be taken in response to possibly problematic contributions. i.e. actions taken even without a complaint, as a way of raising the bar and defending each other. e.g. an edit or revert in most online spaces is relatively easy, can be done by anyone, and sends a strong signal about appropriate conduct. Also hiding content is usually a tool available to highly trusted members of a community, and if so it can be used to limit the damage/impact done by an inappropriate comment added by someone.
On the flip side, 'remove' has an irreversible feel to it, and should be done only after the committee has made a determination after having seen the evidence first hand. (happy to push this aspect out to a subsequent discussion, later.). Maybe the simple fix to this section is to remove 'remove' from this sentence, and replace it with 'hide'. While 'hide' is not possible with git, it is therefore less problematic in this sentence because it is clearly not possible, rather than a self-imposed limitation like 'removing a commit' which can be done but people consider to be 'not do-able'. John Vandenberg (talk) 03:06, 13 September 2015 (UTC)
I would be fine with any of the four:
  • "Project administrators and maintainers have the right and responsibility to remove, edit, revert, or reject all comments, commits, code, wiki edits, tasks, and other contributions that violate this code of conduct." (version under discussion in the consensus section). This provides enough discretion. E.g. if the commit message was the problem, but it's not a super-egregious case like doxxing where a repo rewrite is required, the maintainer can verbally reject it by making clear it's unacceptable and reporting it to the committee.
  • "Project administrators and maintainers have the right and responsibility to edit, revert, reject or hide any comments, commits, code, wiki edits, tasks, and other contributions that violate this code of conduct." (current version). This is close enough to #1, but implies the fact that content can be un-hidden (though this is rare for e.g. suppression).
  • "Project administrators and maintainers have the right and responsibility to take action on any communication or contribution that violates this code of conduct." (Quim's text above, gives reasonable discretion while still allowing committee to take further action if needed).
  • Project administrators and maintainers have the right and responsibility to take action on any communication or contribution that violates this code of conduct, by means such as editing, reverting, or removing depending on the norms of the virtual space (variant of John's proposal).
Like I said, I think the version previously proposed for consensus is good enough, but if people coalesce around one of those, we could propose it as a final change in the next (and hopefully last) round for this section. Mattflaschen-WMF (talk) 01:06, 17 September 2015 (UTC)
My proposal has the simplest wording while keeping the same scope and possibility of enforcement. There are many sentences in this CoC where we are choosing to be more exhaustive mentioning cases, which is fine for a single sentence but makes the whole CoC pages a lot more complex to read and understand when done systematically.--Qgil-WMF (talk) 05:35, 17 September 2015 (UTC)

Proposing the Commitee section

Continuing with #Next steps, and now that #Proposing Intro + Principles + Unacceptable behavior is on its way for wider community feedback, let focus on the discussions related to Code of conduct for technical spaces/Draft#Committee. We have been discussing the Committee together with reporting and enforcement, so there is no clear cut. Related sections (with their subsections) include #Substantive v Procedural, #Membership of the committee and ECT's role, #Conduct Committee v Legal Counsel, #Protection of Conduct Committee members, #Governance, and #Authority/power of committee?.

Please do not discuss these topics or new ones here. Use the existing or new sections instead. Here we are only coordinating the work of proposing this section of the CoC draft to wikitech-l.--Qgil-WMF (talk) 08:45, 2 September 2015 (UTC)

I'm happy about Code of conduct for technical spaces/Draft#Committee, including the idea of not defining there the on-time process of #Bootstrapping the committee. If you have nothing to change based on the open discussion, we could call for wider feedback at wikitech-l and move to the next step (Reporting and Enforcement).--Qgil-WMF (talk) 01:09, 9 September 2015 (UTC)
@Qgil-WMF: I don't think it's complete yet. There is nothing about how the committee is initially formed (I think it's fine to have this in an appendix/separate document because it's a one-time thing, but I recommend it be put somewhere). There is almost nothing about the replacement elections. I'll go ahead and put some more text from my proposal, to address these issues. We can then discuss those changes. Mattflaschen-WMF (talk) 20:51, 9 September 2015 (UTC)
I've gone ahead and edited it. [1] [2]. Mattflaschen-WMF (talk) 22:50, 9 September 2015 (UTC)
@Qgil-WMF: I also think we should wait to send out #Committee to wikitech-l until we have consensus on the intro + Principles + Unacceptable behavior (the first thing we sent out). That helps accomplish our goal of not discussing everything at the same time. Mattflaschen-WMF (talk) 23:54, 9 September 2015 (UTC)
As a note for later, another related talk page section is #COI. Mattflaschen-WMF (talk) 21:22, 16 September 2015 (UTC)

Why do we need a code of conduct, or not

A code of conduct has a clear goal, according to en:wp "set of rules outlining the social norms and rules and responsibilities of, or proper practices for, an individual, party or organization". the discussion attracted maybe 5 WMF employees and 5 voluntary contributors. how many committers do we talk about? how many are employed and how many are hobbyists?

I don't know what this section is supposed to be. It sounds like (judging by your counts) you are summarizing existing discussion, but I don't know which one(s), since you didn't link to the sections. Mattflaschen-WMF (talk) 19:27, 9 September 2015 (UTC)

we do need a standard code of conduct

this is advocated by multiple persons from WMF, got positive comments from contributors from US, GB, IR.

currently it has no criteria defined why one needs it, and no success criteria. frightening is that linus torvalds, the person who successfully built by far the biggest developer community on this planet, growing since 25 years, having thousands of contributors, would not be good enough to participate. --ThurnerRupert (talk) 18:01, 6 September 2015 (UTC)
That sounds like a good argument for adopting the CoC to me. I have no desire to suffer abuse in order to contribute code. Kaldari (talk) 05:41, 7 September 2015 (UTC)
you do not suffer, and if you would know what to do even now. :) --ThurnerRupert (talk) 08:08, 12 September 2015 (UTC)
On en-wikipedia, at least, we have an expectation that the framing of this kind of discussion will actually represent the points of view they purport to be evaluating. Here are some reasons why I believe we need a standard code of conduct:
  1. Codes of conduct create a friendlier and less toxic community which is more likely to keep productive and collaborative people: Our goal is to build a representative, aspirational community - whether it's for our engineering community or our content community. That means a lot of people from a lot of backgrounds, primarily working as volunteers - and nobody likes being treated poorly, particularly for free. By having a code of conduct we have a set of rules for how users should conduct themselves, with a clear enforcement mechanism, which means that toxic individuals (or productive individuals with toxic behavioural patterns) can have their actions addressed in a clear and consistent fashion. The research that has been done about why people leave communities, or cease contributing as prominently, has commonly highlighted toxicity within that community's interactions as a reason. This helps address that.
  2. Codes of conduct create a friendlier and less toxic community which is more likely to attract people: like I said, nobody likes being treated poorly for free. The narrative of our community goes much wider than us because it is communicated by people who experience it to other people they collaborate with - other people who may be interested in collaborating here. A code of conduct sends a signal to potential contributors, particularly potential contributors from marginalised backgrounds (who are people we should be trying to attract because software is best when the experiences the programmers bring to it match the experiences of its potential users or current users) that we take creating a friendly and collaborative space seriously, and that they can contribute to our codebases with some assurance that they will not be treated horribly. This makes for a wider user base, a more representative user base; it makes for more code and better code.
  3. Our current approach is inconsistent and not working; we don't lack policies around behaviour, we just lack any consistency. Some venues have behavioural policies, some do not. Some of those policies specify who should enforce them, some don't. All of the approaches are totally different and pseudorandomly enforced. One of the criticisms levelled at this code of conduct is that it is "bureaucracy"; bureaucracy is what we have at the moment, with a dozen half-formed policies that apply in different areas in totally inconsistent ways. Arguing against this policy will not reduce bureaucracy; arguing for it, replacing those dozen half-formed and inconsistently enforced ones with a single policy, will do that.
This is not to say that a CoC is the be-all and end-all of creating a friendly space; it's not. Just because we have a policy setting out a minimal behavioural standard doesn't mean people will all turn into saints, or even that all people will internalise this standard. But social conventions come from a common understanding of what is acceptable and unacceptable, and standardised policies are a great way of communicating that understanding to people joining the community, as well as people already present - and that communication is how you create a convention. Ironholds (talk) 01:55, 8 September 2015 (UTC)
if we have half a dozen policies, please cite them and make them go away. if we have too much, add something seems not right. you say "create convention" - a community is about contributing, so the ultimate goal is to create a convention about it. this policy does not show how to create something, but how to do nothing. from the code of conducts standpoint there is no difference if i am here or not. i feel not valued. --ThurnerRupert (talk) 08:08, 12 September 2015 (UTC)
I'm afraid I don't understand the second part of your comment; we should create a convention around contributing? People are logically much less likely to contribute if they feel uncomfortable in a space. A convention that we should treat people respectfully, by extension, contributes to people, well, contributing. Ironholds (talk) 18:44, 12 September 2015 (UTC)
The success criteria is given right in the document: "an open and welcoming community" and "a respectful and harassment-free experience for everyone". I completely disagree with the idea that toxicity is required for a successful open source project. The reason the Linux kernel is well-known for this problem is that it's an outlier. No one writes news stories about people safely crossing the street, and no one writes about how an open source project is well-known for its healthy interpersonal dynamics; they write about the outliers. However, the projects with healthy dynamics are those that can most easily attract people and prevent them from leaving. Mattflaschen-WMF (talk) 19:41, 9 September 2015 (UTC)
how do you measure "open and welcoming community" or "a respectful and harassment-free experience"? --ThurnerRupert (talk) 07:58, 12 September 2015 (UTC)
Number of times harassment or other abuse happens? As for openness, it would be interesting to get a sample of new community members a few month ago and send them a poll about their experiences. --Tgr (WMF) (talk) 03:42, 13 September 2015 (UTC)

If we get into 2016 without a code of conduct for technical spaces (notably hackathons), we're cutting ourselves off to a bigger and bigger swath of the developer community. Many active and experienced developers have pledged to only attend events with codes of conduct and all developers (junior and senior) want to be able to volunteer time without being harassed. JSConf has a code of conduct, so does Rubyconf, jsconfeu, and many others (I can keep linking on request, but it'll get repetitive). We want people to do cool stuff with mediawiki. We want the people already making cool stuff with mediawiki to feel like they can belong to a community or participate at an event without harassment. Protonk (talk) 15:33, 13 September 2015 (UTC)

I agree. In particular, "all developers (junior and senior) want to be able to volunteer time without being harassed" gets at why we need a code of conduct for everyone, online and offline, staff and volunteer. (I would add that a code of conduct can make staff work more productively too). Mattflaschen-WMF (talk) 05:28, 17 September 2015 (UTC)

we do not need a code of conduct

it is anyway clear how to behave with such a small group. stop bureaucracy, users complain about it, invent a problem because we know the solution. nemo (IT), steinsplitter (DE), ThurnerRupert (CH).

there is no goal behind the idea. the most successful initiatives, the linux kernel, and wikipedia, have no code of conduct. they have both a person with predictable behaviour and a talent do delegate tasks. the linux kernel still has slim rules, while wikipedia created a lot, differing for regions and languages. --ThurnerRupert (talk) 17:41, 6 September 2015 (UTC)
The Principles section is 'a goal behind the idea'. The reasoning that good free projects don't have / don't need a code of conduct has no base. The Linux kernel has a Code of Conflict. Linux Foundation events have a Code of Conduct. Dozens of successful free software projects have a code of conduct.
'It is clear how to behave' is another argument with no base. This is true for most people most of the times, but the Wikimedia Tech community hasn't been exempt of conduct problems either. Inventing a problem? It is a fact that in many cases we haven't been able to deal with crisis properly. Those who invested more energies in a stronger conduct tended to keep their positions, those who didn't feel like joining / staying in fights moved aside or left. This dynamic is no fair per se, doesn't contribute to welcoming newcomers and to promote diversity.--Qgil-WMF (talk) 07:10, 7 September 2015 (UTC)
Also, what is the idea behind specifying the citizenship of people agreeing / disagreeing? Specially with the small sample we have so far. Aren't you counting citizenship of those who happen to work at the WMF? For what is worth I'm Catalan, Spanish passport, resident in Germany. And you seem to be missing UK / USA citizens that have questioned the CoC as well.--Qgil-WMF (talk) 07:20, 7 September 2015 (UTC)
+1 to Quim. Can you point me to where users have complained about the bureaucracy of "a set of guidelines on how to behave"? I've seen users complain about bureaucracy on Wikipedia, I've seen (and participated in! and helped write!) studies on that bureaucracy, but it has related entirely to the rules around editing content not around participating in discussions. The studies we have done have indeed shown the rules - around editing - to be very onerous and a primary source of people ceasing to edit. They have also shown a big chunk of those who cease to edit do so because they find the community unpleasant and unfriendly. IOW, this is the one type of policy that is actually targeted at why people stop contributing. I am happy to point you at the surveys that have been done. Ironholds (talk) 01:32, 8 September 2015 (UTC)
The goal has been explained on multiple occasions, including briefly in the Principles section ("the interest of fostering an open and welcoming community"). The Linux kernel does have a code of conduct. It takes a different approach from ours, but doesn't mean it's not a CoC. Wikipedia takes a different approach as well, but they do have Wikipedia:Civility and No personal attacks and other specific policies that together form a de facto CoC (there are some issues with Wikipedia's policies, but here is not the place to try to improve them). The MediaWiki technical community is no longer "such a small group", and people do not always just magically behave well. There are now hundreds of committers, and more sysadmins running MediaWiki, people participating on IRC and Phabricator, etc. This is not unnecessary bureaucracy and is not an invented problem. MediaWiki.org has few policies, but this is one we should have. Mattflaschen-WMF (talk) 19:29, 9 September 2015 (UTC)
"forstering a welcoming community" might be a goal, but the code of conduct is not the solution to this goal. while "how to handle conflict resolution" of linux is a clear goal, and the 20 lines make clear how to do it. code committers here are comparable. the linux foundation events code of conduct cited is very short, and the marketing person is handling the situation. here we tend to police, with lawyers. besides is is not comparable - as we have the friendly space policy for this. --ThurnerRupert (talk) 08:43, 12 September 2015 (UTC)
I don't see a need for these references to people's nation (steinsplitter (DE)) (we're not UN ambassadors). People can sign for themselves without these psuedo-signatures. Mattflaschen-WMF (talk) 19:27, 9 September 2015 (UTC)
why you do not make 50 non-WMF dev's sign here? if not, just forget about this page :) it sounds like you let yourself talk into something and now you feel you need to do it and have difficulties to admit that nobody is interested. --ThurnerRupert (talk) 08:43, 12 September 2015 (UTC)
What are the actual stats on the WMF/non-WMF breakdown of developers? Quim would presumably know. Your "it sounds like" section is frankly entirely supposition; a ton of people are interested. We wouldn't have hundreds upon hundreds of kilobytes of comments (some positive, some negative, sure) if people weren't. Ironholds (talk) 18:42, 12 September 2015 (UTC)
48 users edited the talk page. I count 23 WMF staff among them. (There are a few more users who only edited the subject page, or did not edit on the wiki but commented or left tokens on T90908, but they probably would not change the numbers by much.) --Tgr (WMF) (talk) 03:56, 13 September 2015 (UTC)
"why you do not make 50 non-WMF dev's sign here?" How would I make anyone do anything? Mattflaschen-WMF (talk) 03:23, 17 September 2015 (UTC)

a positive code of conduct could be of value

the technical space is perceived as arrogant and ignorant, despite the participants are not arrogant and ignorant. mails get not answered, tickets closed immediately or never, patches are not treated for years. as the WMF has 150 employees, and most of them are technical. a novel approach by WMF can sovle the problem: introduce a simple and effective code of conduct for its employees: make sure that somebody contacting via a technical channel leaves well served. for volunteers this code of conduct would be true as well but not enforced. pretty sure they will behave the same way. in 12 months time it can be judged if this helped, emails without answer, tickets, and patches can be counted. --ThurnerRupert (talk) 17:41, 6 September 2015 (UTC)

For what is worth, Wikimedia Foundation employees are already required to abide to a Code of Conduct policy. If you want to suggest improvements to it, I guess a good start would be its discussion page. In any case, your proposals are not related with conduct or misbehavior. If patches, tickets or questions are not all addressed with efficiency it is not because people are misbehaving or not having respect for others, it is basically a problem of resources, priorities, possibilities. If you think someone is interrupting collaboration flows on purpose, then this attitude falls within the Code of Conduct indeed. Tasks related to the problems you described but not to conduct problems: Goal: Reduce code review queues and waiting times, How to address the long tail of low priority tasks in active projects. If there are other areas you want to address (i.e. you mention mailing lists) then let's start the discussions in new tasks within the scope of the Engineering Community team.--Qgil-WMF (talk) 07:34, 7 September 2015 (UTC)
The fact that WMF staff do not regard themselves as obligated to respond to volunteer comments or questions is unfortunate and in my view both insulting and unwarranted, but it is unfortunately WMF policy [3]. I proposed a thought experiment to rectify that at meta:User talk:LilaTretikov (WMF)#A_bold_thought_experiment but while it remains WMF policy it would be interesting, to say the least, to have it in conflict with this code.
In passing, just to point out that mere mortals are not able to edit the WMF site page, so any discussion would have to be at meta:Talk:Code of Conduct policy. Rogol Domedonfors (talk) 11:15, 7 September 2015 (UTC)
Having a lack of capacity to respond to all volunteer comments and questions is not the same thing as having a policy about it. Regardless, I don't think it's actually relevant to the discussion here. Kaldari (talk) 22:21, 7 September 2015 (UTC)
They are indeed two separate things, and as the diff I provided shows, both are apparently true for the WMF staff. The relevance to this discussion is that exclusion, in the sense of shutting people out of discussion or ignoring their input, might be considered unacceptable conduct, as it is in the Community discussion linked to in a preceding paragraph. However, we are unable to include it in this code, as it is considered acceptable practice for WMF staff and hence, unless we are to introduce a two-tier structure at this point, for the entire technical community. Rogol Domedonfors (talk) 21:31, 8 September 2015 (UTC)
Not replying to emails is absolutely nothing like the "harassment and other types of inappropriate behaviour" on the list. Ironholds (talk) 23:02, 8 September 2015 (UTC)
Maybe so, but deliberately and inappropriately excluding a person or subgroup of people from a discussion or decision-making process is offensive, and has been reported as a form of misconduct, in the link I gave. However, it seems that consensus is not to consider including it as a form of misconduct under this code and I can see why. Rogol Domedonfors (talk) 06:27, 9 September 2015 (UTC)
People at the WMF have been working on integrating volunteer contributors better for a long time. Are we done working on this? No. You note we have ~150 paid WMF engineers. Some other top-10 websites have 1000's. I agree we should keep improving on the volunteer front. What you've given is not a code of conduct proposal, though. (As noted, WMF employees must already abide by a CoC). It's a proposal for a new way to prioritize work. It's important to remember we are juggling a lot of projects and priorities, so when you say "spend more time on A", you are also saying "spend less time on B". Mattflaschen-WMF (talk) 19:27, 9 September 2015 (UTC)
I agree that a positive statement of what we hope to achieve and how we intend to act, stated positively, could be a strong statement of our values as a technical community and a useful discussion in forming it. Experiences in other open source/open culture communities, however, have shown that it's not enough, and that including a procedure for accepting and handling reports is particularly necessary. --Fhocutt (WMF) (talk) 00:44, 10 September 2015 (UTC)
At this point I am not saying "spend more time on engaging with the community" (although in other places I have suggested ways in which that might be done), I am saying "since WMF has decided its staff will prioritise other things, this Code will have to reflect that decision". Regrettable, in my view, but there it is. Rogol Domedonfors (talk) 06:25, 10 September 2015 (UTC)
Rogol Domedonfors, I'm at loss at trying to understand what specific text you want to add or modify in the current draft. Please provide a patch. :) As several people has said in several places, the WMF doesn't have the capacity to reply everybody everywhere. This limitation is not used to discriminate some users over others based on gender, ethnicity, etc. It is not used to harass or lack the respect to some specific individuals or groups. It is not used for sustained disruption, interruption, or blocking of community collaboration. You are trying to mix one legitimate problem with another legitimate problem, but these problems are essentially different, and trying to mix both in a CoC doesn't help solving any of them.--Qgil-WMF (talk) 13:15, 10 September 2015 (UTC)
Qgil-WMF, this paragraph is about "positive code of conduct", so the whole text would need to be changed. you mention WMF has no capacity: there is only ten mail threads per month. there are 3000 new tasks in phabricator per month if i read the statistics right. i tried to figure out how many of them are not created by WMF. i perceive that WMF creates their own tasks, ignores mine. i do feel offended. the participating persons do not offend, it just is some "misunderstanding" on my side or tool deficiency. how is it supposed that i can test the result of this task, and how many tasks are created by WMF compared to community? especially offended i am by your ignorance of this task, it is affecting thousands of users. but of course you do not harass me, hehe. --ThurnerRupert (talk) 09:42, 12 September 2015 (UTC)
@ThurnerRupert: the links you provide show tasks where you are not being ignored as in 'nobody replies to me or seems to care' but as in 'nobody is working in the features I'm requesting'. There are thousands of open feature requests and most of them take a significant amount of time from a skilled developer. I cannot avoid if you feel offended but this, but really this conversation really falls well out of the scope of a Code of Conduct.--Qgil-WMF (talk) 01:38, 13 September 2015 (UTC)
I'm articulating what I believe to be the consensus, which is that although exclusion has been reported as a form of unacceptable conduct, we cannot include it here becuse of constraints on WMF staff. So I am stating the "patch" that I personally would prefer, namely to aqdd Deliberate exclusion of individuals or groups from discussion or decision-making to the list of unacceptble behaviours, would not be consistent with the consesnus here, and further that I regret that situation. Rogol Domedonfors (talk) 18:53, 12 September 2015 (UTC)
"Deliberate exclusion" can be unacceptable behavior in certain circumstances (if a person or group is marginalized for personal reasons, gender, race, etc) and can be accceptable in other circumstances (for instance, I don't have access to #security related discussions, only a small circle of contributors have access to them, and this is fine). I think it is interesting to include the concept of deliberate exclusion if we agree on the unacceptable/acceptable cases.--Qgil-WMF (talk) 01:43, 13 September 2015 (UTC)
I have yet to see a single example of decisionmaking that did not deliberately exclude people. "Everyone" cannot make a decision; a specified group can, and everyone outside that specified group is included. Our most inclusive decisionmaking process is probably the board election, and even that excludes everyone under a certain number of edits.
RD, I am sympathetic to what (I believe) you are trying to get at. I think the WMF too often replaces real inclusion into planning and decisionmaking with polite but ultimately meaningless pseudo-conversations. But when engagement is warranted and when it is unfeasible is very hard to decide; community attention is a finite resource, so is WMF staff time, decisionmaking processes must strike a balance between representing stakeholders and respecting expertise, and the costs of coordination grow exponentially with group size. Whom to include and whom to exclude is a hard decision that must be made case by case; I don't think the code of conduct is a meaningful tool to directly influence that.
And I believe that indirectly it might be able to help. I think a frequent reason for WMF disengaging is that many participants heap abuse on them when they do anything the least bit controversial. When you feel that anything you say will be used against you, and being open and honest only will only achieve that your words can be used against you more mercilessly, you are not terribly motivated to have discussions that include those people; and the alternative is usually excluding almost everyone. One of the main hopes I have about the CoC is that strengthening the norms for respectful and reasonable conversation will make the WMF engage more. --Tgr (WMF) (talk) 04:46, 13 September 2015 (UTC)

Archiving

I suggest that sections less than 36 hours old are hardly "stale". At least some of the sections archived are still active or at least have unfinished business. Rogol Domedonfors (talk) 21:25, 4 September 2015 (UTC)

Hey Rogol. I've unarchived some of the previously archived discussions - sorry for being over-zealous there. If you feel there are still-archived sections that have "unfinished business" please do feel free to yank them out. Ironholds (talk) 21:39, 4 September 2015 (UTC)
can you please unarchive the discussion if we really need this code of conduct? --ThurnerRupert (talk) 21:56, 5 September 2015 (UTC)
  Done Also, I agree that there is no rush in archiving discussions, especially when they aren't clearly closed (i.e. as in opener happy about a conclusion or a change). This page gets awfully long, but this is a reflection of the density of the discussion these days.--Qgil-WMF (talk) 12:16, 6 September 2015 (UTC)
Qgil, i cannot see the discussion why somebody would need a code of conduct? --ThurnerRupert (talk) 17:23, 6 September 2015 (UTC)

Case escalation

"The committee can also escalate complex issues to the Wikimedia Foundation's Engineering Community team, delegating the responsibility of their resolution." seems like kind of dangerous language. I wonder whether it strips authority/autonomy from the proposed committee and whether it unfairly absolves the committee of taking responsibility for handling complex cases. --MZMcBride (talk) 04:47, 9 September 2015 (UTC)

I don't think it strips any authority or autonomy, but it might be good to either explicitly state "and is tasked with creating policy to cover when this should be the case" or, well, just specifying under what circumstances it's the case. Ironholds (talk) 13:48, 9 September 2015 (UTC)
The idea is that ECT helps when it is called, and doesn't interfere if it is not called. The committee is in full control of the delegation, and no situation should imply a direct intervention of the ECT surpassing the committee. This is meant to be a tool for the committee (assumed to be formed mainly as volunteers) to avoid exceptional situations of high stress, not a tool for the ECT/WMF to intervene in major CoC-related issues. I think the current wording works, but better alternatives are welcome.--Qgil-WMF (talk) 17:46, 9 September 2015 (UTC)
I think that idea is fine, but let's get it written into the document properly. It should be explicit about who controls the delegation. --Krenair (talkcontribs) 18:55, 9 September 2015 (UTC)
@Krenair: I've made an edit that should make this even more clear. Mattflaschen-WMF (talk) 20:55, 9 September 2015 (UTC)
Thanks. I also went and removed references to 'escalate', instead preferring 'delegate' because the former implies that ECT is above the committee. --Krenair (talkcontribs) 20:58, 9 September 2015 (UTC)
And delegate implies the inverse. "Transfer"? Ironholds (talk) 21:21, 9 September 2015 (UTC)
I'm fine with 'delegate' (or 'transfer'). Mattflaschen-WMF (talk) 23:35, 9 September 2015 (UTC)
I agree that 'delegate' is better than 'escalate', and the whole sentence is clearer now.--Qgil-WMF (talk) 06:27, 10 September 2015 (UTC)
  • The ECT is also proposed as the Appeal body. How will appeals be handled if a case has been transferred to the ECT in the first instance? Rogol Domedonfors (talk) 06:30, 10 September 2015 (UTC)
  • Good question. I think appeals to ECT resolutions could go first to the Committee. If they still don't want to handle the case, then they should be able to transfer to an alternative body. While this situation is technically possible, I guess it would be rare and related to very strange or acute situations. Community Advocacy, I guess.--Qgil-WMF (talk) 13:27, 10 September 2015 (UTC)

Bootstrapping the committee

On the bootstrapping, I think we don't need to include the details in the CoC since this is a one-time process. Process facilitated by ECT OK, self-nominations with public and private feedback OK, trust on the ECT to make the call... OK, but if this is the case we will bring that decision as close as possible to the candidates and stakeholders themselves, ECT style. Basically what I'm saying is, if ECT is trusted to handle this bootstrapping, then you trust us to do it in the way we think it's best.--Qgil-WMF (talk) 10:33, 3 September 2015 (UTC)

Another detail proposed for the bootstrapping period is that the committee would be renewed for the first time 12 months after its creation (instead of six, to give time to the committee to consolidate).--Qgil-WMF (talk) 01:06, 9 September 2015 (UTC)
I feel like if you want people to "trust us to do it in the way we think it's best" you may need to give more verbose detail on what that looks like. For example, I'm not sure what "ECT style" constitutes. I'm reading this as:
  • Candidates will self-nominate and be discussed both publicly and (through feedback to the Engineering Community Team) privately;
  • The Engineering Community Team will select 5 of these candidates to sit on the initial version of the committee;
  • The resulting committee will sit for 12 months before beginning to cycle through its members, rather than the standard 6, to try and give some time for processes to be set up internally without a lot of turnover.
Is that correct? How long will be given for feedback? How long for nominations? Ironholds (talk) 01:21, 9 September 2015 (UTC)
Basically, ECT will facilitate when needed, but will aim for as much self-organization of candidates as reasonable. I would expect the first committee to be more the result of a conversation with/between candidates than a secret exercise where ECT meets alone behind closed doors and comes out with an announcement. Timeline... one month in total? First two weeks for nominations, feedback can come as soon as nominations are announced. The rest is correct, yes.--Qgil-WMF (talk) 02:01, 9 September 2015 (UTC)
Makes sense. If you haven't already you may want to talk to Maggie, who (amongst many other things) handled the last round of candidacies for the Ombudsman Committee). Ironholds (talk) 02:58, 9 September 2015 (UTC)
I put some stuff about this in the draft. Mattflaschen-WMF (talk) 23:06, 9 September 2015 (UTC)
@Qgil-WMF: I think it's fine for The ECT bootstrap procedure not to be in the main CoC, since it's a one-time thing. However, it is probably useful to have a separate page that describes it. Your proposal about new elections (after 12 months initially, 6 months thereafter) should be discussed here and go in the main CoC. Mattflaschen-WMF (talk) 20:45, 9 September 2015 (UTC)

Committee workload

In looking for volunteers to join the Committee, a natural question to be asked is what the likely workload would be. Does anyone have experience of similar codes in similar sized communities that might be a guide? Rogol Domedonfors (talk) 06:33, 9 September 2015 (UTC)

@Rogol Domedonfors: This is a good question. I've asked another open source project. Mattflaschen-WMF (talk) 00:01, 10 September 2015 (UTC)
I was lucky to get a quick response. They said, on average roughly 2 hours a month, but that it varied (both due to what was happening and how much time people have available). Of course, communities and situations vary (and they specifically noted that it was sometimes 0 hours, other times many more), but this suggests that on average it's not an overwhelming time commitment. There is also provision in the current draft for simpler cases to be dealt with by a single member, which allows some people to potentially take on a little more work than others (while still allowing the committee to override if needed). Mattflaschen-WMF (talk) 02:29, 10 September 2015 (UTC)
I'm also reaching out to some people with experience on these. --Fhocutt (WMF) (talk) 00:49, 10 September 2015 (UTC)

Renaming to Developer Relations team

I assume that all references to Engineering Community Team should now read Developer Relations team? That is, this is a change of name, or at least, the relevant functions have not been redistributed? Rogol Domedonfors (talk) 21:02, 13 September 2015 (UTC)

  Done Indeed.  :)--Qgil-WMF (talk) 06:31, 14 September 2015 (UTC)

Flow for this Talk page

Unless someone has a better idea, I will request the conversion of this page to Flow. When it comes to diversity of participation, any little help is welcomed. Our discussions here are being quite long and dense. I am familiar with wikitext conventions for discussions, but more than once I have found myself thinking whether I should indent with a colon, a bullet, or both, or spending extra time finding the exact point where I should add my comment. I bet many technical contributors will have a harder time watching changes about the topics they care in this page, following the conversation, and participating in it. Flow will help.--Qgil-WMF (talk) 22:09, 14 September 2015 (UTC)

That's not encouraging diversity, it's discouraging participation here by anyone who doesn't like Flow. The inappropriateness sees obvious from where I'm sitting. --Pi zero (talk) 22:58, 14 September 2015 (UTC)
  Done Fine. I disagree, but I'm not picking this battle.--Qgil-WMF (talk) 08:37, 15 September 2015 (UTC)
Not using Flow discourages participation by anyone who doesn't like wikitext ;-) The main advantage of Flow would be to add more structure to discussions (no infinite threading...) which helps to keep discussions focussed. I'd prefer Flow, but I also feel comfortable enough to contribute with wikitext. Valhallasw (talk) 09:03, 15 September 2015 (UTC)
No, thank you. -- (talk) 09:04, 15 September 2015 (UTC)

Is there a reason not to have both? Just create Talk:Code of conduct for technical spaces/Draft/Flow and everyone can leave comments in the way they prefer. --Tgr (WMF) (talk) 10:03, 15 September 2015 (UTC)

It is hard to follow this discussion in one Talk page (plus wikitech-l and Phabricator task, although we are doing better at redirecting discussion here). Following discussion in two parallel Talk pages doesn't make any sense. Never mind, let's move on.--Qgil-WMF (talk) 10:12, 15 September 2015 (UTC)

Body size

We don't have anything related to body size, or this falls under physical appearance? It is important to me since I was born with a medical condition that makes me super skinny and I was called names a lot in school and people told me horrible things that continues today, It never happened in mediawiki space but I can imagine the possibility Ladsgroup (talk) 08:22, 15 August 2015 (UTC)

There are only examples in this CoC. Harassment may be alleged for whatever someone believes is harassment which easily includes appearance, medical conditions or the perception of these (this is how the police explained their approach to me in the UK, i.e. it's not their job to interpret what is or is not harassment, they take seriously any complaint and document it for further action). -- (talk) 11:06, 15 August 2015 (UTC)
Yes, there's a reason it says, "Examples of harassment include but are not limited to"; it's meant to cover the most common issues, but it recognizes it might miss something. Let's go ahead and add body size, though, just for clarity. Mattflaschen-WMF (talk) 23:36, 17 August 2015 (UTC)
I changed "personal appearance, body size" to "physical appearance" as this seemed less awkward. --MZMcBride (talk) 02:43, 19 August 2015 (UTC)

this edit removed the explicit mention of body size, instead amalgamating it into "physical appearance".

While I understand the tendency towards brevity and efficiency, I think this is worth calling out. Body size makes a regular appearance in both tropes about engineers and harassment of people within technical spaces, with a frequency that most forms of "physical appearance"-based harassment do not. One of the things we are trying to do with this document is recognise that vagueness and catch-all terms in codes of conduct or behavioural guidelines tend to serve to provide wiggle-room when there is a violation, and that specificity is key to ensuring both that users are aware of what they are not permitted to do, and that community groups have a clear guideline to enforce that they can move on with confidence. With that in mind, and given the prominence of physical size as a trope and tool for harassment, calling it out seems perfectly sensible to me. Ironholds (talk) 19:30, 19 August 2015 (UTC)

I agree, especially given that Ladsgroup brought this up as well. I've put it back. Mattflaschen-WMF (talk) 21:29, 19 August 2015 (UTC)
I guess this makes at least the third case of attempting to address an unproven problem. Ladsgroup specifically stated that body size-related harassment had never happened in Wikimedia technical spaces to him. Similarly, there's no evidence of people encouraging other people to harass (Kaldari's suggestion above) or unwarranted rejection of patches (also discussed above). There seems to be a worrying amount of tilting at windmills here. --MZMcBride (talk) 02:12, 20 August 2015 (UTC)
If it didn't happen before that doesn't mean it won't happen and it doesn't mean it is not worth addressing in the CoC Ladsgroup (talk) 19:33, 20 August 2015 (UTC)
Would you tell a country where there had never been a bank robbery that there shouldn't be a law against it, since it's an "unproven problem"? Of course not, since everyone knows it happens in other places. Similarly, we know these problems happen in other similar places. Mattflaschen-WMF (talk) 23:43, 20 August 2015 (UTC)
Are you able to name such a country? --Nemo 06:42, 21 August 2015 (UTC)
Sure. Any new country, like South Sudan, on day 1. Sane countries don't wait for a well-known crime to occur, then pass a law against it. That would be silly. Mattflaschen-WMF (talk) 20:47, 23 August 2015 (UTC)
I asked an example and you're providing an axiom. The axiom is easily refuted, for instance the Kingdom of Italy adopted all laws of the Kingdom of Sardinia from day 0. The example is not substantiated and is highly dubious, given article 198 "Continuity of Laws and Institutions

" of the South Sudan 2011 constitution. Nemo 16:45, 10 September 2015 (UTC)

As I said, "Sane countries don't wait for a well-known crime to occur, then pass a law against it." You just proved my point. South Sudan adopted Southern Sudan's (region that was previously part of Sudan) laws exactly to avoid having to start from scratch. Waiting for South Sudan's first bank robbery to ban bank robberies would have been foolish, so they didn't do that. Why should we wait for a kind of harassment to occur to ban it, when we know it's happened elsewhere? Mattflaschen-WMF (talk) 21:13, 16 September 2015 (UTC)
As a general principle, I think it is better to be more explicit than implicit describing the types of harassment we want to address in this CoC. The first goal of this document is to prevent problems, and a good measure to prevent problems is to spell them out. Let's not get stuck in these details, a good enough list is a good enough list. If these lists need one item more or one item less, having this discussion will be a lot simpler when the CoC is approved rather than now that we have many fronts open.--Qgil-WMF (talk) 08:54, 21 August 2015 (UTC)
"body size" is mentioned in the original Contributor Covenant. Someone's body size can be hardly a relevant factor in any discussion at Wikimedia tech, and therefore it is reasonable to think that if it ever comes across, it will be off-topic. I see no strong reasons to remove it, and I would recommend it to keep it for now, and see whether it is strongly contested when we ask for wider community feedback.--Qgil-WMF (talk) 10:34, 24 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)

I have no intention of withdrawing the policy. The Wikimedia technical community is not part of Wikipedia. It's true that English Wikipedia has Wikipedia:Civility and No personal attacks, but we don't. There is no binding policy in this area for any online Wikimedia technical space. So far from having a "mass of rules" in this area, we have essentially none. Mattflaschen-WMF (talk) 05:09, 11 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. -- (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)
The CA team does not have the power to ban users from #mediawiki, #pywikibot, etc. Legoktm (talk) 23:40, 10 August 2015 (UTC)
Wctaiwan} has removed "not being productive". I think they're right we don't need it. It is from Bug management/Phabricator etiquette and I think the intention was/is to refer to cases where interpersonal problems or edit-warring were negatively affecting productivity, but it's true there are a lot of other causes of non-productivity, so it doesn't fit the policy as well as I would like. Mattflaschen-WMF (talk) 05:40, 11 August 2015 (UTC)
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. The policy doesn't do anything to threaten these forms of contribution. If you have ideas about an explicit appeal process, please make suggestions. Ultimately, though, any WMF employee is responsible to their manager and eventually the board. I doubt managers and the board would allow the kind of abuse by employees you're hypothesizing. The part about "seek to make our technical spaces a respectful and positive" is a preamble. As Bawolff noted, this policy does not apply to Commons (except maybe software development there, e.g. Common.js and gadget development). Mattflaschen-WMF (talk) 05:09, 11 August 2015 (UTC)
Hang on, so this Code does apply to Commons then as you have listed examples? Specifically as I have published some of my bot code on Commons, and I use commons to discuss technical issues of batch uploads, then those discussions are now retrospectively controlled by this Code. If this is the case then there needs to be a Commons policy proposal. -- (talk) 06:15, 11 August 2015 (UTC)
I said 'maybe'. This is still just a draft, and the draft does not mention Commons. I'll let other people weigh in on whether they would like to explicitly cover on-wiki code workspaces (like gadgets, etc.) (outside of MediaWiki.org) Mattflaschen-WMF (talk) 06:20, 11 August 2015 (UTC)
I hope the scope of the Code can be made completely unambiguous. Thanks -- (talk) 07:23, 11 August 2015 (UTC)
I am strongly opposed to this applying to individual wiki Common.js. I don't think we legitimately have the authority to make policy for non-tech wikis or any of their pages. If someone from a content wiki comes to mw.org asking for help, or a channel like #wikimedia-dev, then this policy should apply, but pages on individual wikis should be the province of that wiki (Or something agreed upon at meta). Bawolff (talk) 08:12, 12 August 2015 (UTC)
Consensus seems to be against it, and the current document already reflects that the virtual list is complete (there is no 'including but not limited' in the list of virtual spaces), so Common.js on other wikis (and similar things) is not included. Mattflaschen-WMF (talk) 21:31, 12 August 2015 (UTC)
It's utterly ridiculous that its inclusion was ever considered even remotely possible by anyone. --Nemo 07:32, 21 August 2015 (UTC)
i agree with nemo on the first sentence: stop it. why? the terms of use require clearly: "civility" elaborating it, including measures "We reserve the right to exercise our enforcement discretion with respect to the above terms." the discussion above shows imo only one thing: we have so many rules that even employees of the WMF have difficulties to know and understand them. the best is, the rules are nowadays written using so complicated language that we need a "human readable summary". if not humans, i am asking myself who else it could apply to and who else would read then the "real text". monkeys? computers? trees? --ThurnerRupert (talk) 01:55, 22 August 2015 (UTC)
This draft is far more specific than just saying "Be civil" or "Don't harass". There are many reasons we still need a Code of Conduct for technical spaces despite the Terms of Use, including:
  • The TOU do not define 'harassment' at all (even as a 'including but not limited to'), which means people may be unclear what constitutes harassment.
  • The TOU only addresses very specific kinds of disruption, while allowing other kinds.
  • The TOU is missing several specific provisions applicable to in-person events (of which there are now a fair number in the technical space), for instance regarding unwanted photography and unwanted attention.
  • The TOU does not address issues like offensive comments and personal attacks. It actually doesn't even require you to be civil. Both the summary and the in-text part about civility ("We encourage you to be civil") are not binding.
  • It has only narrow provisions about privacy (only forbidding violating the law, or soliciting information). There is nothing forbidding doxxing people in unethical but legal ways.
But perhaps most importantly, the TOU can only be enforced by the WMF, and only in very limited ways (mostly limited to bans and legal action). The Code of Conduct can address cases where action needs to be taken, but it either doesn't violate the TOU, doesn't require a ban, or doesn't rise to the level where the TOU would be enforced in practice.
This is actually explicitly what the TOU intends to happen: "The Wikimedia community and its members may also take action when so allowed by the community or Foundation policies applicable to the specific Project edition, including but not limited to warning, investigating, blocking, or banning users who violate those policies." You'll note the TOU also makes clear that warning/reprimanding (an important way of dealing with misconduct that doesn't require a ban) is primarily meant to be handled by local communities. Mattflaschen-WMF (talk) 23:11, 23 August 2015 (UTC)

I have re-read this section, and it seems that all concerns have been addressed in new versions of the draft except perhaps one: "Everyone has been complaining for years of the ever-expanding bureaucracy and mass of rules in Wikipedia(s), which frighten new contributors." -- says Nemo. Why a new contributor would be frightened by this Code of Conduct? New contributors agreeing with our notion of unacceptable behavior don't even need to bother about this CoC, unless they become victims of unacceptable behavior, in which case it will be use for them to know that this CoC exists. About "creeping bureaucracy", from the point of view of a Wikimedia technical contributor it is actually the opposite: follow this CoC and you will be fine with whatever terms, policies and guidelines exist about contributors conduct.--Qgil-WMF (talk) 12:59, 6 September 2015 (UTC)

Per en:Wikipedia:List_of_policies there are currently 57 policies on English Wikipedia, plus a bunch of global policies like the privacy policy and the terms of use. In contrast, the much more diverse tech space is governed by the privacy policiy, the friendly space policy, the Phabricator terms of use, the Labs terms of use, the development policy and the +2 policy. A comparison hardly seems reasonable.
(Also, it is a convenient and somewhat populist position to hate bureaucracy, just like hating politicians or big corporations or taxation. Yet for all of those things history repeatedly show that attempts to remove them end up very badly. (Common sense shows that, too. Imagine that we strike out all Wikipedia policies overnight. Can you see that being an improvement?) They can be done well or badly, but they all perform legitimate and vital functions.)
That said, it would be nice to see plans for the CoC eventually replacing the friendly space policy as there is a lot of overlap. --Tgr (WMF) (talk) 01:52, 13 September 2015 (UTC)

Consensus discussion on intro, "Principles", and "Unacceptable behavior" sections

"We pledge"

I still think that, in the "Principles" section, the "we" sentences -- "we pledge", "we are committed" -- should be rewritten. As currently stated, I would think these are meaningless at best, false claims at worst. Yaron Koren (talk) 15:40, 10 September 2015 (UTC)
    • I thought this had been addressed in this discussion. By approving this CoC, we as a community would be pledging and committing. If you think a different wording is needed, please create a section with your proposal. Meanwhile, that paragraph has gone through a good deal of review.--Qgil-WMF (talk) 23:47, 10 September 2015 (UTC)
      • It was addressed before, but without resolution, just like now. Yaron Koren (talk) 00:35, 11 September 2015 (UTC)
        • Yaron Koren, I have tried to think of a different wording trying to guess your thoughts and I'm incapable of getting anywhere keeping consistency. "We" is identified as "contributors and maintainers of Wikimedia technical projects". Pledge and commit are the basis of any Code of Conduct aiming to be an actual guarantee for anyone being harassed or disrespected. What decent alternatives are there? Not to pledge, not to commit? Provide a list of contributors that explicitly checked a box to pledge and commit, wishing you good luck not to get in trouble with the rest? :) Ideas welcome.--Qgil-WMF (talk) 02:17, 13 September 2015 (UTC)
          • Thanks for asking. Here's my proposed rewrite of the first two sentences:
"In order to make the Wikimedia community an open and welcoming one, it is important that we respect all people..."
"Participation in Wikimedia technical projects should be a respectful and..." Yaron Koren (talk) 15:37, 13 September 2015 (UTC)
  • @Yaron Koren: Please check the new version I'm proposing. I think it covers your concerns, and I simplified the wording altogether, keeping the meaning of the sentence. I have kept the verb "commit", because I think it is essential for any Code of Conduct (and the ones I checked all contain that word or equivalent). Committing means that we take seriously the "it is important that we respect" and the "should be respectful".--Qgil-WMF (talk) 10:06, 15 September 2015 (UTC)
  • It's definitely better, in my opinion, though I'm still not a fan of the "We are committed" line - it's a statement that can't be possibly be true. (And by the way, if every single person in the community were truly committed, there presumably wouldn't be much of a need for a code of conduct in the first place.) Yaron Koren (talk) 13:35, 15 September 2015 (UTC)
  • "We are committed" is used consistently in this Code of Conduct. If the CoC is approved by the community, then as a community we are committed. Like in any plural community, members are free to have their own opinions, and some will care more than others about this CoC. However, if someone is not committed to the extent of disrespecting or harassing others, then we as community commit to take action. Anyway, I think I see your point and I certainly see yours. I think we have approached positions compared with some editions back, and I hope the current wording is good enough to focus on other potential improvements.--Qgil-WMF (talk) 20:48, 15 September 2015 (UTC)
      • "It was addressed before, but without resolution, just like now." I don't agree with that. It was resolved as a compromise. You summed up as "It feels like this whole section could just be removed". Other people didn't want to remove it. After a couple changes, you acknowledged that some of your concerns with the Principles section had been met. In other places, the draft stayed closer to the Contributor Covenant. Mattflaschen-WMF (talk) 21:33, 16 September 2015 (UTC)
  • I expressed a concern, and it was half-alleviated. Is that a resolution? That's a matter of opinion. Yaron Koren (talk) 23:35, 16 September 2015 (UTC)
  • @Yaron Koren: From my perspective, this is how consensus and negotiation with the rest of the community goes. The current draft--which I am supporting--is certainly not my ideal draft. I don't agree with all the changes that have been made, but not enough for me to not support it overall. Is your remaining disagreement something that means you would oppose this generally, or is it something that you don't like but can live with? --Fhocutt (WMF) (talk) 19:27, 17 September 2015 (UTC)
  • I actually don't have a strong opinion about the document overall, one way or the other. Yaron Koren (talk) 01:26, 18 September 2015 (UTC)

I don't have a strong opinion either way but We the People-style pledges are pretty standard (the Open CoC has a good list at the end and every one of those has language like "we commit to" or "project X is committed to") and generally understood to express a common consensus and not literally the agreement of every single participant. --Tgr (WMF) (talk) HH:MM, 19 September 2015 (UTC)

persons employed discussing something applicable to developers, a nogo. besides this, there is no agreement beforehand to "do we need a code of conduct". additionally, there is no cultural awareness here, only anglo-saxon persons or persons employed there discuss for the world. there is no consideration of alternative models which might have a much higher impact, as eg "positive code of conduct" / "exemplary" / "living principled behaviour". the goal is not defined: is it to get more devs to write software? then the proposal is a miss. is it because the space is unfriendly? then the example cases are missing. for how many persons is this? if it is only for 10 persons, than it is overkill. should the code be short and easy? then it is a miss as alone the introduction is longer as other examples. --ThurnerRupert (talk) 07:05, 12 September 2015 (UTC)
  • You oppose this proposal simply because paid developers are involved in discussing it? Ironholds (talk) 18:45, 12 September 2015 (UTC)
    On the demographic front: that's a fairly specific example of intersectionality you're interested in right there. Yes, a lot of the supporters are staff, and a lot of them Anglo-Saxon staff - although not all, see Valhallasw's comment below. The support group does include a lot of British and American people - I also count people from Continental Europe, Russia and India in the support column. That's a pretty wide geographic distribution. It's not perfect, but it's important to remember that our technical community itself is biased towards Western Europe and North America, so I wouldn't expect to see a distribution of perspectives that encompassed the whole gamut of the human condition (indeed, creating a safe space hopefully moves us closer towards that being possible). Ironholds (talk) 20:14, 12 September 2015 (UTC)
    The rule "persons employed discussing something applicable to developers, a nogo." would mean that no WMF staff, or WMDE staff, or staff of MediaWiki consulting companies, could ever participate in crafting anything relevant to developers, from a security RFC, to a coding convention, to a conduct policy. I don't think anyone is willing to adopt that. Your statement that all of the people discussing were Anglo-Saxons, or persons working out of Anglo-Saxon countries is false (even when you made it). It's also a divisive and unproductive approach to the issue. If we're serious about diversity, we should honestly acknowledge the current state of our community. Our community is not in any way a cross-section of the world. However, looking at this discussion, I see a much better (though imperfect) cross-section of our existing technical contributors. Increasing our community's diversity will be a lot of work. A code of conduct is just one part of it, but it's a part we can't neglect.
    It is not true that "there is no consideration of alternative models which might have a much higher impact, as eg "positive code of conduct" / "exemplary" / "living principled behaviour"." See wmf:Code of conduct policy. It doesn't specify penalties, and is only binding for staff and board members. For everyone else, it is "intended to provide guidance". That is precisely a by-example (exemplary) approach, and it has failed to shape the overall technical community. You say the proposal will not "get more devs to write software", but are unable to explain why, when it's quite clear many successful communities like Django and jQuery think exactly the opposite. There are many examples of problem cases available on the Internet, and it is not appropriate to include them in the actual draft. "if it is only for 10 persons, than it is overkill." basically expresses the idea that 10 toxic people is acceptable. I fundamentally disagree with this, and where toxicity begins, more will develop. You have not cited any working code of conduct that is shorter than ours and meets our needs. It is quite clear that the Linux Code of Conflict (which you've cited elsewhere) would not meet our needs for many reasons, and it's very questionable whether it meets the needs of that community. Mattflaschen-WMF (talk) 07:23, 17 September 2015 (UTC)

Definition of maintainers

As a person who is still dubious about the effectiveness of a CoC, I nevertheless feel the need to bring some concerns here. As in the Contributor Covenant, terms such as "project administrators" and "maintainers" are not clearly defined; the definition of "unacceptable" as "inappropriate" is indeed tautological; and there is no reason why resolutions lasting less than 3 months may not be appealed. --Ricordisamoa 14:19, 12 September 2015 (UTC)
  • What is unclear about the definition of admins and maintainers? What wording would you prefer in reference to unacceptable/inappropriate? Appeal process is out of scope in this section; we will get there and I'm not convinced about that limitation either.--Qgil-WMF (talk) 02:08, 13 September 2015 (UTC)
    For MediaWiki, I don't think we really have "maintainers" in the way that many open source projects use that term. Now that Ricordisamoa mentions it, if someone asked me to enumerate the "maintainers" of mediawiki/core (or a section there-of), I'm not sure what I would answer. Perhaps the people with +2 rights, but that's not really the same as being responsible for a section of MW. Bawolff (talk) 05:39, 13 September 2015 (UTC)
    Sure, but maintainers is a term that we already use. Same with i.e. mediawiki.org administrators. Maybe not perfect but clear enough. What is the actual problem that these 'not clearly defined' terms would cause? Someone not sure whether they are a maintainer or an admin? Well, no problem, at the very least you can report the problem to the committee, and they will find out who is responsible in that context. Bottom line: I think the current wording of administrators and maintainers has a good foundation.--Qgil-WMF (talk) 10:49, 13 September 2015 (UTC)

COI

How the committee is formed interests me little, as I don't think we should have a committee (see above). As someone who has shared the responsibility of approving a code of ethics in an organisation way larger than our technical community, I recall that the main concern is generally conflict of interest, which must be avoided at any rate to prevent complete discredit of the policy.

Whoever decides on forceful enforcement (e.g. a block of a contributor) is disposing of movement resources (e.g. volunteer developer time), which also reminds us of m:Guidelines on potential conflicts of interest. For instance I would be uncomfortable if a WMIT (Wikimedia Italia) employee or contractor happened to "judge" a case involving another WMIT employee or contractor, as any outcome clearly implies (financial) interest: promoting the employer's interest affects renewal of a contract, vacating a job currently taken by an involved party affects employment opportunities in the organisation. --Nemo 07:28, 21 August 2015 (UTC)

Conflicts of interest are usual in community affairs, and there are ways to deal with it. Committee members have the same chances to have COI than stewards, sysops, WMF employees, and just any humans involved. Promoting diversity of affiliations in the committee and allowing committee members to disclose COI and step aside in specific cases should be enough to control this problem reasonably. Nothing new.--Qgil-WMF (talk) 09:51, 21 August 2015 (UTC)
This is a good suggestion. I've added a point about that. Mattflaschen-WMF (talk) 22:24, 23 August 2015 (UTC)
Thanks. "Members of the committee must not participate in a decision if doing so would place them in a conflict of interest." This is quite generic; I'd prefer the example I provided to be explicitly forbidden: «a WMIT (Wikimedia Italia) employee or contractor happened to "judge" a case involving another WMIT employee or contractor». Nemo 16:45, 10 September 2015 (UTC)
That seems like a highly specific example to use. Ironholds (talk) 20:31, 11 September 2015 (UTC)
I note that the quoted guideline says "The WMF staff and committees are required to serve the same mission, ultimately report to the WMF Board, and do not have competing interests." Presumably this applies equally to WMIT. Even though in this case they don't report to the same board (the committee would probably not report to any board at all), they still serve the same mission, so their goals are aligned. Derailing a legitimate misconduct claim against a member of a Wikimedia organization would hardly be in the best interest of that organization.
That said, I don't think a restrictive COI policy would do any harm, either. Worst case the committee could just defer to the ECT if too many members have recused. --Tgr (WMF) (talk) 01:26, 13 September 2015 (UTC)
Nemo: by analogy, would this prevent committee members who work or contract for the WMF from being involved with cases that involve other WMF employees/contractors? If so, I don't think that's practical. --Fhocutt (WMF) (talk) 20:42, 15 September 2015 (UTC)
Does anyone think that Committee members with a conflict of interest should be free to act? If not, what is wrong an explicit statement prohibiting it? Rogol Domedonfors (talk) 21:05, 15 September 2015 (UTC)
Nothing is wrong with such a prohibition. In fact, there already is an explicit prohibition. The questions are whether to provide an example (remembering that that example would only cover one of many possible issues), and what exactly constitutes a conflict of interest. Mattflaschen-WMF (talk) 06:09, 17 September 2015 (UTC)
The strong point of wmf:Resolution:Guidelines on potential conflicts of interest is to "disclose actively" conflicts of interest. The first step is that if any Committee or any Developer Relations member think they have a COI, they should disclose it. Common affiliation doesn't presume automatically a COI, just like different affiliation doesn't presume automatically lack of COI. As a Developer Relations member, I would definitely think to have a COI if a report is made by or against another DevRel member, but the same is not true for the +200 employees of the WMF. Following Nemo's argument, if a WMF specializing on PHP development is fired because of a resolution, I will hardly benefit from that since I'm not a candidate for their position. However, if that PHP developer happens to be a close friend, then I will declare COI because I might be emotionally biased. The same can happen if certain non-WMF people who are close friends end up involved in a report. It is relative, and the first step is to disclose the COI. Once disclosed, the Committee or DevRel (depending on who needs to handle the report) can decide what to do, most probably keep that person out of the process to play safe.--Qgil-WMF (talk) 22:46, 15 September 2015 (UTC)


Reports involving WMF employees

This is a spin-off of the discussion of #Conduct Committee v Legal Counsel related to Wikimedia Foundation employees and the discussed requirement to report to WMF bodies such as the Human Resources or the Legal team (or the managers of the employees affected, let me add).

It is a fact that the Wikimedia Foundation must follow the law of the State of California. If a WMF employee is involved in harassment or other illegal type of conduct, the WMF might start accruing liabilities since the moment such event happens or is reported. Other considerations alien to this CoC and Wikimedia tech such as whether the employee has a management role or not do have clear legal implications. As a WMF employee, being a witness of a harassment case involving another WMF employee and failing to report this to your manager or HR might also have implications that fall beyond this CoC. We need to consider these factors when defining how reporting works and how the committee works. Employees of chapters i.e. Wikimedia Germany might be in similar/different situations based on the similar/different laws they need to follow.

The point being questioned is that private reports are expected to keep their privacy, and reporting to WMF HR or Legal would hamper such privacy. Let's try to dissect the problem:

  • Not all reports will have a strict requirement for privacy. In many cases the potential abuse is logged in URLs publicly available, so there is not much secret around them.
  • Not all private reports will refer to behavior legally classified as harassment or another type of conduct with legal implications.
  • Not all private reports with legal implications will affect WMF employees, although it is unclear whether these cases should still be reported to WMF Legal, because they would be happening in WMF infrastructure or activities...
  • About private reports that might have legal implications, the committee should recommend to the reporter to share this case with WMF Legal (and HR if it involves WMF employees). The reporter wants a solution to this problem, this is why they are reporting, and these bodies have experience and tools to support the committee and deal with the problem beyond it. Needless to say, members of these teams (just like the managers of allegedly offending/offended WMF employees) have signed a work contract and an NDA that ties them to stricter rules about privacy than the own committee members.
  • While theoretically there might be situations where the reporter will want to share a problem with the committee but not with the WMF even if a WMF employee is involved, I believe in most cases reporters will be comforted by the fact that their reports involving WMF employees will be properly reported and escalated to the WMF when needed.

A point of flexibility here is the moment between the report to the committee and the decision of the committee to involve WMF Legal / HR or not. There is a risk for false accusations seeking escalation and trouble for an innocent employee, a form of harassment in itself. The committee could have a buffer to analyze reports before reporting them directly to the WMF. In fact, the process of escalation to the ECT already contemplated in the draft could be the step to follow: committee tells to ECT that this case involves WMF employees or might have legal consequences for the WMF, and ECT proceeds with the escalation.

Although this post is very long and the discussion might get a lot longer, when it comes to the draft I think we would only need to add something like

Reports involving employees of a Wikimedia organization as well as reports with potential legal implications to the Wikimedia Foundation must be shared with the Engineering Community team, who will consider the escalation to the WMF Legal or Human Resources teams.

--