Talk:Code of Conduct/Archive 4

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)
 * 1) People would then comment on nominations, both publicly and by emailing ECT (as they prefer).
 * 2) ECT consults with Community Advocacy on the candidates.  The past behavior of the candidates should be in the spirit of the Code of Conduct.
 * 3) 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).
 * 4) 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.
 * 5) 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)
 * 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)
 * 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 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)
 * 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)

Protection of Conduct Committee members
A volunteer serving on the Conduct Committee must consider the possibility that an aggrieved party will sue for libel. To attract qualified volunteers to serve on this committee, one should consider how best to protect them. The main methods are:
 * D&O Liability Insurance. Many not-for-profit organizations purchase a D&O policy that extends coverage to chapter members and volunteers. It is not clear if the WMF has such coverage. Nothing relevant appears when one searches wikimediafoundation.org.
 * Limited disclosure. To take away the grounds for a libel suit, many not-for-profit organizations follow RONR 10th ed, Chap XX Disciplinary Procedures, §61: "If (after trial) a member is expelled, the society has the right to disclose the fact that he is no longer a member—circulating it only to the extent required for the protection of the society or, possibly, of other organizations. Neither the society nor any of its members have the right to make public the charge of which an expelled member has been found guilty, or to reveal any other details connected with the case. To make any of the facts public may constitute libel."

For the protection of Conduct Committee members, please: Wp mirror (talk) 07:12, 20 August 2015 (UTC)
 * procure D&O liability insurance, and post the terms on your site;
 * specify, in the procedural law for the Conduct Committee, how to report the outcome of cases; and
 * reconsider the "public reprimand" penalty clause stated in the draft.
 * The Wikimedia projects are not organised as a society of members. Again, these concerns are best surfaced to and handled by counsel, not pseudorandom members of our technical community (I include me in that). Ironholds (talk) 14:07, 20 August 2015 (UTC)
 * What open source code of conduct committee offers D&O insurance to all members (both staff and volunteer)? Unless you can show a significant number of them do, I don't think it's reasonable to pursue this.  I also can not think of any cases where someone has successfully sued an open source project or related organization for libel after being banned from participating or reprimanded.  Can you? Mattflaschen-WMF (talk) 00:43, 21 August 2015 (UTC)

I have in mind the following libel cases: The last three are sometimes called cyberlibel cases. Consider the following: As to D&O Liability Insurance: The need for coverage is real. This is why potential committee members need to see a copy of the policy. The WMF Chief of Finance and Administration is only one e-mail away. Shall we ask him? Wp mirror (talk) 03:33, 21 August 2015 (UTC)
 * Zenger (1735) - ruled that truth is a defense against libel charge;
 * Cubby, Inc. v. CompuServe Inc. (1991) - ruled that carrier/distributor not liable for libelous posting;
 * Stratton Oakmont, Inc. v. Prodigy Services Co. (1995) - ruled that publisher is liable for libelous posting;
 * Zeran v. America Online, Inc. (1996) - ruled that Communications Decency Act (1996) protects on-line service providers.
 * If the proposed Conduct Committee got its facts wrong and publicly reprimanded someone for a crime he did not commit, Zenger (1735) would not apply, and WMF General Counsel would seek another defense.
 * If WMF General Counsel disavows the Conduct Committee, then Cubby (1991) might be a defense. But then the Conduct Committee would not have authority to enforce the Code of Conduct.
 * If the WMF Board of Trustees acknowledges the Conduct Committee (e.g. if the Conduct Committee reports to the Board of Trustees, like say the Affiliations Committee does), then Stratton (1995) might apply and WMF would be liable.
 * members of the WMF Board of Trustees are indemnified (see Bylaws Article VIII - INDEMNIFICATION);
 * the WMF Chief of Finance and Administration is responsible for purchasing the coverage (see seventh bullet under ADMINISTRATION).
 * If coverage is not provided, qualified volunteers might be hard to find, and even WMF employees would be prudent to hesitate.
 * If WMF employees are covered, but not volunteers, then committee membership should be restricted to employees.
 * If WMF General Counsel needs to be able to disavow the Conduct Committee, then WMF employees must be excluded from the committee.
 * I asked some specific questions, with the goal of comparing to similar situations (open source or at least similarly-minded organizations with code of conduct enforcement). None of the libel cases you mentioned show that a good-faith ban or reprimand can lead to a successful libel suit.  I am not convinced libel suits are a real problem other communities have faced in connection with their codes of conduct.
 * Similarly, you have not shown that D&O insurance is something other similar committees have had. It's not always affordable or realistic to buy more and more insurance, and it certainly doesn't seem to be legally required (or you would cite an example of a community that had bought it). Mattflaschen-WMF (talk) 04:04, 21 August 2015 (UTC)

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

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

