Talk:Code of Conduct/Archive 4

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). --Fæ (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)

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)

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)

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. --Fæ (talk) 19:33, 8 August 2015 (UTC)

My reading of this policy is that it makes it possible for a WMF employee to choose to ban me forever from all the projects I am committed to as an unpaid volunteer - If we're talking about you personally, I'm not sure I see what you mean. Most of your activity is on commons, which unless I misunderstand severely, is quite out of scope of this policy. Maybe this policy applies to tool labs (Does it? Its not entirely clear on that point), which would probably affect you more significantly. It would apply to in-person events, but people could already be banned without much appeal from such events anyways, so this is not much new on that front. (On the more general point though, I agree, fairness in enforcement is an important issue that is being hand-waved). Bawolff (talk) 21:31, 8 August 2015 (UTC)

And I just re-read the policy. Since my last reading the line "The Community Advocacy team also has the authority to investigate behavioral issues and recommend WMF global bans for individuals." has been added. So I guess I see where your coming from more. Bawolff (talk) 21:33, 8 August 2015 (UTC)

You may need to read the policy again. The CA team has always had that power - this policy does nothing about that. What it does is set out behavioural guidelines for technical spaces. Your objection to the policy around it chilling volunteers ignores an important line from the actual policy; "a healthy amount of constructive criticism and vibrant debate helps to improve our software and is encouraged". This is nothing to do with critiquing software changes in the sense of the community giving feedback on new extensions or features; this is to do with how people behave on phabricator, on gerrit, on wikitech-l, and making sure we have a welcoming community. I agree, for what it's worth, that "not being productive" is a bit vague, and probably needs fixing up. Ironholds (talk) 17:15, 9 August 2015 (UTC)

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. --Fæ (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 --Fæ (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)

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-discussionwikimedia.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-discussionwikimedia.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-discussionwikimedia.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-discussionwikimedia.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 ^{(talk • contribs)} 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)

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.

--Qgil-WMF (talk) 10:36, 1 September 2015 (UTC)

Why can't we just ask the victim whether they are OK with it? See Geek Feminism: Responding to reports and 'Why didn't you report it'. If the report is always sent to HR, it is very likely it will dissuade people from responding -- WMF HR is not generally seen as a neutral entity, and many people will assume HR and Legal will act to reduce liabilities for the Foundation rather than trying to solve the issue at hand, which triggers all the fears listed in the 'Why didn't you report it' post. Valhallasw (talk) 14:39, 1 September 2015 (UTC)

Valhallasw, I agree. HR and Legal's jobs are, fundamentally, to protect the interests of the WMF. In many cases this should align with protecting the interests of vulnerable individuals, but I've heard from enough people who've learned the hard way not to trust their own HR departments that it is simply not reasonable to expect that all people who experience unacceptable behavior will be ok with that information being shared. The scenarios likely to be most concerning are when information is shared with HR, and retaliation occurs, or when information is shared with HR, HR acts, and the vulnerable person is blamed for HR's actions ("You got him/me fired!") and is now open to retaliation from that person or their friends/allies. There have been high-profile cases of both of these in tech within the last couple of years and it's not reasonable for people to blindly trust that the WMF will do better.

To be clear: I am not saying that I expect these to happen, or that WMF HR is incompetent or malicious. I do not expect coverups of major misconduct. I trust them considerably more than I've trusted HR at other orgs I've worked for. All that said, I still expect that if there is a situation where they have to choose between what's best for the WMF and what's best for me, there's a good chance they won't choose me.

At the same time, I see the arguments for having some way to involve HR: legal liability, and the question of what should happen if sanctions on an employee affect their ability to do their job. If a WMF engineer is banned from Phabricator for a week, that will affect their ability to carry out their work. If someone on Community Tech is permanently banned from Labs spaces, they won't be able to work on bots and tools and the scope of work available to them is suddenly much smaller. I think it's reasonable for HR to know about things that affect an employee's ability to do the work they are hired to do. I don't know how to balance that with targets' wishes and risk analyses.

I suspect there isn't a good answer here. I'd like to talk with someone from HR and Legal and hear what sorts of things they really need to know about, and see if there are existing confidentiality policies that can perhaps be adapted. --Fhocutt (WMF) (talk) 17:39, 1 September 2015 (UTC)

It's already theoretically possible to be banned from Phabricator/Gerrit/Labs/wherever permanently, and therefore lose the ability to do your job. I don't see why we need a policy stating that WMF HR needs to be informed now. Particularly, we should be careful to leave the actual decision to the committee (never their company), with just a notification of the outcome going to the affected person's HR department (whether that be at WMF or WMDE or some random other contributor's company). --Krenair ^{(talk • contribs)} 18:08, 1 September 2015 (UTC)

I agree that HR should not be able to influence the Committee's outcome in any way. But of course HR can take their own additional actions. Mattflaschen-WMF (talk) 20:10, 2 September 2015 (UTC)

+1. Ironholds (talk) 20:34, 3 September 2015 (UTC)

• So are we happy with the fact that the Code may conflict with the laws of the jurisdiction where the incident complained of took place? For example, in the UK it is a crime to publish the name of the complainant in a serious sexual offence, yet this is arguably mandated by the code. Whether or not there is a conflict in this specific case -- IANAL -- has WMF Legal explicitly considered what the effect may of conflict of laws and are they explicitly satisfied that their requirements are sound on this point? Rogol Domedonfors (talk) 21:31, 4 September 2015 (UTC)

  That's not true. IASOAL and what you're referring to is Section 5 of the Sexual Offences (Amendment) Act 1992. You might note, if you've read that section, that it provides a complete defence of anyone accused of violating it if the complainant has given written permission for the name to be published. Ironholds (talk) 21:50, 4 September 2015 (UTC)

  Excuse me, it is true, and Malcolm Blackman was fined £400 for doing so as reported in the London Evening Standard on Thursday 3rd September. As you point out there is a statutory defence to the charge which is not relevant here since the Code does not require the complainant to give written permission for the complaint to be made public, and I doubt that anyone would suggest that was a reasonable requirement. My question was addressed to the WMF Legal and unless "IASOAL" means "I am answering on behalf of the WMF Legal department" your response is somewhat irrelevant. The question is, have the actual lawyers in WMF Legal explicitly considered what the implications are for their requirements when incidents take place in other jurisdictions especially when the law of the state of California is in conflict? What we want here is a Code that encourages victims of harassment to speak up and protects their interests while not exposing the Committee to unncessary legal risks themselves. That requires careful consideration by Legal. Rogol Domedonfors (talk) 07:58, 5 September 2015 (UTC)

  Malcolm Blackman was fined for publicly identifying the person who said he raped her. That is not a remotely sensible comparison to make. Anyway, nowhere deos the CoC mandate identifying the complainant; in fact it states in quite clear terms that " All reports will be kept confidential. In some cases we may determine that a public statement will need to be made. If that is the case, the identities of all victims and reporters will remain confidential unless those individuals instruct us otherwise." This discussion has somehow become completely detached from the reality of the text. --Tgr (WMF) (talk) 02:12, 13 September2015 (UTC)

