Talk:Code of Conduct/Archive 4

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)

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)
 * 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)
 * 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 . I still think "trust the committee" is a better principle than trying to define numerical rules in advance. A committee trusted to enforce the CoC should be trusted to handle its own functioning. If a specific committee cannot be trusted on the latter it probably won't be trusted on the former, and we will have a bigger problem than supermajorities anyway.--Qgil-WMF (talk) 17:39, 9 September 2015 (UTC)
 * We have the model of the Architecture committee, which is similar to this case (experience, trust, complex issues...) The CoC committee should be transparent in their initial formation and their renewals, but other than that I think a model based on empowering the committee to maintain themselves will work. If the committee misbehaves there will be crisis and loss of trust, and if that happens then we will surely discuss how to move forward.--Qgil-WMF (talk) 09:52, 2 September 2015 (UTC)


 * On the capacity of ECT to remove members, I don't think this is a good idea. If a committee member deserves to be removed, the case should be clear enough for the committee fellows to take action. If ECT wants to remove a member when the rest of the committee is opposing, that means that we all have a deep problem that no rule will solve.--Qgil-WMF (talk) 10:33, 3 September 2015 (UTC)
 * On the permanent seat for an ECT member (something not mentioned in this proposal but discussed elsewhere without a clear conclusion) I still firmly think that ECT should have no privilege. If one of us wants to go for it, then self-nomination and selection should be the process like for anybody else. And if an ECT member is in the committee but for whatever reason it is thought that it is better to leave, the process to refresh seats every six months could be used for that.--Qgil-WMF (talk) 10:33, 3 September 2015 (UTC)
 * The Engineering Community team members agree that ECT should not have a permanent seat or power to veto committee members.--Qgil-WMF (talk) 01:02, 9 September 2015 (UTC)
 * Okay. I do think there needs to be a way to remove members, for very serious problems.  However, I agree that in most cases, it should be sufficient for the committee to do so.  I've added this (requiring a supermajority because unlike regular elections, removing someone mid-term isn't something that should be required often).  If this isn't (e.g. the committee is turning a blind eye to one of their members), a procedure could be developed then. Mattflaschen-WMF (talk) 04:16, 9 September 2015 (UTC)
 * I also think we need to allow resignations mid-term, so I've added that. Mattflaschen-WMF (talk) 04:18, 9 September 2015 (UTC)

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

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

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

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)

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

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)


 * I'm happy about Code of conduct for technical spaces/Draft, including the idea of not defining there the on-time process of . 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)
 * 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. . Mattflaschen-WMF (talk) 22:50, 9 September 2015 (UTC)
 * 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)

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)
 * ✅ 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)
 * 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:
 * 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.
 * 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.
 * 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)
 * 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)

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

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 . I proposed a thought experiment to rectify that at meta:User talk:LilaTretikov (WMF) 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)

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)
 * 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 &bull; contribs) 18:55, 9 September 2015 (UTC)
 * 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 &bull; 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)

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

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)
 * 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 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 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.