D&O premiums are low. Cost is not the issue. Nor is having a list of court cases. Getting people with executive experience to serve is the issue. This is why WMF trustees are indemnified. They would not serve otherwise. Wp mirror (talk) 06:52, 21 August 2015 (UTC)
 * We should definitely check this with WMF Legal before it takes effect. There may be other approaches to dealing with any potential liability arising from participation on this committee. --Fhocutt (WMF) (talk) 23:10, 21 August 2015 (UTC)


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

Is the CoC introducing any novelties here? User bans and other types of measures already exist, and with them the risk of upsetting someone to the level of retaliation. If anything, the CoC provides a bit more structure and a bit more protection to the ones taking action. The existence of a Committee allows admins and maintainers to not be the main actors when i.e. banning someone. The Committee can delegate ugly cases to professional employees at ECT. WMF Legal does protect WMF employees legally, but so it does with Wikimedia volunteers as well. In the case of someone receiving some retaliation for enforcing a CoC resolution, I think the situation with CoC will be better than the current situation without it.--Qgil-WMF (talk) 10:09, 2 September 2015 (UTC)
 * "Public reprimands" (one of the penalties Wp mirror took issue with) also already exist in Wikimedia communities. Specifically, this is what happens when an admin posts on someone's talk page something like "You have done Xyz which is a violation of our policies.  Please do not do so again, or you may be blocked."  Mattflaschen-WMF (talk) 20:40, 2 September 2015 (UTC)

Next steps
We need a bit of organization. Even when the discussion is being shared basically by just a few people, it is becoming harder to follow and get involved productively (even more for volunteers with little time available). The goal of this exercise is to draft a proposal of an enforceable Code of Conduct to be approved by the Wikimedia technical community. We can slice the drafting in modules, allowing for a lighter process of discussion and consensus:
 * 1) Intro + Principles + Unacceptable behavior define the scope of this CoC, and have an intrinsic value. If those of us active in this Talk page now focus on these points, we should be able to reach a level of agreement good enough to send a proposal to wikitech-l.
 * 2) A new section "Committee" (that I will create now unless someone is faster) comprising all the details about this committee will need some more iterations. We can work on it while the community has time to discuss the points above. Hopefully by the time that the points above are stable and clear, we could share our proposal about the committee to wikitech-l.
 * 3) With the previous points on its way for agreement, Reporting, Appealing, and Enforcement should be relatively simpler to deal with, as they are mostly a matter of process. Once we have a draft we are happy with, we would share it with wikitech-l, adding that this is the last chunk of the CoC and we are seeking general consensus for the approval of the entire document.
 * 4) The CoC would become official as soon as it is approved. Then we would proceed to the creation of the committee.

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

There have been some comments about a self-selection (for a lack of a better word?) of people participating in this draft, in this discussion page, and in the related threads in wikitech-l. In order to help capturing a wider range of opinions, we could offer an email alias i.e. coc-discussion@undefinedwikimedia.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)


 * I did think about that, so in option 2 I mentioned that the trusted parties receiving the anonymous feedback would take some basic steps to guard against sockpuppets (essentially the same steps that anybody would take take when checking public comments): checking that the sender has a Phab/mediawiki.org account that predates the discussion and that they haven't already commented. Do you think these wouldn't be enough?—Neil P. Quinn (talk) 18:09, 23 August 2015 (UTC)
 * Its more I would like to err on the side of caution. Its a complicated issue, I'm not 100% sure where I stand. Bawolff (talk) 19:27, 23 August 2015 (UTC)
 * It's not trivial to cross-check someone's email address with their MediaWiki.org or Phabricator account. First, some accounts don't even have email addresses associated (but the anonymous feedback might still come from an email). Even if there is an email associated, you would need to use Special:EmailUser to send them a message to confirm the previous email came from them (otherwise, you don't know their email address and don't know if the from address of the original email was forged). Mattflaschen-WMF (talk) 23:45, 23 August 2015 (UTC)
 * OK, then let's start applying this sequence. About anonymous feedback, I think we should go for 1 as long as consensus is build through discussion (and not votes). If we decide to go for votes, then the scenario changes, but there should be enough time for anonymous feedback in any case. Good ideas are good ideas, regardless of where they come from. If they are influencing, so be it. The fact that such ideas come from a techie sockpuppet, someone alien to Wikimedia tech, etc, it doesn't matter. Considering that users can post here anonymously already (with an IP or a newly created account), users of the private channel would probably be people willing to make a point without having followed the entire discussion or without willing to pick a fight publicly.--Qgil-WMF (talk) 09:51, 24 August 2015 (UTC)
 * Who should be the three people publicly identified as recipients of coc-discussion@undefinedwikimedia.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 so I hope we can go through this step quick.--Qgil-WMF (talk) 08:14, 26 August 2015 (UTC)
 * I am willing to be one of those people. Also, I suggest "conduct-discussion@undefinedwikimedia.org", as abbreviations can be confusing. --Fhocutt (WMF) (talk) 19:09, 26 August 2015 (UTC)
 * No more volunteers so far? Then I will join as well. Two people are enough to get this started. I have requested the conduct-discussion@undefinedwikimedia.org email alias to WMF Office IT and I have also CCed, 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 (a new section with existing content) and .--Qgil-WMF (talk) 08:48, 2 September 2015 (UTC)