My question was addressed to WMF Legal and asked for explicit consideration of the question as to whether their requirements for reporting incidents to them might be in conflict with the legal requirements of the jurisdictions in which events of harassment might take place (bearing in mind that this Code covers in-person as well as on-line harassment). I gave as an example the legal situation in one country for one sort of crime: a serious example to illustrate the possible difficulties in a serious situation. The Code is already somewhat unsatisfactory in that the statement of strict confidentiality which you cite conflicts with the requirement to report to WMF HR in a range of cases. Your opinion of one specific case is somewhat irrelevant. In the absence of an answer from an qualified lawyer who has given careful attention to the implications of this requirement in the situation of conflict of laws, I think that it would be better for non-lawyers to refrain from giving their unqualified opinions on whether this part of the Code is legally sound. Rogol Domedonfors (talk) 06:49, 13 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)

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)

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)

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)

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 ^{(talk • contribs)} 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 ^{(talk • contribs)} 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)

Remaining catch-all

"Other unethical or unprofessional conduct."

I thought Quim and others had worked to reduce the ambiguity in some of the language from this section. This last bullet seems to be an open-ended catch-all. Should it be included? --MZMcBride (talk) 04:49, 9 September 2015 (UTC)

This sentence comes from the original Contributor covenant this CoC is based upon. I think it is fine to keep it. If a report is filed about other unethical or unprofessional conduct, then the committee will evaluate it anyway.--Qgil-WMF (talk) 17:51, 9 September 2015 (UTC)

I don't think we should really care about where it comes from, this needs to reflect exactly what we as a technical community believe is an appropriate rule, not what other people believe is an appropriate rule. I agree that it's too open to interpretation. @Qgil-WMF: Are you suggesting that the committee would deal with complaints outside the scope of the code of conduct? --Krenair ^{(talk • contribs)} 19:24, 9 September 2015 (UTC)

What if it was "other harassing or inappropriate conduct" to link it in more tightly with the narrative around that section as a whole? That way it makes clear that it's designed to cover behaviour in the same vein as what is explicitly laid out, even if the behaviour that occurs isn't - but also makes clear that the intent is not to ban someone from gerrit because they stole all the t-shirts at a hackathon (which would be unprofessional but probably isn't the Conduct Committee's business) I don't particularly think the conduct committee would ever lay claim to that kind of behaviour but I understand why people get apprehensive at catch-alls and this might tighten it up a bit. Ironholds (talk) 20:29, 9 September 2015 (UTC)

That's better, but I suspect it's already covered by "Examples include but are not limited to". --Krenair ^{(talk • contribs)} 20:33, 9 September 2015 (UTC)

I agree that "Harassment and other types of inappropriate behavior are unacceptable" plus "Examples include but are not limited to" already cover the scope of the CoC. Removing the reiterative bullet point contributes to give a small percentage of relevance to the remaining bullet points, so I went ahead and did it. I think the result is slightly better, with no loss.--Qgil-WMF (talk) 06:33, 10 September 2015 (UTC)

I read this as imparting some flexibility and space for discretion on the committee's part. Rigid policies invite rules lawyers. --Fhocutt (WMF) (talk) 00:48, 10 September 2015 (UTC)

How is "Examples include but are not limited to" rigid? --Tgr (WMF) (talk) 02:41, 13 September 2015 (UTC)

The "inappropriate" and "unwanted" lines are still catch-all phrases that are not really helpful. "Unwanted" is meaningless unless we expect contributors to have the ability to read minds, and anyone willing to engage in conduct they deem to be inappropriate will not be deterred from it by a CoC asking them.

If "unwanted" is meant as doing something after you have been told it's unwanted, we should say so. Something like "Engaging in personal communication, following, physical contact (sexual or otherwise), photography or other recording that the offender has been made aware is not wanted"?

As for inappropriate:

• is there appropriate use of sexual language/imagery? All the high-profile cases I can think of involved completely innocent use of sexual imagery, such as showing a girl in a bikini as a transition between slides; but most involved seemed to agree that it was inappropriate. The safe approach is probably to not use such things at all, unless it is necessitated by the subject of the discussion (e.g. when talking about a profanity filter or an explicit content warning feature). So maybe replace it with "unnecessary use of sexual language/imagery"?

  I have changed "inappropriate" for "gratuitous or off-topic", which is clearer and more precise, borrowed from http://todogroup.org/opencodeofconduct/ --Qgil-WMF (talk) 11:01, 13 September 2015 (UTC)

• I don't think there is such a thing as inappropriate but wanted following/phyisical contact/etc. so just saying unwanted should be good enough there.
• Inappropriate communication is probably already covered by the other points; if not, those points should be expanded instead.

--Tgr (WMF) (talk) 02:41, 13 September 2015 (UTC)

I disagree that we need the ability to read minds to know what is unwanted, even before being explicitly told. Social conventions define defaults for wanted/unwanted. These defaults can be definitely fuzzy and different across cultures etc, but they exist and are quite common in many situations related to i.e. sexual contact or stalking. I would also simplify "Inappropriate or unwanted" in simply "Unwanted" to make the point stronger. "Unwanted communication" can be me keeping sending you private emails about personal topics after you have requested me repeatedly to stop doing that. The content of each email might be formally correct and not a violation of the CoC but the act of persevering in an unwanted personal communication becomes harassment.--Qgil-WMF (talk) 11:16, 13 September 2015 (UTC)

Unwanted and inappropriate conduct are surely different things. Certain acts when performed in public may well be inappropriate even if consensual. Rogol Domedonfors (talk) 13:12, 13 September 2015 (UTC)

Mmm true. Then it looks like the current wording is correct after all.--Qgil-WMF (talk) 14:25, 13 September 2015 (UTC)

I agree with Quim. In many cases, the social cues and conventions show that something will certainly or most likely be unwanted. We do not want to allow "they didn't explicitly tell me it was unwanted" as a guaranteed free pass. It's true there may be good-faith borderline situations caused by genuine culture differences and/or misread social cues. But that's why the committee can ask all sides and come up with an appropriate penalty, which might only be a private warning in a minor case caused by a genuine misunderstanding. Mattflaschen-WMF (talk) 04:26, 17 September 2015 (UTC)