Proposing Intro + Principles + Unacceptable behavior
As proposed in, let's focus on agreeing Intro + Principles + Unacceptable behavior up to a point where we can make a wider call to wikitech-l and whatever channels we decide. These sections define the scope of this Code of Conduct, and have an intrinsic value. Please do not discuss these topics or new ones here. Use the existing or new sections instead. Here we are only coordinating the work of proposing these three sections of the draft CoC to wikitech-l.--Qgil-WMF (talk) 10:25, 24 August 2015 (UTC)
 * The intro (first paragraph) seems to be ready.
 * Principles, it looks like the previous discussions are settled now.
 * Unacceptable behavior, there is still recent discussion under, , , ,.


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

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

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

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

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

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

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

I suspect that "level of experience" is trying to get at either/both of the following, which I agree with:
 * 1) newness of the contributor (i.e. number of years involved in this community) shouldn't be a discriminatory aspect
 * 2) power relationship games are completely unacceptable

Sorry I don't have answers for how to rephrase this yet. John Vandenberg (talk) 05:33, 26 August 2015 (UTC)
 * I think part of what its trying to get at, is making fun of people for lack of skill, is not ok. I think there's also a dual meaning of the word "respect". It can mean being a decent person, but it can also mean how seriously you treat their ideas or how likely you are to defer to their decisions, etc. I believe its important to be nice to everyone. But if someone wrote on wikitech-l proposing to rewrite half of MW, I'm going to treat their email much more seriously if somebody like Tim Starling is writing it, than if someone I don't know is writing it. Bawolff (talk) 05:55, 26 August 2015 (UTC)


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

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

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