The list of unacceptable behaviors begins with "Examples include but are not limited to" which makes it clear that a behavior can be considered unacceptable despite not being explicitly listed there. That is sufficient to prevent rules lawyering. All other points should serve the purpose of preventing misbehavior (or encouraging its reporting) by telling someone who otherwise would not have realized that a certain thing is unacceptable. Handwavy stuff like "do not engage in communication in a way that violates cultural conventions or social cues" does not do that. If someone does not know what said cues and conventions are, the CoC does nothing whatsoever to help them. If someone does know, they don't really need the list of unacceptable things at all; they just need to know that there are consequences for behaving unacceptably.

So vague claims do not make the CoC more effective, but they can be actively harmful. Conventions are fuzzy across cultures and also across different levels of social skill. Saying "don't do inappropriate things" implies that you should know what those are, and if you don't know (or don't know what's inappropriate in the US, or at a conference attended by rich industry types you don't normally meet, etc), you are at the wrong place. (Also worth noting that about 1 in 20 adults in the US are estimated to have social anxiety disorder; anecdotally, it is even more frequent in online and technical communities. WebMD describes it as fear that someone "will make mistakes, look bad, and be embarrassed or humiliated in front of others. The fear may be made worse by a lack of social skills or experience in social situations. ... As a result of the fear, the person endures certain social situations in extreme distress or may avoid them altogether." Warnings about horrible consequences of ill-defined bad behavior can easily prevent such persons from joining a community.)

Again quoting the Open CoC, "continued one-on-one communication after requests to cease" is an actually useful way of putting what "unwanted communication" was probably intended to mean. The other "unwanted"/"inappropriate" points can probably be rewritten along those lines. --Tgr (WMF) (talk) 10:01, 18 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)

Own page for the Committee

There have been several mentions about the usefulness to move all the details about functioning and membership of the committee to an own page. I think this is a good idea for several reasons:

• it simplifies the CoC document
• we will need a page for the committee anyway, to identify its members, post announcements, etc
• details about the functioning of the committee can be discussed and agreed without having to touch the CoC, which should be a quite stable document.

It is still worth keeping the text in the CoC page while we are drafting in order to keep the discussions in one place at this point. However, that text should be clearly marked to go to its own page. This separation has been seen positive by several people before, so I went ahead proposing the change in the draft.--Qgil-WMF (talk) 07:17, 10 September 2015 (UTC)

It is fine for the CoC to be composed of multiple pages. However, we should separate what is the CoC policy, and what is adjacent administrative stuff (e.g. list of committee members, procedural details the committee comes up with). Obviously the list of people and announcements are not part of the CoC. But also, the procedural details are not; they can clarify details of CoC enforcement, but not be inconsistent with it. Amending the CoC is different from adding a procedural element.

I suggest we compose the whole Code of Conduct (i.e. the policy-level parts) of everything under Code of conduct for technical spaces/Policy. So this main CoC document would be moved to Code of conduct for technical spaces/Policy, and subpages that are still parts of the CoC proper would go to e.g. Code of conduct for technical spaces/Policy/Committee. The list of committee members and user-friendly non-binding explanation could go to Code of conduct for technical spaces/Committee. Procedure the committee comes up with itself could go to e.g. Code of conduct for technical spaces/Committee/Meeting procedure. Mattflaschen-WMF (talk) 14:58, 10 September 2015 (UTC)

Sorry, I got lost. From the current Committee section, what would you keep together with Principles and Unacceptable behavior, and what would you move to own pages? I think we can recreate these pages here using "=" headers, so we have the real division of pages but still everything in one place for better discussion.--Qgil-WMF (talk) 02:01, 13 September 2015 (UTC)

I would approach this from a usability point of view. There are going to be a lot of readers who want to learn what they shouldn't do / what they should call out others for doing, and (hopefully) a very few number of readers who need to know how to report violations or otherwise get involved in the enforcement process. So separate the description of what people should not do and the description of what happens when someone does it anyway. --Tgr (WMF) (talk) 02:46, 13 September 2015 (UTC)

I have started by separating the CoC page from the Committee page. We could have a "Report an issue" section after "Unacceptable behavior" with the minimum information, linking to Code of conduct for technical spaces/Report an issue where the full process of reporting, enforcing, and appealing would be described. This would leaves us with three pages: CoC, Report and Issue, and Committee.--Qgil-WMF (talk) 22:27, 15 September 2015 (UTC)

... and I have moved the Reporting/Enforcement part to an own page as well. The draft now reflects a structure of three pages that looks usable and solid. What do you think?--Qgil-WMF (talk) 14:24, 16 September 2015 (UTC)

My concern is to separate policy-level pages and other pages (as an analogy, Wikipedia:Verifiability is a policy, while w:Wikipedia:Verifiability, not truth is just a wiki page). It's takes more consensus to change a policy-level page than an ordinary page (even one summarizing a policy). I don't think we need essays about the CoC (but people could put them in userspace), but we do need supplementary pages (e.g. list of committee members at Code of conduct for technical spaces/Committee, meeting procedure devised by each committee at Code of conduct for technical spaces/Committee/Meeting procedure) that are not policy-level. I've shown my proposal using the system you've made on the main page (= sections). The separation already there made sense, so I just changed the titles. Only the policy-level ones need to be decided now. Mattflaschen-WMF (talk) 04:13, 17 September 2015 (UTC)

I agree with you that we need to identify policy pages as such and we need to follow a more careful process to update those. However, I think naming the pages with "/Policy" is superfluous and adds an unnecessary bureaucratic flair to the CoC. A Template:Policy should be enough to achieve that. This doesn't stop the Committee creating the non-policy pages they need.--Qgil-WMF (talk) 05:44, 17 September 2015 (UTC)

@Qgil-WMF: Okay, I don't feel strongly about it, so I've undid my edit. Template:Development policy (that's what Template:Policy redirects to) is not suitable, though, since it is meant for a different type of policy with a different approval and update process. That can be addressed with a new template, e.g. Template:Conduct policy or Template:Community policy. Mattflaschen-WMF (talk) 06:39, 17 September 2015 (UTC)

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

Do we have consensus that the current text of the intro (lead section before "Principles"), "Principles", and "Unacceptable behavior" should be considered done?

This does not mean these sections would yet become binding. There will be separate procedure later to decide whether to approve the Code of Conduct.

This is just about whether we can mark these sections as done, and move on to the remaining sections. Mattflaschen-WMF (talk) 15:18, 10 September 2015 (UTC)

Reminder. The consensus discussion is solely about the linked version, not changes made after that. I am thinking if this version has consensus, we could look at the changes made after that and maybe have a brief discussion (1 week) about whether to approve further changes that happened during the first discussion. Mattflaschen-WMF (talk) 21:01, 16 September 2015 (UTC)

• Support I think we've done a good job addressing issues and coming up with consensus text for this. Mattflaschen-WMF (talk) 15:18, 10 September 2015 (UTC)
• 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)
  • discussion: #"We pledge"