To me, adding 'level of experience' in this list trivialises all of the other items in the list, which are all identity based. 'level of experience' (broadly speaking) does deserve being highlighted in the CoC, somewhere else, but it fundamentally is not the same as the others in this list. Including it weakens our commitment against identity based discrimination and harassment, when it should be using stronger language for those. Dealing with contributors with seemingly low competence/familiarity can become quite hard, especially if they are not hearing the sometimes too subtle cues, and we all struggle with how to support newcomers effectively - there is always room for improvement here (IMO not reviewing patches in a timely fashion is not respectful). Of course extreme reactions, such as mocking a contributor, is unacceptable, however "RTFM, n00b" is a completely different type of problem to responses that focus on a person identity. Any complaint lodged relating to identity attributes, irrespective of how trivial it is, should result in strong community rejection, and rapidly escalating enforcement. Non-trivial complaints lodged relating to primarily to 'level of experience' are typically going to be complex to untangle, and will often be unresolvable due to difference in perspectives of the events in question. If isolated, complaints related to 'level of experience' will need to give the accused the benefit of the doubt. Repeated bad behaviour related to 'level of experience' will need more careful handling, and possibly even providing training if the accused is a valuable technical resource. John Vandenberg (talk) 08:22, 27 August 2015 (UTC)
 * Would it help to have "level of experience" at the end of the list instead of the beginning? Level of experience is a known target of certain types of unacceptable behavior that we don't want to see in our community. Identity is a tricky concept and I don't think it is worth entering into this debate. Some people won't care much about their own political or religious views, but they might feel stronger about their "geekiness" or "non-geekiness". Also, maybe "level of experience" is not the best wording. Someone can be an expert in several fields of humanities and sciences, be a great family and social partner organizing all kinds of stuff, but have little experience in the context of a free software project. "technical skills" might be a better label for that.--Qgil-WMF (talk) 08:56, 27 August 2015 (UTC)
 * I'd be much happier if our treatment of newcomers / competence levels / skills is clearly separated from the others. IMO it is worthy of its own sentence/paragraph in the Principles section.  Putting it at the end doesnt address my concern.  If there is any interest in separating it, I'd be happy to put in some effort to try separating it from the others in a way that highlights it as an important problem.  If not, so be it.
 * "technical skills" is IMO better. John Vandenberg (talk) 09:25, 27 August 2015 (UTC)
 * I think one of the things we're trying to say here is that established contributors do not get special consideration or licence in matters of conduct on account of the claimed value of their contributions. (This is a principle which the English-language Wikipedia continue to struggle with.)  Is that indeed what we are agreed on?  If so, is there is suitable form of words?  Something like "The behavioural standards expressed in this code apply equally to all members of the community irrespective of status".  Rogol Domedonfors (talk) 06:47, 29 August 2015 (UTC)
 * I have tried to address your feedback in this edit.--Qgil-WMF (talk) 14:05, 31 August 2015 (UTC)
 * That is pretty much what I believe the consensus here to be. Rogol Domedonfors (talk) 16:52, 31 August 2015 (UTC)
 * I completely agree with the principle behind "The behavioural standards expressed in this code apply equally to all members of the community irrespective of status" (not saying we necessarily need that exact sentence in it, but I support that idea). However, I don't think that's all it should mean.  It should also including the ethos of (these are ideas, not proposals for the draft) "Treat newcomers in a welcoming way" and "Try to make interactions with them educational where possible, rather than devolve into RTFM, or just 'Won't Work'", and "Don't harass them because they're new". Mattflaschen-WMF (talk) 23:15, 31 August 2015 (UTC)
 * Now? (I thought I know everything about wikitext discussions, but I'm getting lost with bullets, colons, and indentations...) :) --Qgil-WMF (talk) 09:34, 1 September 2015 (UTC)
 * Yeah, the current text for this looks fine. Mattflaschen-WMF (talk) 23:40, 1 September 2015 (UTC)
 * Yes, I like the phrasing in the draft now. --Fhocutt (WMF) (talk) 17:47, 1 September 2015 (UTC)

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

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 &bull; 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)

Who is going to approve this/how?
It's not clear to me how we expect this draft to be made into policy. Are we going to vote on this? If does eventually become policy, what would be the process for amending it? -- Krenair (talk &bull; contribs) 21:00, 29 August 2015 (UTC)
 * It was suggested above under that it be formally adopted by Resolution of the WMF Board of Trustees. Rogol Domedonfors (talk) 21:37, 29 August 2015 (UTC)
 * I think who approves and how depends on the final draft, and this is why I'm focusing on pushing the draft further as proposed in . I would personally prefer to try first a process of discussion and consensus.--Qgil-WMF (talk) 14:09, 31 August 2015 (UTC)
 * I agree with Qgil-WMF that consensus here on this talk page is the best way. A Board resolution is unnecessary.  See my last comment at Talk:Code_of_conduct_for_technical_spaces/Draft ("This does not require a Board resolution, [...]") for why. Mattflaschen-WMF (talk) 23:44, 31 August 2015 (UTC)

Authority/power of committee?
It's not clear how a committee is going to work unless they are either actually given the power to issue bans etc. themselves, or can convince local technical space admins to give effect to their decision in every single controversial case (of which there will hopefully be few/none, but that can't be assumed) -- Krenair (talk &bull; contribs) 21:04, 29 August 2015 (UTC)
 * Local technical space admins are subject to this CoC just like anybody else. There is a specific sentence mentioning them in the Principles section. They should apply the decisions of the CoC or have a good argument for an appeal.--Qgil-WMF (talk) 14:16, 31 August 2015 (UTC)
 * There is also specific text ("The committee can also bring in people from the spaces involved (e.g. if it happens on both MediaWiki.org and IRC, bring in involved admins and IRC contacts).") about bringing in local space admins when appropriate. In such cases, the local space admins have a direct opportunity to participate in discussion, and thus better understand the basis for the committee's decision. Mattflaschen-WMF (talk) 23:50, 31 August 2015 (UTC)

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

Reports involving WMF employees
This is a spin-off of the discussion of 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: 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.
 * 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.

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 &bull; 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)

Proposing the Commitee section
Continuing with, and now that is on its way for wider community feedback, let focus on the discussions related to Code of conduct for technical spaces/Draft. We have been discussing the Committee together with reporting and enforcement, so there is no clear cut. Related sections (with their subsections) include, , , , , and.

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)

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)