• Support. Looks pretty good to me. I understand Yaron's concerns but I don't have a problem with aspirational prologues, as it were. Ironholds (talk) 15:50, 10 September 2015 (UTC)
• Oppose No. The intro is incorrect (claims "we" have control of things "we" don't control, contains undefined phrases such as "representing the project"); principles are either empty babble or dubious (freedom of religion is mentioned, but not freedom of opinion, thought or expression?!); "Unacceptable behavior" is either redundant (compared to the terms of use) or tautological ("prohibited things are prohibited"). --Nemo 16:22, 10 September 2015 (UTC) P.s.: This comment is not an endorsement of the validity of this section as tool to determine consensus on this matter.
  • discussion: #Redundance and freedom of opinion
• Support This is solid, and has been modified to address most of the points that have been raised in the discussion. --Fhocutt (WMF) (talk) 16:44, 10 September 2015 (UTC)
• Support It looks pretty solid to me and discussion on those sections seems to have died down. Kaldari (talk) 23:35, 10 September 2015 (UTC)
• Support I think these sections are simple and clear, the result of a very fruitful discussion. There might be still little details to polish while we draft the rest of the CoC, but I think the draft is already very good as it is now.--Qgil-WMF (talk) 23:49, 10 September 2015 (UTC)
• Support These sections look pretty solid and I agree with everything said in them. I wonder if it would make sense to name 'prolonged staring' as an example of "inappropriate or unwanted attention" to avoid potential "well how was I supposed to know that's what it meant too" issues? --MPopov (WMF) (talk) 21:22, 11 September 2015 (UTC)
• Support I would still like to see the changes as discussed here. SSastry (WMF) (talk) 23:38, 11 September 2015 (UTC)
• Oppose, 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)
  • discussion: #Paid vs. unpaid; complexity
• Support. I'm not WMF, nor anglosaxon, nor employed in an anglo-saxon country, yet I fully support having a code of conduct to set an absolute minimum on how people act in our community. I feel these sections clearly set this minimum. Valhallasw (talk) 10:48, 12 September 2015 (UTC)
• Oppose 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)
  • discussion: #Definition of maintainers
• Support I've seen harassment on-wiki and off-wiki for a very long time and it made me thick-skinned but I hope this CoC helps creating a foster place for newbies. It seems these sections can set the minimum of a foster environment. Ladsgroup (talk) 18:39, 12 September 2015 (UTC)
• Comment It is regrettable that this discussion has been very largely conducted by WMF staff and that the support gained comes very largely from that group. Until there is a significant level of support from the volunteer community, the code will lack legitimacy. Indeed, at present it bears an uncomfortable resemblance to an imposition on the community by the WMF, in tht the code has been largely drafted by WMF staff, is angled at the specific constraints of WMF staff, and assigns the ultimate enforcement authority to WMF staff. This is not a comfortable position. Why is there so little input at this stage from the wider community? In the matter of legitimisation, the widest possible degree of involvement is desirable. Rogol Domedonfors (talk) 18:59, 12 September 2015 (UTC)
  • discussion: #Lack of volunteer involvement
• Support I approve of the language and organization of content in this draft. Code of Conducts are not for me. Or you. They are for the underrepresented people who don't have the privilege we have. Those who don't feel comfortable attending our events - or if they do attend, speaking up when someone acts against members of the community. It's telling the the opposers to this are mainly made up of young men - not the group of individuals that would most benefit from a Code of Conduct.

We can't speak to the experiences of individuals that would most benefit a Code of Conduct. But we can use our position of privilege to give them a larger voice. I think it's important to publicly state that events are dedicated to providing a inviting and supportive environment that does not tolerate discrimination or harassment. Equally important is having a strong process for event organizers on what to do if something does happen. They should be empowered to act if an unfortunate event occurs without hesitation. Far smarter individuals have said it better than I. I encourage you to learn more.

• https://medium.com/@bmanning/the-code-of-conduct-conundrum-ceb3693af7d3
• http://republicofquality.com/lessons-from-a-code-of-conduct/
• http://rachelnabors.com/2015/09/01/code-of-conduct/

Ckoerner (talk) 15:01, 16 September 2015 (UTC)

• Support All of my concerns with these sections have been resolved. John Vandenberg (talk) 21:01, 16 September 2015 (UTC)

"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)

Redundance and freedom of opinion

“

No. The intro is incorrect (claims "we" have control of things "we" don't control, contains undefined phrases such as "representing the project"); principles are either empty babble or dubious (freedom of religion is mentioned, but not freedom of opinion, thought or expression?!); "Unacceptable behavior" is either redundant (compared to the terms of use) or tautological ("prohibited things are prohibited"). --Nemo 16:22, 10 September 2015 (UTC) P.s.: This comment is not an endorsement of the validity of this section as tool to determine consensus on this matter.

”

• Nothing wrong with being redundant. Would you seriously inflict reading the 40.000 character terms of use on everyone who wishes to learn about etiquette? :)

  Freedom of religion is actually not mentioned. What is mentioned is "making participation respectful and harassment-free for everyone regardless of religion". People certainly should not be harassed for holding unpopular opinions, whether religious or not; do you have any specific suggestion on how to amend the text? --Tgr (WMF) (talk) 03:26, 13 September 2015 (UTC)

The Terms of Use apply to everyone who uses the sites, so the answer to your question has to be "Yes". Rogol Domedonfors (talk) 06:45, 14 September 2015 (UTC)

It applies to everyone, but no one actually reads it. WMF Legal made epic efforts to make that document readable and it's better than most ToUs; even so, it's a dozen pages, most of which is legalese. With the CoC we should be aiming at a document that we can refer people to and they will actually read it.

In any case, there is a single sentence in the ToU about unacceptable behavior that overlaps with the CoC ("Engaging in harassment, threats, stalking, spamming, or vandalism"); Nemo is exaggerating there a bit. --Tgr (WMF) (talk) 18:11, 14 September 2015 (UTC)

Laughable. WMF Legal made epic efforts to replace long-standing terms of use with a document three times as long. Now, you are making epic efforts to impose additional walls of text in front of new contributors: the current draft is longer than the entire terms of use were. Maybe this is https://xkcd.com/927/ striking again. --Nemo 10:41, 18 September 2015 (UTC)

Paid vs. unpaid; complexity

“

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)

Lack of volunteer involvement

“

It is regrettable that this discussion has been very largely conducted by WMF staff and that the support gained comes very largely from that group. Until there is a significant level of support from the volunteer community, the code will lack legitimacy. Indeed, at present it bears an uncomfortable resemblance to an imposition on the community by the WMF, in tht the code has been largely drafted by WMF staff, is angled at the specific constraints of WMF staff, and assigns the ultimate enforcement authority to WMF staff. This is not a comfortable position. Why is there so little input at this stage from the wider community? In the matter of legitimisation, the widest possible degree of involvement is desirable. Rogol Domedonfors (talk) 18:59, 12 September 2015 (UTC)

”

• I agree that the widest amount of involvement is desireable, but I disagree that it looks like any form of imposition. The discussion has been advertised on wikitech-l (the mailing list used by the entire tech community, not just WMF developers) and publicly listed on phabricator (the bugtracker used by the entire tech community) and started off in a discussion at a conference (which overwhelmingly had non-WMF attendees). I'm not sure what more there is to do to advertise it to MediaWiki developers once it's been repeatedly advertised on the venues they use. If you have ideas, I would really appreciate hearing them.

  I don't agree that it needs a vast amount of volunteer support to gain legitimacy, for the same reason I'd also hypothesise is why we're seeing many WMF comments; the MediaWiki development space is the one space where it's fair to say that WMF staff make up a significant percentage of the community, and a significant space of the most active community members. In that regard the process is actually a success - it's succeeded in attracting a lot of very active members of the developer community - and while I would love for more volunteers to participate (if you are thinking of participating, and are reading this, please do) the fact that support includes a lot of staff is not shocking given the demographics of the developer community.

  I don't see where this is "angled at the specific constraints of WMF staff" (can you point to examples where that is the case?) and while ultimate enforcement rests with the WMF, absent appeals it is (according to discussion on this very talkpage) the Committee's decision whether to refer cases over. Ultimately resting with WMF staff is probably where we want to be on this too, in the sense that (as you yourself has noted) there can be fairly serious legal implications around some of the stuff people could report. Ironholds (talk) 20:08, 12 September 2015 (UTC)

The "specific constraints" point you ask about is this. As to the legitimacy issue, we clearly disagree, perhaps unsurprisingly. Rogol Domedonfors (talk)

Well, "it's a constraint on WMF staff" is not why I personally do not agree with including your request in the Code of Conduct, for what it's worth; I do not agree because it is totally cross-wise with the sort of behaviour the code of conduct is designed to prohibit. It doesn't fit in with any of the examples or explicitly called out forms of behaviour. And (aside from that) I wouldn't describe it as "a constraint on WMF staff" I would describe it as "impossible to do without a vast increase in WMF resources". If you want to go argue for an increase in that resourcing I invite you to do so but this is not the place for that, and absent those resources, not including something that is literally impossible (respond to all community comments, however they scale, promptly and in a way satisfactory to the person commenting, with a ratio of 1:400 between respondents and commenters) isn't really a deficiency. We should stick to the possible and practical. Ironholds (talk) 22:46, 12 September 2015 (UTC)

Do you have an example of a discussion with high volunteer involvement that can be used as a baseline for comparison? It would help avoid unrealistic expectations on what fraction of people participate in discussions in general. (English Wikipedia, for example, has tens of thousands of editors but an RfC with a hundred commenters counts as decent turnout.) --Tgr (WMF) (talk) 04:12, 13 September 2015 (UTC)

One word: Superprotect. Rogol Domedonfors (talk) 13:08, 13 September 2015 (UTC)

Let me reword: do you have an example of a discussion with high volunteer involvement that can be used as a baseline for a meaningful comparison? :) Thus, a discussion concerning the MediaWiki technical community and not something that involved all of the Wikimedia movement which is about two orders of magnitude larger? (Also, preferably something that's not basically outrage porn; negative discussions tend to have very different dynamics from constructive ones.)

The best comparison I can think of is Requests for comment/Phabricator (which affected the average contributor *way* more than a CoC) which had 91 users involved. (The SVN + CodeReview -> Git + Gerrit migration was the other change with huge impact, but I couldn't find a similar discussion for that.) With half the user count for a way more modest change, I think we are doing OK. --Tgr (WMF) (talk) 20:59, 13 September 2015 (UTC)

As far as I can tell there are 6 volunteer and 7 staff votes here: it's a bit confusing as some staff have chosen to vote under their non-staff handles. The 6 volunteers are opposed 4:2 and the 7 staff are supporting 7:0. This does not look like a mandate from the volunteer community. Rogol Domedonfors (talk) 06:45, 14 September 2015 (UTC)

The average volunteer doesn't have the time or motivation to follow lengthy and dense discussions like this one, regardless of the topic and their agreement. In every round of feedback we are getting interesting new ideas from previous and new contributors, supportive or reticent about the CoC, and we are improving the draft almost on a daily basis. I'm sure we will get a higher number of participants and a more balanced ratio of WMF/non-WMF as we move forward.--Qgil-WMF (talk) 07:14, 14 September 2015 (UTC)

@Qgil-WMF: Just for clarity, I disengaged away from this discussion after repeatedly seeing every point I raised for change being beaten back by WMF employees and concluding that as I do not enjoy long and petty wikilawyering arguments with the same old names, I would be better off using my time elsewhere. The WMF employee point of view dominates this discussion. The outcome will be a policy that employees approve of, but there is no consensus here from unpaid volunteers, nor in reality does it seem needed or wanted. You are in control, it's your call. --Fæ (talk) 09:13, 15 September 2015 (UTC)

@Fæ: I have re-read all your comments here and in the Archive page. You had a lot of feedback on vagueness and wording in the draft that (as far as I can see) has been addressed. You have complained about the appeal process, and we haven't agreed anything there yet because we have decided to go step by step. You have made references to the existence of a bunch of policies that potentially overlap with this CoC, to which we promoters of this CoC say that this CoC offers a simple, compatible, and enforceable gateway to all of them -- we can discuss further in an own section. You have been questioning ECT as appealing / delegation body, which is being discussed and I'm asking for better alternatives. You also say this CoC has a potential to become a censorship tool for the WMF, allowing the WMF to global ban someone for minor faults in conduct not constituting harassment (the wording is mine), but I wonder how a potentially evil WMF could do that bypassing admins, maintainers, and the Committee. I think these arguments are reasonable from a volunteer point of view, not WMF specific. Discussing is taking a lot of time indeed, but because the questions raised are good and valid, and deserve attention. A community without a Foundation could be discussing a CoC in very similar terms.--Qgil-WMF (talk) 09:41, 15 September 2015 (UTC)

Thanks for summarising my thoughts on long and difficult governance issues so quickly. I feel I have burnt my fingers taking part and I'm just not welcome around here regardless of the printed word. I'll go focus on more rewarding stuff with my unpaid free time. Thanks --Fæ (talk) 10:12, 15 September 2015 (UTC)

"every point I raised for change being beaten back by WMF employees" This is not accurate. For example, you wrote "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." In response, I made sure "included but not limited to" was removed from the "virtual" part, and made sure it stayed that way (I had to change it back again at one point). The part referencing global bans was removed partly due to your feedback. Mattflaschen-WMF (talk) 05:52, 17 September 2015 (UTC)

The average volunteer doesn't have the time or motivation to follow lengthy and dense discussions and outrage porn -- these suggest an unhealthy attitude on the part of paid staff towards volunteers. Why not just come right out and say that volunteers' comments are not worth considering? Rogol Domedonfors (talk) 19:41, 15 September 2015 (UTC)

@Rogol Domedonfors: could you point to a single comment in this entire CoC discussion not considered by myself or any of the promoters of this proposal? If you think we have more than a few dozens of volunteers that can afford investing the time you and me have been investing in this CoC draft, I beg to disagree. Please don't distort my words.--Qgil-WMF (talk) 20:29, 15 September 2015 (UTC)

Both phrases are direct quotations, one from you, one from a colleague. Each suggests that the author, you and your colleague, feels that comments by people who are not WMF staff members are of lower value than those of staff members. If that is not your view, it would be good to hear it. Rogol Domedonfors (talk) 21:00, 15 September 2015 (UTC)

I think the opinions of people who are not WMF staff are highly valuable, because most of them are volunteers that contribute their time altruistically, because their opinions can cover a wide range of diversity, and because it is my responsibility to listen to them and provide them what they need. I also care about the volunteers that are not participating here for various reasons, trying to cover their needs as well. I also care about WMF employees, and I'm aware of those that have a long experience as volunteers themselves (like the majority of the WMF employees you see around). My track is fully public and it extends to almost three years serving volunteers at the WMF, plus some more before. If I keep replying to your comments as diligently as I can is because I'm treating you as a volunteer.--Qgil-WMF (talk) 22:07, 15 September 2015 (UTC)

The average volunteer doesn't have the time or motivation to follow lengthy and dense discussions. (Isarra said it better: «Imagine if you were doing all of this in your spare time, would you rather be using your limited time making things, or talking about some ephemeral proposed thing that may not ever even affect you even if it does become real?».) So why impose on them some 15 kB of additional text beyond the terms of use, which nobody reads as Tgr kindly noted? Presumably, this additional text will not be read either. So are all your bets on the power of forceful enforcement? --Nemo 10:53, 18 September 2015 (UTC)

WMF being the ultimate enforcement authority seems natural to me as it is the WMF that physically owns most of the architecture, an physical access is usually the ultimate means of enforcement. (Or sanctions by the employer or event organizer, which is also the WMF in most cases.) That said, the actual, everyday enforcement would be done by project administrators and maintainers and would not involve the WMF at all. --Tgr (WMF) (talk) 04:12, 13 September 2015 (UTC)

Technical enforcement on their servers is certainly going to be implemented by WMF. The fact that the WMF paid staff have been largely responsible for designing a code of conduct that applies to disputes that might involve them and non-staff, and that the suggestion that WMF Engineering Community team act as final arbiters of disputes that might be between members of their own community and others, do not send out a good message about independence. Rogol Domedonfors (talk) 13:08, 13 September 2015 (UTC)

Without CoC or Committee, Developer Relations (was Engineering Community) is dealing with conduct problems in the Wikimedia tech community already today, and for a long time. The introduction of a CoC and a Committee is an improvement in "independence from WMF", if that concerns you. ECT members have also heard opinions of people that thought we were partial toward volunteers in detriment of WMF employees. I guess this shows that we are trying hard to be impartial, and a CoC will make this work easier for everybody. If the community wants to have a backup for the Committee and they find another group that can do better this job, we will support that.--Qgil-WMF (talk) 14:23, 13 September 2015 (UTC)

I would say that the whole technical community is responsible for designing a CoC (as, ultimately, we all are responsible for making sure we are an open and welcoming community), and it has been largely WMF staff that has picked up that work. (Not all that surprising since WMF staff have, on average, way more time to spend on Wikimedia activities in general.) That is maybe unfortunate but it's necessary work that someone had to pick up, and no one is excluded, so I don't think WMF has any extra authority here apart from the usual doocratic authority in which WMF tends to be overrepresented as it does most of the work.

It also seems unfair to characterize a situation where the committee is allowed to hand over cases to ECT as ECT having the ultimate authority. Presumably the committee will only exercise that right when they feel they are unable to deal with something, in which case it is not a question of independence but one of necessity. --Tgr (WMF) (talk) 20:59, 13 September 2015 (UTC)

The ECT/DR team is the appeal body, and hence the final authority. Rogol Domedonfors (talk) 06:45, 14 September 2015 (UTC)

Once the project administrators and committee have passed over it, who would you have the appeal body be? Ironholds (talk) 16:54, 14 September 2015 (UTC)

That's a fair point, but like Ironholds, I can't think of any good alternative. Maybe some sort of ombudsman system similar to the one checkusers have would make sense? --Tgr (WMF) (talk) 19:32, 14 September 2015 (UTC)

Of course, the ombudsmen are appointed by the WMF in a very similar fashion to how we're proposing the Committee be appointed here, so if the goal is "absolutely no WMF involvement ever at the top level" it's still very easy to criticise that. As I think I've made clear I have no problem with the existing way of doing things but *shrugs*. Ironholds (talk) 00:35, 15 September 2015 (UTC)

Putting "absolutely no WMF involvement ever at the top level" in quotes suggests that you think that someone, probably me, actually said it. Could you either provide a diff, or, better, strike it and return to the topic under discussion, which is, whether having the EC/DR team as ultimate appeal authority in a putative consensus primarily of WMF staff might suffer from a lack of legitimacy? Rogol Domedonfors (talk) 19:41, 15 September 2015 (UTC)

We are still drafting the Committee section and we haven't called for wider consensus about it yet. I keep asking if you or someone else has any alternative proposal to the Developer Relations team. If there is an alternative proposal, then we can discuss which one to choose. While there is no alternative proposal, what exactly are we discussing?--Qgil-WMF (talk) 20:36, 15 September 2015 (UTC)

My proposition is that the current draft lacks independence and community acceptance and that it represents an imposition on the community by a small group of staff who would also be assigned the authority to enforce it. That is what I would hope to discuss. For some reason, discussion seems to have diverted towards other, possibly less uncomfortable, topics, such as the make up of the Committee and the Appeal body which, as you so rightly point out, is not precisely within the scope of this section. Rogol Domedonfors (talk) 21:00, 15 September 2015 (UTC)

Of the formal !votes here, I see one from someone "assigned the authority to enforce it". What would make this an "independent" draft to you? Community comment has been solicited (and incorporated in many cases). It started off in a public meeting at a movement-wide conference. It continued in a phabricator thread open to the general public. It was announced for discussion on the public mailing lists.

I've heard very little from you about problems with the draft itself, so I'll ask explicitly; what problems do you see in the draft portions we are discussing in this thread, other than the mandate to respond you'd like to see incorporated? Ironholds (talk) 21:11, 15 September 2015 (UTC)

My proposition is that there is not sufficient participation for this "Consensus discussion" to represent a consensus of the whole community; that the preponderance of !votes from staff represents a lack of independence; and that in the absence of a wider discussion and consensus the Code will lack legitimacy. Rogol Domedonfors (talk) 21:23, 15 September 2015 (UTC)

In other words, you don't have an issue with the proposed text, merely the system in which it is being proposed. I agree that it needs wide-ranging support behind it, but I absolutely disagree that the "preponderance of !votes from staff" represents a lack of independence; I think it represents, well, representation.

In August 2015 (the last complete month of data), the technical community dashboards show that WMF employees submitted 3,493 patches; volunteers submitted 615. Those 3.4k patches were submitted by 79 people; the 615, 12. Now, I see 9 supports here in this discussion, 7 WMF and 2 non-WMF, making for 77% WMF overall. When you look at the committer numbers, WMF employees made up 86% of committers. The "preponderance of WMF votes" does not represent some imminent risk to the independence of the technical community, because when it comes to the MediaWiki community that technical community is already mostly staff. Heck, one of the things this code of conduct is attempting to do is create a nicer environment explicitly to broaden the community out and allow for far more people to participate because they genuinely want to.

Now, I want to see more community members - I want to see more people - but what we're talking about here is a community of, according to gerrit, around 100 people, 86% staff. And what we're seeing in support is a 10th of that, 77% staff. 10% participation isn't terrible (and it's more than that when you factor in people who haven't expressed an opinion either way, or who have opposed). If you have active suggestions for how we can get more people involved I would love to hear them (and my apologies if you posted them above and I missed them). Ironholds (talk) 22:02, 15 September 2015 (UTC)

That's the second time this week that you have presumed to ascribe to me an opinion with no basis in anything I have written -- please don't do that again. You seem to be saying that 7 WMF staff and 2 volunteers are sufficient to speak for the entire community within physical spaces such as Wikimedia events and Wikimedia-related presentations in other developer events, and virtual (MediaWiki.org, wikitech.wikimedia.org, Phabricator, Gerrit, technical mailing lists, technical IRC channels, and Etherpad). I don't think that numbers equivalent to 8.9% of the highly active staff and 17% of the highly active volunteers here at this site (taking "highly active" to mean, "submitted a patch in August 2015") constitutes a sufficiently broad set of supporters to give this code legitimacy and for you to claim community acceptance. If you are indeed concerned about bringing more and wider community activity to this process, then instead of asking me for suggestions now in mid-September, you should already have been calling on the resources of the teams of experienced paid staff of the WMF as soon as the process started in mid-July. To leave it for two months and then toss it in as a rhetorical question suggests you see it more as a debating tactic rather than an urgent desire for community involvement. As a thought experiment, I suggest you read over your comment from the point of view of a volunteer contributor anxious about becoming a second-class citizen in this process. Do you think their concerns will be alleviated by your response that the view of 7 WMF staff and 2 volunteers is representative? Rogol Domedonfors (talk) 20:43, 17 September 2015 (UTC)

While there is not enough quantitative participation and not enough diversity of participation, I find the quality of the participation is very high, and it is helping ironing this CoC draft. Once the usual contributors and whoever else wants to join have finished ironing it, then we can go back to wikitech-l and beyond and present the draft asking for Accept / Neutral / Oppose positionings with optional comments. If at that point we the usual contributors step back and let others speak, there are high chances that we will get more opinions from a more diverse pool of contributors. Meanwhile, I will keep discussing about whatever topics are being brought here, but I will keep focusing on ironing the draft section by section.--Qgil-WMF (talk) 22:13, 15 September 2015 (UTC)

Appeals details are not part of this particular consensus discussion because it's not in one of the discussed sections (they will be part of a later one after more drafting work on those sections). However, it's important to note that the linked version of the draft only allows appeals by the alleged offender, and only if there is a resolution of more than three months. That may change after later discussions, but with the current draft you're overstating DR's authority. Mattflaschen-WMF (talk) 05:38, 17 September 2015 (UTC)

• The technical space is one of the only Wikimedia communities where a large fraction of contributors (if not the majority in some kinds of technical work) work for the WMF. Thus it is not surprising to see a significant amount of staff here. You ask "Why is there so little input at this stage from the wider community?" I think the main reason is that most people in the WMF technical community are not interested in this kind of discussion. At lot of people will be happy with any reasonable Code of Conduct (and may show up for later discussions), but would rather do their normal work then help draft it. If you notice, even among WMF, only a fraction of WMF staff and contractors have chosen to participate; many of them are busy doing other things too, just like volunteers. However, this code of conduct will help us all better welcome volunteers if adopted and followed. Mattflaschen-WMF (talk) 03:48, 17 September 2015 (UTC)

Representing the community in public spaces

Re: this edit, I think it changes the meaning drastically. Think of someone opening an a Twitter account with the name "MediaWiki developer" and then using it abusively. That is not a technical space, but it still represents the project in some way. (This was occasionally a problem for some non-tech projects where unofficial Facebook groups and such were used by people who where banned from the official places as a soapbox.) Also consider the case of a MediaWiki developer participating at a non-technical event where they were invited for being a MediaWiki developer.

I have a weak preference for the old version, but in any case, it's not an insignificant change. --Tgr (WMF) (talk) 02:56, 13 September 2015 (UTC)

An unauthorized "MediaWiki developer" Twitter account would infringe the trademark policy in the first place, and in your case would be someone anonymous in any case, so this CoC would be of little practical use. A MediaWiki developer participating in an event out of the scope of "Wikimedia technical spaces" and harassing or disrespecting someone there would be subject to the code of conduct or similar of that event in the first place. If that person would a WMF employee then wmf:Code of conduct policy could apply regardless. Probably the most likely scenarios are covered by these cases? If not, someone could still submit a report arguing that such developer was representing the MediaWiki project, and the discussion would be interesting regardless of the sentence I removed being present in the CoC or not. The core mission of this CoC is to assure "making participation in Wikimedia technical projects a respectful and harassment-free experience for everyone", and I think it is better to keep a CoC with clear and concise principles. Trying to cover all scenarios possible with a longer and more complex text does not necessarily accomplish better the mission of the CoC.--Qgil-WMF (talk) 03:25, 13 September 2015 (UTC)

I also disagree with this change, and the assertion in the edit summary, "Simplifying sentence without changing meaning (?)". This section is also part of the active consensus discussion. As to the actual point, the Twitter case would indeed be hard to enforce. However, say a MediaWiki developer participates in a Foolang conference as a speaker (representing MediaWiki, e.g. because "Senior MediaWiki VP of Advanced Technology" or whatever was next to their name on the conference program). (This example is not referring in any way to actual people). They then put something offensive on their presentation slides. In this example, the MW code of conduct committee should have its own jurisdiction, regardless of whether the Foolang conference has a code of conduct. Put more simply, we don't want people going out, speaking in public spaces, saying they're "from MediaWiki" and putting us in a bad light through conduct the CoC does not allow. Mattflaschen-WMF (talk) 04:46, 17 September 2015 (UTC)

Alright, back to the original scope. Still my main problem with this sentence is that (being the first sentence and providing the first impression) sounds unclear and repetitive. I have to read it twice to deduce what it means. I have proposed an alternative wording. Please revert if you think it needs further discussion.--Qgil-WMF (talk) 05:59, 17 September 2015 (UTC)

Start with positive guidelines on behavior

One thing I like about the Open Code of Conduct is that it tries to balance the long list of things not to do with a positive and upbeat list of ideals. (It's also highly scannable, in case someone is in a rush.) Our list of donts is considerably shorter, but I would still welcome having a similar list of behaviors to strive for. --Tgr (WMF) (talk) 04:52, 13 September 2015 (UTC)

I think this is a good idea. The selection of positive points is good, but I would avoid the long explanations, just like we are avoiding getting into lengthy details in general.--Qgil-WMF (talk) 10:55, 13 September 2015 (UTC)

Proposal of a paragraph to be added in Principles between "... or religion." and "Technical skills..."

Our community strives to:

• Be friendly and patient.
• Be welcoming to people of all backgrounds and identities.
• Be considerate with those affected by decisions and changes.
• Be aware that English is not everybody's primary language.
• Be respectful regardless of disagreement.
• Be kind and careful in the words we choose.
• Try to understand why we disagree.
• Focus on being productive, resolving issues and learning from mistakes.

--Qgil-WMF (talk) 10:43, 15 September 2015 (UTC)

I have copied this list at Code_of_conduct_for_technical_spaces/Draft#Principles. If you like it, let's keep it. If you want to fine tune it, let's edit the list in the Draft, and let's discuss here if needed.--Qgil-WMF (talk) 14:28, 16 September 2015 (UTC)

@Qgil-WMF: I feel that the prior Principles section already addressed many of these things. Tone-wise, I also think that version of the principles section is also pretty good (especially "in the interest of fostering an open and welcoming community, we pledge to respect all people" kicking it off). Adding a large block of text this late in the process is also somewhat problematic, since people commenting on the consensus section (which covers this section) may incorrectly think this text is part of what they are weighing in on. I tried to clarify this with the link, but some people might not use it. In some cases, we have to make late-breaking changes, but I'm not sure this is such a case, so I've reverted it. The TODO code of conduct was first referenced on August 9, so there were earlier opportunities to suggest this text. Mattflaschen-WMF (talk) 05:06, 17 September 2015 (UTC)

I agree with Tgr (WMF) that the overall impression is that the CoC focuses on the negatives and would benefit from a description of the expected positives. "We pledge to respect" and "a respectful and harassment-free experience" just cover the minimum in terms of positive message and guidelines. In contrast, we offer a full list of negatives. Tgr's proposal of offering a list of positive guidelines is excellent, and the list is specific enough to be used as a reference when someone is starting to cross the line, well before reporting anything formally.

"This late in the process" is relative. Although I understand that we were making a call for consensus on these sections, I also don't see why we shouldn't incorporate a very good idea when it is suggested by someone resonding to that call for consensus. There is only a chance to write a first version of a CoC in this community, let's use it to define the best CoC we are capable to write, even if it takes some extra hops in our approval process.--Qgil-WMF (talk) 06:32, 17 September 2015 (UTC)

More opinions are welcome. This is the last significant bit of the CoC that needs an agreement.--Qgil-WMF (talk) 09:11, 18 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. --Fæ (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)

"Diverse affiliations" at the Committee

I think we can remove the sentence "It is required that at all times, at least one member of the committee is neither a WMF staff member nor a WMF contractor." The first paragraph of the Committee page already says "a team of five trusted individuals with diverse affiliations", which implies that it is not possible not having all of them affiliated to the WMF. The sentence actually brings involuntarily a change of expectation (at least for me): I'm thinking about the Committee as mainly formed by volunteers, maybe with one or two WMF/WMDE professional developers with a strong community background. That sentence brings the image of a Committee with 3-4 WMF members as ok, maybe expected. In practice I think it is better to stress the aspect of "diverse affiliations" and hope that self-nominations and Committee selections will provide that diversity.--Qgil-WMF (talk) 21:17, 16 September 2015 (UTC)

I think we should keep it. I am fine with rephrasing (as long as the requirement is still noted), or adding something to express that there is no minimum number of WMF members (zero WMF is permitted, though it would not be very representative of the technical community). Mattflaschen-WMF (talk) 02:12, 17 September 2015 (UTC)

What about "Independence and diversity of affiliation among Committee members is encouraged. The Committee cannot have all members affiliated to the same organization." This would set an expectation toward a committee nurtured primarily with independent volunteers and avoids mentioning an exception for the WMF (an hypothetical Committee of five members affiliated to certain chapter or certain company would be equally undesirable).--Qgil-WMF (talk) 06:43, 17 September 2015 (UTC)

That sounds really good. To emphasize that people do not have to be an employee or formal member of an organization, how about, "Independence and diversity of affiliation among Committee members is encouraged. Members need not be formally part of any organization, and the Committee cannot have all members affiliated to the same organization." Mattflaschen-WMF (talk) 06:51, 17 September 2015 (UTC)

Even better, thank you! I have edited the draft accordingly.--Qgil-WMF (talk) 07:42, 17 September 2015 (UTC)