Talk:Code of Conduct/Archive 4

Appeals
The wording on appeals seems unduly restrictive. Firstly, the phrase "the reported offender" should probably read "any person sanctioned". Secondly, there is no specific right of appeal against non-action or leniency of sanction, although this is arguably covered by the final sentence. Is that omission deliberate? Rogol Domedonfors (talk) 19:32, 18 September 2015 (UTC)
 * These are excellent points, particularly the second one. I'm definitely open to changing "the reported offender" (I guess there could be situations in which someone is reported and an investigation finds other people were participating in the activity). Ironholds (talk) 19:37, 18 September 2015 (UTC)
 * (((Your feedback on is welcomed; I'm reluctant to get deep into "Report an issue" before settling at least on the CoC main page.)))--Qgil-WMF (talk) 12:35, 19 September 2015 (UTC)
 * It seems extremely unlikely that other work will lead to a change in the consensus to the effect that there should not be an appeal process, and so there is very little risk that this discussion will prove nugatory. If you do not wish to discuss this point at present, then we look forward to hearing from you at a suitable time. Rogol Domedonfors (talk) 21:53, 20 September 2015 (UTC)
 * "In addition, any member of the community may raise concerns about the committee or a case." does not allow a different kind of appeals. It is purely for informative purposes. Mattflaschen-WMF (talk) 00:25, 25 September 2015 (UTC)
 * Do you mean that you think there should not be a possibility of appeal by an aggrieved party if the Committee takes no action, or is, in the view of the aggrieved party, unduly lenient? In other words that appeals should only be possible against sanctions? Rogol Domedonfors (talk) 06:43, 25 September 2015 (UTC)
 * No, I was just describing what the draft then said. Multiple people have expressed that victims should be able to appeal, so I've changed the draft to allow that. Mattflaschen-WMF (talk) 06:08, 28 September 2015 (UTC)

Now there is a defined section for Appealing a resolution.

I propose to remove "Only resolutions (such as bans) that last 3 months or longer may be appealed by the reported offender." Instead, it could say "Resolutions can be appealed by the reported offenders while they are being enforced." The concern here is that someone obstructs the enforcement with legalese in bad faith, and this is a way to prevent that temptation.
 * I disagree with removing this. Your proposed change allows enforcement during the appeal period, which is good.  I've added a note to clarify this.  However, that does not solve the issue of time-wasting frivolous appeals.  If I am given a private warning or banned for one day from an IRC channel to cool off, I can still appeal.  The original sanction remains in effect during the appeal process, but eventually DR must spend time reviewing the evidence and making a judgement. Mattflaschen-WMF (talk) 06:16, 28 September 2015 (UTC)
 * As member of the DevRel team, I believe that processing "frivolous appeals" will take significantly less resources than dealing with the potential problem of people unhappy with the rule that doesn't allow them to appeal. If there is a process, unhappy people can follow it. If there is no process, unhappy people will manifest their frustration in other ways, and they are likely to get more community sympathy because they were not given other option than complaining elsewhere. So if your concern is saving DevRel resources, please allow anyone to submit a recall to us. :) --Qgil-WMF (talk) 09:35, 28 September 2015 (UTC)
 * The restriction seems unnecessary; the committee can always agree that a complaint is frivolous and should be rejected - that does not seem like something that would take up a significant amount of time. Also, I disagree that appealing a two-month ban is necessarily frivolous. --Tgr (WMF) (talk) 07:59, 1 October 2015 (UTC)
 * Mattflaschen-WMF, I still think that we should remove "Only resolutions (such as bans) that last 3 months or longer may be appealed by reported offenders. Reported victims can always appeal." For the reasons expressed above. Unless you or someone else has a strong objection, I would like to remove this restriction in this review round.--Qgil-WMF (talk) 23:34, 7 December 2015 (UTC)
 * I understand where you're coming from (and that your team would be responsible for reviewing these appeals), but I still don't think a structure that encourages appealing every low-level decision (if everything is appealable, might as well give it a shot) is ideal. It's also worth noting that this is already a compromise.  It originally only allowed permanent decisions to be appealed.  See  and Talk:Code_of_Conduct/Draft/Archive_1. Mattflaschen-WMF (talk) 00:34, 15 December 2015 (UTC)
 * You're both making great points, I'm not sure what to suggest myself. I see point and share the worry about abuse of the appeals process, but I think there's another point to be made: why three months? If we make this rule to only allow for appeals for "big" decisions, then why doesn't a month-long or two-month-long decision deserve to be included? The choice of three months seems (and may be raised by others as) a bit random. This is especially true when even a month-long ban from certain technical spaces can absolutely be taken as a very long time, indeed. I think that if we're time-boxing this, we are risking two main problems: 1: That people will be frustrated that they can't appeal shorter times (two and a half months? two months? why not? etc) and 2: That this will make it seem, to the committee, that any decision under three months is "light" or "short" action, which may actually not be true at all, depending on the situation. Another issue we may run into is that sometimes even decisions that don't carry an actionable sanction may actually carry reprecussions, so the question can be asked about why these can't be appealed. Then again, this does risk abuse to the DevRel team, or the committee.
 * I think this is one of those cases where it is wise of us to lean on the side of caution (and remove the restriction) and, if DevRel team sees that this is abused in an unmanageable way, perhaps follow up later, in that case, to enforce some minimum. That will also let us analyze the actual situation and see what minimum actually makes sense, rather than making this judgment before the fact with a time limit that sounds random. MSchottlender-WMF (talk) 01:19, 15 December 2015 (UTC)

About "any member of the community may raise concerns"... what does that mean in practice for the Committee or Developer Relations? Are we saying that others may appeal on behalf of the reported offender? The statement is true regardless, since freedom of expression is granted in our channels, so if "raise concerns" doesn't mean an action that Commitee or DevRel must take, I would remove it.--Qgil-WMF (talk) 08:24, 25 September 2015 (UTC)
 * It does not grant an appeal right. Under the current draft, observers can not appeal.  It is just noting that people can communicate with them.  I don't object to removing this. Mattflaschen-WMF (talk) 06:16, 28 September 2015 (UTC)

Finalize "Report a problem" section?
Should the "Report a problem" section be considered done? Mattflaschen-WMF (talk) 01:37, 30 October 2015 (UTC)
 * I forgot to link the version in question. Please evaluate this version, which is the version as of when I created this talk page section.  Mattflaschen-WMF (talk) 19:11, 30 October 2015 (UTC)
 * Consensus reached. There was consensus here on the main section.  We started a separate section about the confidentiality sentence (there was feedback both here and by anonymous email about that).  Quim proposed text, with no objections, so that's incorporated.  Tgr also made a small clarification and linked it below.  So (reflecting just the above) the difference between what I linked above and the current text is here.  Ignore the parts of the diff below "Attribution and re-use".  Those sections are not part of "Report a problem". Mattflaschen-WMF (talk) 00:49, 25 November 2015 (UTC)


 * as proposer. I think this is pretty straightforward.  It says who you can report to, asks but doesn't mandate that maintainers take action (this was a compromise; I would have preferred otherwise, but that's how compromises go), and is clear that you can report to the committee if previous reports fail.  It also says that minimal reports will be accepted, but that more information will help.  All and all, I think it's a pretty practical approach. Mattflaschen-WMF (talk) 01:37, 30 October 2015 (UTC)
 * I fixed some incorrect wording.
 * "All reports will be processed confidentially" feels too vague. What it means for the Committee is well specified in its own section, but how exactly should maintainers handle a report? (Can they share with the Committee? With other maintainers? WMF HR? What can they share with the perpetrator if the case is not clear-cut and they want to hear both sides?)
 * It would be useful to have something along the lines of "If you send a report to maintainers, include a reference to this document." In practice, most people - even most maintainers - are not going to be familiar with the policies. --Tgr (WMF) (talk) 05:43, 30 October 2015 (UTC)


 * (for clarification: I give this "+1" as a contributor, who hasn't worked on this Code of Conduct so far, and is meant, as one part, that I (as a "normal" contributor) understand this section (so you could assume, that it's well-written), and, as the other part, I can identify my self with this proposal, or better said: I would accept it so, if someone would ask me now :)) --Florianschmidtwelzow (talk) 14:36, 30 October 2015 (UTC)
 * There are a couple of things that I think we compromised a bit too much on, but as was mentioned in the first comment, that's how compromises go. I think this is a good version to continue onward with. MSchottlender-WMF (talk) 18:52, 30 October 2015 (UTC)
 * Although I have no objections in improving the sentence about confidentiality, to set the right expectations.--Qgil-WMF (talk) 22:12, 30 October 2015 (UTC)
 * Would not object to improving the clarity of confidentiality as others have mentioned. AGomez (WMF) (talk) 22:22, 5 November 2015 (UTC)
 * Looks good to me. Kaldari (talk) 04:15, 9 December 2015 (UTC)

"All reports will be processed confidentially"
"All reports will be processed confidentially" feels too vague. What it means for the Committee is well specified in its own section, but how exactly should maintainers handle a report? (Can they share with the Committee? With other maintainers? WMF HR? What can they share with the perpetrator if the case is not clear-cut and they want to hear both sides?) --Tgr (WMF) (talk) 05:43, 30 October 2015 (UTC)

An email received at conduct-discussion@ also suggests a need to be more specific. The sender mentions the example of complaints involving private events. If person A sends person B an inappropriate private message and person B complains about it, if person A is warned or sanctioned they will be aware that person B complained when they are told the reason for the sanction.--Qgil-WMF (talk) 11:53, 30 October 2015 (UTC)
 * In this scenario (assuming a sanction is necessary/appropriate) there's no way I see to avoid the offender knowing who the reporter is. However, in such a case, it's probably best they report to the committee or to an event contact they trust.  The Committee members must commit to certain procedures (see "The Committee must get consent from the reporter before revealing any confidential information (including the reporter's identity)." of the draft section) to even be a nominee (as part of committing to comply with the full CoC).  It's not clear if we can expect all maintainers to commit to such detailed procedures (or even remember them 100%).  Also, the Committee may have better judgment whether a sanction is necessary in such a case (if it's not, there's no need for the alleged offender to know there was a report). Mattflaschen-WMF (talk) 19:21, 30 October 2015 (UTC)
 * The feedback is about improving the sentence, not about trying to apply it strictly in reality. It might be enough to say: "Reports are processed confidentially. For more information, see Confidentiality." and explain the details there.--Qgil-WMF (talk) 21:59, 30 October 2015 (UTC)
 * Mattflaschen-WMF, I hope my proposal is clear after my last comment. It is a minor edit on the current text, other people has expressed their support to be more clear about the confidentiality, and there have been no objection to the wording proposed after more than two weeks. Are you ok resolving this topic and moving forward?--Qgil-WMF (talk) 11:50, 18 November 2015 (UTC)
 * Yes. There have been no objections in over three weeks. Mattflaschen-WMF (talk) 22:58, 24 November 2015 (UTC)

If you send a report to maintainers, include a reference to this document
It would be useful to have something along the lines of "If you send a report to maintainers, include a reference to this document." In practice, most people - even most maintainers - are not going to be familiar with the policies. --Tgr (WMF) (talk) 05:43, 30 October 2015 (UTC)


 * I don't think this sends a message of confidence to someone sending a report. There is a finite number of existing admins and maintainers and it shouldn't be that difficult to contact them when this CoC is approved (and before, in our general call for feedback and approval). New admins / maintainers are granted permissions following a process, and it should be easy to mark an acknowledgement of the CoC as part of that process.--Qgil-WMF (talk) 22:04, 30 October 2015 (UTC)
 * Seems unrealistic to assume that everyone who ever contributed an extension to gerrit will read and remember the code. People have been trained pretty thoroughly to ignore terms of use. --Tgr (WMF) (talk) 07:29, 2 November 2015 (UTC)
 * It is realistic to assume that every maintainer receiving an email about "IMPORTANT: Code of Conduct for Wikimedia Technical Spaces" will be aware that a Code of Conduct exists, even if they haven't read it. It is also realistic to think that even if they are confused about receiving a report, they will ask someone or somewhere what to do with it. If the maintainer doesn't do any of this, it is realistic to think that the reporter will go for "You can also send a report to the Committee if you reported an incident elsewhere but were not satisfied with the response." I think your proposal sends a subliminal message to the reporters: "the person you are sending this report to may have no idea what you are talking about". How serious is this community about this CoC, then? -- the reporters may think. This defeats the purpose and effectiveness of this CoC, and this is why I think we should not integrate it. A good promotion of the CoC is the correct response to your valid concern.--Qgil-WMF (talk) 11:04, 2 November 2015 (UTC)
 * I agree with Quim. After spreading the word, we can assume all maintainers at least know the document exists.  They may not remember all the details, or always respond properly, but there are ways to deal with that.  We don't need to instruct people to explicitly inform the maintainer of the CoC. Mattflaschen-WMF (talk) 21:43, 4 November 2015 (UTC)
 * I agree that people should at least have awareness from the emails, etc. that this exists. Additionally, it's uncomfortable and difficult to report an incident - requiring a link to the document is another potential (small) hurdle that could be avoided. AGomez (WMF) (talk) 22:22, 5 November 2015 (UTC)

Logging actions of the Committee
The draft mentions that the Committee must log their actions. The Committee members can define the details themselves when they are formed, but maybe it would be good to set some framework in the draft itself. What actions are absolutely required to be logged (each report and its resolution, anything else?). Also, is this log public, private, both (in which case, what needs to be private/public)? This is probably closely related to the tool the Committee should use to handle reports and discuss them. See T112859 Code of Conduct reports to be handled via OTRS?. Same for Developer Relations and the cases transferred to them.--Qgil-WMF (talk) 09:01, 25 September 2015 (UTC)


 * Following up on Talk:Code_of_conduct_for_technical_spaces/Draft, probably the following should be logged:
 * Each report and its initial outcome (initial outcome is before notifying affected people)
 * Altered outcome (if it gets altered after notifications)
 * Decides to finalize (this could be combined with another log entry if it happens at the same time; see Talk:Code_of_conduct_for_technical_spaces/Draft.
 * The log should be private. The report itself and internal case deliberations will always be private.  Certain outcomes, e.g. "Taking no further action" and "private reprimand" are also private. Given that, and because the log must be somehow (directly or indirectly) be linked to the reports and case deliberations, that means the log must also be private. There will need to be a separate place for certain public actions (e.g. public reprimands), but the Committee can handle that part. Mattflaschen-WMF (talk) 06:49, 28 September 2015 (UTC)


 * As far as I can see, these privacy requirements can be handled via OTRS. Or probably via a Google Group, but I'd rather use a tool hosted in Wikimedia servers.--Qgil-WMF (talk) 18:26, 4 November 2015 (UTC)
 * I think we can leave the real nitty-gritty procedural details (private wiki vs. OTRS vs. private mailing list vs. etc.) to the committee. That keeps the CoC shorter, means we don't have to decide it now, and gives them flexibility on a non-substantive matter.  Other than that, do you see anything missing from the draft?  Initial outcome, altered outcome, and "begins enforcing" are also explicitly called out in the draft for logging now. Mattflaschen-WMF (talk) 21:53, 12 November 2015 (UTC)
 * I like the idea of the Committee sorting out this implementation detail. There is no reporting before committee, so no need to process incoming reports before a committee exists and is ready to receive them.--Qgil-WMF (talk) 11:43, 18 November 2015 (UTC)
 * There is no reporting to the committee before the committee exists. However, reporting to other people, such as maintainers, will still be possible and encouraged. Mattflaschen-WMF (talk) 22:54, 24 November 2015 (UTC)

Done, down or defunct?
Nothing happens here? I am Mister Thrapostibongles (talk) 21:48, 17 November 2015 (UTC)
 * Some weeks are more busy than others. Wednesdays have become our usual checkpoint for review and today is Wednesday, so perhaps... In any case, thank you for the ping. :) I will comment on the relevant sections about the next steps.--Qgil-WMF (talk) 11:41, 18 November 2015 (UTC)


 * I see this document as having lost its way after having a couple of WMF employees over manage the process for creating it. Non-WMF employee edits on the draft have dropped to zero, and unpaid volunteers that did take part in discussion have been eroded away. The outcome is naturally a WMF document, rather than a policy created with the positive support of the community. Above mentioned post-release consultation, inviting what will probably be the same old rejected comments to be rejected again, is not the way to build a credible consensus. --Fæ (talk) 07:19, 4 December 2015 (UTC)


 * I think the current silence is more related to the fact that discussing processes is less controversial than discussing principles. Overmanaging? We have organized the discussion to slow down the initial speed, volume and complexity of posts, which was definitely driving away people without the time to catch up, including most volunteers. The CoC keeps being open to edits and discussion by anybody, and we are reporting progress and requests for feedback to wikitech-l on a weekly basis. The goal is to promote hospitality and respect in our technical community, and to prevent the opposite. I think we are progressing toward that goal.--Qgil-WMF (talk) 10:46, 4 December 2015 (UTC)
 * One need only compare the declining numbers of unpaid volunteers making non-trivial contributions per week since this opened, against those with WMF contracts, to assess which types of participant this WMF employee directed process encourages and judge which others are effectively rebuffed. Perhaps only a handful of volunteers will care either way, however I see this as an unfortunate missed opportunity for meaningful consensus, and a flaw that is likely to be challenged when it needs to be applied in any difficult cases. --Fæ (talk) 19:36, 4 December 2015 (UTC)
 * We promoters of the CoC also want increasing numbers of people participating in its definition. Any ideas? For what is worth, 45 people are watching this page regularly, which is a respectful level of observation of the process. Your division between WMF paid staff and volunteers might be a bit misleading though, because it might suggest that WMF employees are pushing in a same direction, when the reality of our discussions here shows otherwise. It also might suggest that WMF employees look more after their own interests than after the interests of volunteers when, again, the discussion shows that this is not the case.
 * All in all I think we are drafting a good Code of Conduct, providing enough time to everybody to propose improvements.--Qgil-WMF (talk) 22:18, 7 December 2015 (UTC)

A few electrons rearranged. Anything happening in the real world? Anywhere away from this page? Any future to this project? Anyone responsible? I am Mister Thrapostibongles (talk) 14:34, 26 January 2016 (UTC)
 * https://phabricator.wikimedia.org/T90908 is active AFAICT. --Elitre (WMF) (talk) 14:50, 26 January 2016 (UTC)
 * Got it. Discussion moved to WMF insider discussion board, already taking place in parallel.  No notification here, no forwarding address.  Obvious that outsiders are not welcome. Still nothing happening in real world outside WMF offices.  Note that posting of 15 Sep 2015 at 6:05 says "If we are still working on anything but appointing people to the committee in January 2016 something is horribly horribly horribly wrong."   No further comment necessary.  I am Mister Thrapostibongles (talk) 07:08, 27 January 2016 (UTC)
 * Well, no? (and Phab isn't the "WMF insider discussion board". It's the movement's project management tool, and helpful community members actively using it may dislike your characterization). There have always been multiple venues for discussing, since the very beginning - first I heard about CoC was on some mailing lists, for example. It is entirely possible it's still being discussed there - I just don't know, I don't follow them so regularly these days. Sad to hear this fragmentation seems to be preventing you from contributing to it, though. --Elitre (WMF) (talk) 11:41, 27 January 2016 (UTC)
 * The Phabricator task isn't being hidden from anyone. It is linked from the code of conduct draft as the very first "See also" (first added there end of July).  This is the main talk page, but people are going to participate in various ways (we even accept anonymous feedback), like with any project. Mattflaschen-WMF (talk) 00:19, 3 February 2016 (UTC)
 * yes the discussion moved to T90908 and you are right that it should go back to this discussion page. The reason why this happened is that such Phabricator task is/was fulfilling different roles: a Wikimedia Developer Summit session (we used the task to coordinate preparation and to post the minutes) and Developer Relations quarterly goal (I posted there my notes related to the quarterly review). This activity in the task combined with the lack of visible progress here helped pulling the discussion there. I will ask the participants in the task (myself included) to focus the discussion here.
 * The main reason for the lack of progress in the draft has been our conclusion that we need expert advice to assure that the processes defined is sensible and effective. Other organizations have been using codes of conduct in their communities, others before us have found themselves in problems like we are discussing (i.e. privacy of reporters versus legal obligations of the Foundation), and at some point we decided to slow down our own drafting and seek specialist advice. This is how we got in touch with Valerie Aurora and Ashe Dryden, who are starting to help us with answers and feedback as we speak.
 * I hope this explanation helps. The Code of Conduct keeps being a priority for the Developer Relations team and for the people that are working on it on their own initiative and volunteering time. We want to do it right and this is taking more time than we thought. Still, we will keep focusing on quality rather than deadlines.--Qgil-WMF (talk) 12:49, 27 January 2016 (UTC)
 * Note, Ashe's surname is Dryden. I've edited Quim's post accordingly. Mattflaschen-WMF (talk) 00:28, 3 February 2016 (UTC)

Valerie Aurora and Ashe Dryden
With regard to "we got in touch with Valerie Aurora and Ashe Dryden", can you publish the invitation to tender for the work that these consultants are being paid for where unpaid volunteers can read it? Can you also explain who the "we" is that was in charge of the final procurement decision. Thanks --Fæ (talk) 13:38, 27 January 2016 (UTC)
 * Why would there need to be a tender? Valhallasw (talk) 14:02, 27 January 2016 (UTC)
 * The WMF supports professional procurement standards, so either there's a job spec for contractors to apply for, or there should be an ITT, or this was part of an existing contract. Either way, there should be a document/spec that can be openly published and the procurement work-flow explained.
 * Purchasing_and_disbursements_procedures appears to apply, unless you can point me to a more relevant procedure. --Fæ (talk) 15:34, 28 January 2016 (UTC)
 * That page doesn't say anything about procurement, and even explicitly states "we strive for the proper balance between appropriate safeguards and controls (...) and undue bureaucracy". In my experience (in a university environment, where there *are* explicit procurement procedures), we can just pay someone to set up or fix a machine -- no long-term contract necessary. I'm not sure why that would be different for the WMF -- if anything, it should be easier.
 * In addition to the formal rules, why does it matter (content-wise) why there is a tender or not? Do you feel Valerie and Ashe are not suited to the task? Do you feel someone from the community should have been hired instead? As far as I can see, Valerie and Ashe have experience in the area of writing and upholding codes of conduct, so it sounds reasonable to me to ask them to look over the process here. Valhallasw (talk) 10:02, 29 January 2016 (UTC)
 * Sorry to contradict you as you are a WMF employee, but the link I provided is about contracts and purchases, so I read that as a procurement procedure. The quote you have taken is from a section of that document that goes on to state "Purchases that involve contracts need to go through contract review", so there is a specification for this work that can be published, if there was a review of it.
 * Procurement procedures are there to ensure legal and ethical governance of funds. As a manager/director and consultant, I have experienced many environments including academic, commercial and governmental and have had responsibility for auditing procurement processes in all of them, as well as deploying processes.
 * This is not a question of challenging the competence of these contractors, but ensuring that their contracts have been placed in a way that will not compromise the WMF or them.
 * It would be sensible to have an answer from the person that had authority to place this contract, rather than general speculation, though I can raise this question formally with WMF HR or WMF Legal if that is needed. Thanks --Fæ (talk) 08:53, 31 January 2016 (UTC)
 * I have raised this question to WMF Legal already, in order to assure that you get a correct answer.--Qgil-WMF (talk) 21:58, 1 February 2016 (UTC)
 * I am not a WMF employee (nor a contractor). I understand the goals of procurement, but I still don't see how the specific process used in this situation is relevant to the code of conduct discussion. Valhallasw (talk) 13:25, 31 January 2016 (UTC)

Please let me reply and wrap up this question. I agree it is off-topic in the CoC discussion; if anyone wants to follow up, please choose a different venue. The two contracts have small budgets covering an amount of hours of consulting. They were organized by me as part of my responsibility as Engineering Community Manager, checking with the Code of Conduct promoters and the Wikimedia Developer Summit organizers (Valerie helped us co-organizing this event as well). I followed the normal WMF procedures for contracting vendor services, going through WMF Finance and Legal review as well as approval by my manager. Both consultants are recognized experts in their field and are fit for the tasks requested.--Qgil-WMF (talk) 07:52, 2 February 2016 (UTC)

The above hidden request for information has been raised by open letter/email to the WMF CFO at http://www.gossamer-threads.com/lists/wiki/foundation/680114. Any information or thoughts can be raised at Wikimedia-l as questions about the expert advice for this draft policy are considered off-topic in this discussion about the draft policy. Thanks --Fæ (talk) 16:58, 15 February 2016 (UTC)

Finishing the Cases page
The Cases page is all about process: handling reports, responses and resolutions, and appeals. I propose to start a call for feedback at wikitech-l, allowing for edits in that page and discussing here any open topics. If by next Wednesday edits and new topics seem to be settled, we could open a review period for support / neutral / oppose statements, as we have done with previous sections.--Qgil-WMF (talk) 11:57, 18 November 2015 (UTC)
 * , I hope you don't mind if I mention this section in the new Developer Relations/Weekly summary. There was no fresh beef about the CoC last week, and I don't want to miss the chance of mentioning it today.--Qgil-WMF (talk) 10:30, 19 November 2015 (UTC)
 * No, an announcement sounds good. Mattflaschen-WMF (talk) 23:32, 24 November 2015 (UTC)
 * Thanks for starting this section. I've renamed it consistent with the past terminology.  I will send out an email regarding this.  I think we should give more time to finish this section, though, so I think we shouldn't set a date for the beginning of the review period yet.  Mattflaschen-WMF (talk) 23:32, 24 November 2015 (UTC)

Removing detail in Code_of_Conduct/Draft?
The list of possible responses at Code_of_Conduct/Draft contains a lot of implementation details, and I'm not sure we need this. Enumerating the possible responses is useful. Defining in the document how exactly those responses need to be made is probably premature. The Committee can define their procedures as they go, and they can probably fine tune them based on experience. I don't see any implementation detail so critical that needs to be agreed and written beforehand. Are there any objections to remove them?--Qgil-WMF (talk) 19:44, 8 December 2015 (UTC)
 * The goal is for Code of conduct/Cases to be a secondary page, but binding, much like e.g. https://jquery.org/conduct/enforcement-manual/ (which it is partly based on). What specifically do you want to remove?  Perhaps you can copy the current text to user space, save that, make the edits you want, then link to the diff with the removals you want. Mattflaschen-WMF (talk) 00:50, 15 December 2015 (UTC)

Translation
Should we mark this for translation now, even though there will be ongoing changes? Or wait until it's approved? Mattflaschen-WMF (talk) 01:02, 22 January 2016 (UTC)
 * I would not bother translators before we have gone through the draft.--Qgil-WMF (talk) 09:34, 22 January 2016 (UTC)

Harassment Survey 2015
(Bringing my thoughts on the Phabricator task over here. Apologies for the confusion)

Unfortunately given the results of the recent harassment survey I'd say we don't have to worry about external trends to influence our decision. Harassment is something our community needs to deal with. An enforceable code of conduct is (one) first step to addressing these issues.

For others tracking this work who have not read it, I suggest reading the survey results. It is something relevant and worth reviewing in light of this discussion.

https://meta.wikimedia.org/wiki/Research:Harassment_survey_2015

Ckoerner (talk) 04:33, 2 February 2016 (UTC)


 * What's the connection between harassment on Wikipedia and harassment among Wikimedia technical developers? Isn't that like extrapolating from the behavior of people who go to bars to the behavior of people who brew beer? Yaron Koren (talk) 01:21, 11 February 2016 (UTC)
 * The scope of the survey is Wikimedia projects, which includes Wikimedia technical spaces.--Qgil-WMF (talk) 08:57, 11 February 2016 (UTC)


 * My apologies - I thought this was a purely Wikipedia-based survey, but I see (according to page 24), that 92% of the people who reported being harassed had it happen on Wikipedia, while 1% had it happen on "MediaWiki" (whatever exactly that means). I'd say my original point still stands, though, statistically speaking. Yaron Koren (talk) 01:29, 12 February 2016 (UTC)


 * In order to know whether your point stands or not, we still need a data point: the percentage of visitors of "MediaWiki" that were harassed in "MediaWiki". To put an extreme example, if 99% of the participants in the survey were not harassed in "MediaWiki" but didn't visit it either, that would mean that the 100% of the rest (1%) were harassed in "MediaWiki" indeed.
 * But there is a simpler point to all this. There is harassment and disrespect in Wikimedia technical spaces. I have seen it, I have spoken with others that have suffered it, I have got to deal with it, and I'm sure what I have seen is only a portion. That is what motivates me to support this work.--Qgil-WMF (talk) 07:07, 12 February 2016 (UTC)
 * MediaWiki has about 3% as much active users and 0.2% as much pageviews as enwiki, so it does not seem like it's particularly underrepresented in the responses.
 * That said I think the most helpful thing that could happen to this discussion in its current state would be testimonials about past harassment, instead of vague claims that person X has heard about many / other communities have lots so we must have too. I understand this is a sensitive issue, the target of harassment does not always want to speak about it, or might become a target again by speaking out, but even so I doubt it's hard to find examples where the subject is willing to talk about it. --Tgr (WMF) (talk) 17:09, 12 February 2016 (UTC)
 * Qgil - I wasn't making any statement about harassment, just questioning an apparently flawed analysis by Chris. Tgr - I wasn't criticizing the survey, just questioning its applicability. Yaron Koren (talk) 01:25, 13 February 2016 (UTC)

What's in a title?
Ricordisamoa mentioned in the phabricator task:

"I would be glad if you clarified that the "goal" is to have the draft complete and submitted for consensus, not to have it enforced regardless of the consensus. Thanks in advance. " From the task description: Measurement of success Code of Conduct for Wikimedia technical spaces draft completed and submitted to community discussion. Proposal approved with community support. Committee created.

Emphasis is mine. I see what you're saying though Ricordisamoa. Maybe the title should read "Goal: Community-approved, binding code of conduct for all Wikimedia technical spaces with consequences for breaches".

What do others think? CKoerner (WMF) (talk) 20:41, 10 February 2016 (UTC)
 * I replied at the task. Mattflaschen-WMF (talk) 21:04, 10 February 2016 (UTC)
 * I replied at the task. -- Ricordi  samoa  22:39, 10 February 2016 (UTC)
 * I think the title and measurements of success of that task are correct, they describe with accuracy what we are aiming for and the steps to achieve it. I'd rather keep pushing a precise goal allowing people to position themselves than diluting it in more vague intentions that are less actionable, leading ultimately nowhere. PS: and please let's focus the discussion here, keeping the Phabricator task for updates only.--Qgil-WMF (talk) 09:08, 11 February 2016 (UTC)

Considering the model of Rust's community Moderation team
In the context of Requests for comment/Governance, the Architecture committee is discussing the creation of specialized working groups. One proposal is to Create a Wikimedia equivalent of Rust's Moderation subteam (T126605). Let's discuss this idea here, since this directly affects the current draft about the Code of Conduct Committee.

Required reading: https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md#moderation-team

Related: https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md#community-norms-and-the-code-of-conduct

Needless to say, I like the idea of a community team in charge of solving the problem of harassment and disrespect in Wikimedia technical spaces. I also like the idea that such team is connected to the Architecture Committee, which is the only community governance body we have (currently in the draft, the CoC committee appears more connected to WMF's Developer Relation team). All in all, I think Rust's Moderation team can be a good precedent and example for us. Being one of many working groups connected to the ArchCom would make this team part of a bigger and consistent structure, instead of a single entity on its own.

About the name, yesterday I had a conversation with where he said that "Code of Conduct committee" is a name too tight to a specific solution, whereas "Moderation committee" points more to the problem that needs solving. I think this argument is reasonable, and anyway "Code of Conduct committee" is not a great name.--Qgil-WMF (talk) 08:59, 12 February 2016 (UTC)
 * I am fine renaming "Code of Conduct Committee" to "Moderation Committee". What do other people think? Mattflaschen-WMF (talk) 21:20, 12 February 2016 (UTC)
 * "Moderation Committee" or "Moderation team" both sound good to me. -- Gabriel Wicke (GWicke) (talk) 18:37, 17 February 2016 (UTC)
 * "Moderation team" sounds to me even better than "Moderation Committee", but I don't have a strong opinion.--Qgil-WMF (talk) 08:34, 22 February 2016 (UTC)

Definition of maintainers, again
Please state clearly whether I am to be considered an administrator and/or a maintainer according to the current Draft, and where, in order to allow me to resign before I am held liable of something I don't understand. -- Ricordi  samoa  23:06, 12 February 2016 (UTC)
 * do you have special permissions (admin, +2) in any Wikimedia technical space?--Qgil-WMF (talk) 08:59, 15 February 2016 (UTC)
 * I am not a member of the MediaWiki "sysop" group on either mediawikiwiki or labswiki; I am, however, a member of [//gerrit.wikimedia.org/r/a/accounts/Ricordisamoa/groups/ several groups] of project owners on Gerrit. Thanks in advance. -- Ricordi  samoa  23:32, 15 February 2016 (UTC)
 * Then this refers to you (or anybody in your situation) in the context of the Wikimedia technical spaces used by the projects where you have +2 permissions: "Project administrators and maintainers have the right and are expected to take action on any communication or contribution that violates this Code of Conduct." I hope this helps clarifying the "where" in your question. However, I still don't understand what is the specific problem that would make you resign as maintainer. I'm pretty sure you understand harassment and disrespect when you see it, and I bet you understand the difference between rights, expectations, and liabilities.--Qgil-WMF (talk) 07:48, 16 February 2016 (UTC)
 * Speaking of expectations - does "expected to take action" mean that admins/maintainers will be penalized if they don't? And if so, what's the penalty? The code of conduct has never been clear on this, despite various wording changes. Yaron Koren (talk) 20:34, 16 February 2016 (UTC)
 * I still think my previous reply to this question applies: "The reasons for someone not to report a violation may be so diverse that I would not attempt to define a rule for them all. The person might be an indirect victim, not reporting fearing retaliation. The person might be an accomplice, allowing an act of harassment on purpose. These might be the type of complex cases requiring investigation from the Committee, mentioned in the draft."
 * Let me ask you the complementary question. Imagine that you see a user harassing another user in Gerrit changesets or phabricator tasks related to SemanticForms, a project you maintain. The harassment continues. Nobody else seems to be doing anything to stop it. What do you do?--Qgil-WMF (talk) 10:56, 17 February 2016 (UTC)
 * I'd probably ask them to stop; if they didn't, I'd probably try to take away their commit privileges for my projects. I probably wouldn't report them, though. But it all really depends on the circumstances - as you note, there are a lot of potential factors. But to go back to my question - is it possible that an admin might be punished for not informing on others? And if so, what might that punishment possibly be? The document should really spell it out, one way or the other. Yaron Koren (talk) 14:01, 17 February 2016 (UTC)
 * I have been given merge rights in Pywikibot because I knew the code and existing owners trusted me not to merge bad code. I see nowhere implied an increased right and/or responsibility to patrol those repositories and act against harassment compared to non-maintainers. -- Ricordi  samoa  05:13, 18 February 2016 (UTC)

the root of the discussion is whether social problems are within the scope of admins and maintainers. The CoC proposed indicates that yes, social problems are within the scope of problems that admins and maintainers are expected to contribute to solve. If you disagree on principle, then we will have to agree to disagree. If you disagree because this principle might lead to situations unjust for maintainers, then please provide plausible examples. So far you seem to be more concerned about the comfort of maintainers than about the harassment on contributors.--Qgil-WMF (talk) 08:32, 22 February 2016 (UTC)


 * I have various answers I can give, but before that I'm curious about your phrase "the comfort of maintainers", which would seem to indicate that yes, admins can be punished for not informing on the activities of their users. Is that definitely the case? I have yet to hear a clear answer on that. Yaron Koren (talk) 14:35, 22 February 2016 (UTC)
 * How can you think about "comfort"? Think of the selfless volunteers, whose technical skills benefit the communities, who have never engaged in harassment against anyone, who do their best to keep the spaces clean, whom you want to turn forcibly into moderators. -- Ricordi  samoa  04:52, 23 February 2016 (UTC)
 * I think you are making a big fuzz out of this. In the more than three years that I have been working at the Wikimedia Foundation, I have received multiple reports from people in the lines of "Hey, just fyi, this is happening: (URL)". That is "to take action" and that is all what they needed to do in those cases. Yes, I'm talking about maintainers' comfort because no matter how uncomfortable it is for a maintainer to send such one liner in an email, the situation is clearly more uncomfortable for the ones being harassed. In the example provided by Yaron, he says that as a maintainer he would take action himself, which is in line with the CoC's expectation. The message is that it is not OK for maintainers to ignore harassment happening in their projects in front of their noses just because "I'm here to review code". The committee and the admins cannot have their eyes in every single task, changeset, mailing list, etc, we need to rely on others willing to help when harassment happens, even if it is with a simple ping + URL.--Qgil-WMF (talk) 08:24, 23 February 2016 (UTC)


 * I find it incredible that you refuse to answer my question - and that you want people to agree to ambiguous wording that apparently no one, not even you, fully understands. Yaron Koren (talk) 14:34, 23 February 2016 (UTC)
 * I do not think it is OK for anyone to ignore harassment happening anywhere. However, project admins are no better equipped to handle harassment than ordinary contributors. It makes sense to me that both victims and witnesses of harassment (including admins, etc.) should report directly to the Committee and/or to special-purpose moderators. -- Ricordi  samoa  04:47, 24 February 2016 (UTC)
 * Merging code and patrolling behaviour strike me as very different jobs. I would agree (also because of some history I've seen on enwiki about bot programmers with persistent issues at working well with others) that it is not good to make the same people by default responsible for both.Jo-Jo Eumerus (talk) 08:29, 24 February 2016 (UTC)

It looks like the consensus is going in the direction of removing this line altogether: Talk:Code_of_Conduct/Draft. I was not refusing to answer your question, as in I had an answer but I didn't want to write it down. I think you were forcing an answer that could not be defined in advanced, and that should be looked case by case by the committee in charge of enforcing the CoC (is it possible that an admin might be punished for not informing on others? And if so, what might that punishment possibly be?. Anyway, it looks like we can move on and focus on other things.--Qgil-WMF (talk) 08:44, 24 February 2016 (UTC)
 * Sorry for casting aspersions. I'm glad this particular topic is settled. Yaron Koren (talk) 16:10, 24 February 2016 (UTC)

The Committee elects their new members
Good recipe for a new Geshuri incident, isn't it? -- Ricordi  samoa  23:09, 12 February 2016 (UTC)


 * Your rhetorical question has a different answer than you might expect ('No, because the nominees are known far in advance'), but the question 'why isn't it an election' is a valid one. It was introduced after the discussion at Talk:Code_of_Conduct/Draft/Archive_1, but there was not much discussion on the committee deciding on their own members. is there a reason to prefer this over open elections? I can imagine the private feedback to be a reason, but a veto should then be good enough. Valhallasw (talk) 22:02, 13 February 2016 (UTC)


 * It's the same reason, e.g. no one is proposing that the whole MediaWiki community elect subteam leaders or members (see Requests for comment/Governance). It's a job that can benefit from specific experience and skills (though hopefully there will also be training).


 * Ricordisamoa, I think you'll be hard-pressed to find a process that doesn't sometimes lead to a bad outcome. We all know government elections don't always elect the right person, for example.  I think the current draft is a good process for this committee, but we should keep thinking about it. Mattflaschen-WMF (talk) 01:04, 18 February 2016 (UTC)

Suggested changes
These are some suggested changes to "Unacceptable Behavior" and "Report a problem" (version without change). They are based on feedback from the consultants as well as other people.

Please indicate your views with Support, Oppose, or just a comment. If you would support the change with some alterations, that would also be helpful to note. Based on this, I will determine if there is consensus for/against, or if people might support a modified version of the suggested changes (if it needs more work then another consensus discussion).

I apologize that this feedback arrived later than planned, but I think this will create a better document. Mattflaschen-WMF (talk) 01:43, 24 February 2016 (UTC)
 * I think there are some good changes in here (and have no issues with the length of time involved). Thank you for suggesting them. -- Krenair (talk &bull; contribs) 02:24, 24 February 2016 (UTC)

Clarification of legitimate reasons for publication of private communications and identity protection
Should the following clarifications be made regarding privacy?:
 * Add "Publishing or reporting private communication or personally identifying information for the purposes of reporting harassment (as explained here) and/or in the case of whistleblowing, is acceptable." after "Inappropriate or unwanted publication of private communication."
 * Add "Disclosure of some identifying information is not consent to disclose other identifying information." after "Disclosure of a person's identity or other private information without their consent."

Mattflaschen-WMF (talk) 01:43, 24 February 2016 (UTC)
 * The whistleblowing exception makes me feel much better about this (previously ridiculous) line. I'm not sure whether I'm fully convinced yet, but it's unambiguously an improvement.  Krenair  (talk &bull; contribs) 01:50, 24 February 2016 (UTC)
 * Both additions seem reasonable and provide useful clarification. Kaldari (talk) 02:42, 24 February 2016 (UTC)
 * Makes sense. --Smalyshev (WMF) (talk) 04:00, 24 February 2016 (UTC)
 * - Jmabel (talk) 05:00, 24 February 2016 (UTC)
 * --Qgil-WMF (talk) 08:11, 24 February 2016 (UTC)

When does something qualify as whistleblowing? Real-life whistleblower protection laws typically only cover some fairly specific things like breaking laws. Also, reporting private communication for the purposes of reporting harassment, sure; but publishing it is hardly justified by that. --Tgr (WMF) (talk) 07:54, 24 February 2016 (UTC)

Definitions - trolling, bad-faith reports
Should the definitions of trolling and bad-faith reports be clarified as follows?:
 * Replace "Trolling, for example by sustained disruption, interruption, or blocking of community collaboration." with "Harming the discussion or community with methods such as sustained disruption, interruption, or blocking of community collaboration (i.e. trolling)"
 * Replace "Reports of unacceptable behavior must be done in good faith to defend potential victims and to restore a friendly environment. Accusations of unacceptable behavior against potential victims or reporters done as a tactic to introduce more tension or confusion are unacceptable themselves." with (new text would be added in bullet point) "Using the code of conduct system for purposes other than reporting genuine violations of the code of conduct (e.g., retaliating against a reporter or victim by filing a report claiming their response was harassment)"

Mattflaschen-WMF (talk) 01:43, 24 February 2016 (UTC)
 * I know it was in the existing text but can you give some examples of "blocking of community collaboration"? I'd like to make sure we're all thinking along the same lines here. -- Krenair (talk &bull; contribs) 02:23, 24 February 2016 (UTC)
 * Makes sense too. --Smalyshev (WMF) (talk) 04:45, 24 February 2016 (UTC)
 * Jmabel (talk) 04:59, 24 February 2016 (UTC)
 * Doesn't seem to make much difference. "response" in the last sentence is probably the wrong word (or in any case I don't understand what it refers to). --Tgr (WMF) (talk) 08:05, 24 February 2016 (UTC)
 * --Qgil-WMF (talk) 08:13, 24 February 2016 (UTC)
 * Just to clarify, in the second item "response" in this context means that Person A files a report regarding Person B. Person B responds by filing a report against Person A as a from of retaliation. Is that right? CKoerner (WMF) (talk) 15:10, 24 February 2016 (UTC)

Marginalized and underrepresented groups
Should the following be added to the list of Unacceptable behavior, to back up the Principles section?:

"Discrimination against marginalized and otherwise underrepresented groups"

Some parts of the harassment survey (of all Wikimedia projects) show that Wikimedia has a particular problem with harassment against underrepresented groups. For example, figure 17 on page 19 shows that (for all but one type) female users were more likely than male users to experience harassment.

This proposed text would support the Principles text about this. Mattflaschen-WMF (talk) 01:43, 24 February 2016 (UTC)
 * I'm wondering whether age would count here. -- Krenair (talk &bull; contribs) 01:53, 24 February 2016 (UTC)
 * Yes, we should think about this in regards to 18+ restrictions in our technical spaces. Mattflaschen-WMF (talk) 03:17, 24 February 2016 (UTC)
 * An example to think about is Confidentiality agreement for nonpublic information, though this is not limited to technical (also, the limit is 16 for some roles). Mattflaschen-WMF (talk) 03:23, 24 February 2016 (UTC)


 * This one short phrase would, if I understand it correctly, add a whole other category of wrongdoing to the code of conduct: discrimination. That would open up a big can of worms, and seems like a very bad idea. (Not to mention that the phrasing makes it seem like you would be allowed to discriminate against some people, but not others... as I said, can of worms.) Yaron Koren (talk) 02:34, 24 February 2016 (UTC)


 * "Discrimination" is this context is pretty poorly defined term. Also, we have already said that it's not ok to mistreat and harass people, so adding "it is also not ok to do the same if the targets belong to underrepresented groups" is redundant. Moreover, it might even produce an impression as if it's less bad to mistreat people if they can't be assigned to any "underrepresented groups", which is certainly not what we want. --Smalyshev (WMF) (talk) 04:40, 24 February 2016 (UTC)
 * As Smalyshev (WMF) and Yaron Koren wrote, the proposed wording might be misinterpreted. -- Ricordi  samoa  04:53, 24 February 2016 (UTC)

What would it change? We already have "Offensive, derogatory, or discriminatory comments" which seems to cover this. --Tgr (WMF) (talk) 07:58, 24 February 2016 (UTC)

There might be a point on covering discrimination as a type of harassment, but it would need to be better defined. Examples of potentially discriminatory actions that are not clearly covered now: refusing to grant +2 to someone deserving it, rejecting a valid scholarship request, or a proposal for a session in an event... all this justified on technical grounds, fair principles, but in fact being motivated by a filter of discrimination. The type of discrimination against minorities and marginalized groups that we can see in similar circumstances in our societies.--Qgil-WMF (talk) 08:23, 24 February 2016 (UTC)
 * OTOH, it requires everyone to be mind readers: "Oh, he had solid technical reasons for denying that request, but we just know it was really because he's racist." It also explicitly legitimizes playing the race card as a tactic to harass someone for legitimately rejecting a request despite the second bullet in above. Anomie (talk) 15:00, 24 February 2016 (UTC)
 * Same concern here. Without identifyable pattern of behavior, it encourages guessing intent, which invites to abuse the system. How could you find out if something is "motivated by discrimination" or not? Short of explicit admission (which is unlikely to happen especially if complaint is filed) there is no way to objectively establish that. Which means people would resort to personal preferences and likings, and that would not go well. --Smalyshev (WMF) (talk) 20:39, 24 February 2016 (UTC)
 * I note that the article you links to there also includes the line "George Dei, et al., in the book Playing the Race Card argue that the term itself is a rhetorical device used in an effort to devalue and minimize claims of racism.". So concerns about use and misuse here go both ways.
 * In the situation where it is misused - and I honestly can't imagine one - people can choose not to enforce, or to prioritise the second bullet point. On the other hand, the absence of a rule means that if it is used legitimately the committee would have no recourse. Ironholds (talk) 02:43, 25 February 2016 (UTC)

If a contributor makes known their reason for their actions as being discriminatory, then it should be covered by the Code of Conduct. A silly example would be someone saying "I don't like left-handed people, so I didn't approve their merge."

While Trg points out that we do have language regarding discriminatory comments, we should be explicit and include discrimination as not just a comment, but purposeful actions as well. I agree with Quim that this should not be better defined, but it should be present. CKoerner (WMF) (talk) 15:41, 24 February 2016 (UTC)


 * per Chris. Ironholds (talk) 18:10, 24 February 2016 (UTC)

Enforcement issues
Should the following changes regarding enforcement be made?:
 * Remove "Project administrators and maintainers have the right and are expected to take action on any communication or contribution that violates this Code of Conduct."
 * Replace "Report the problem to the administrators, maintainers, or designated contacts of the space where the problem is happening." with "If you are at an event, report the problem to the event organizers, or a designated contact."
 * Add "Attempting to revert a decision of the Committee, e.g. unblocking someone during a period the Committee banned them" under "Unacceptable behavior"

The goal is to make the process more effective and clear.

Several people have objected to the provision about administrators and maintainers. If the first and second points were adopted, people would still able to talk to maintainers informally. But the text wouldn't imply a formal obligation existed.

The third point is in order to prevent wheel wars. The draft already has reconsideration and appeals processes. Wheel wars should not substitute for that. Mattflaschen-WMF (talk) 01:43, 24 February 2016 (UTC)
 * first two changes. Third one needs significant thought and work to ensure that only official committee-created blocks are enforced. Also remember that if a case is referred to someone acting on behalf of WMF (e.g. Developer Relations is mentioned), they cannot be allowed to control administrator decisions. -- Krenair (talk &bull; contribs) 02:03, 24 February 2016 (UTC)
 * the first two changes, as per Krenair. As others have noted, project admins are in charge of code, not of people. I have no opinion on the third one. Yaron Koren (talk) 02:41, 24 February 2016 (UTC)
 * the first two changes, as per Krenair and Yaron Koren. -- Ricordi  samoa  04:53, 24 February 2016 (UTC)
 * OK with the first one, with the second one I would leave the option to report to space maintainers - i.e., if that happens in team's space, maybe team leader can handle it. On the third, "attempt" sounds like very broad and may include legitimate discussion and appeal to the Commission to reconsider, for example. I don't think it's unacceptable. Maybe it should be "Attempting to circumvent a decision of the Committee" so it's clear it is about things done outside of the process? --Smalyshev (WMF) (talk) 04:57, 24 February 2016 (UTC)
 * Similarly, the first two, neutral on the third. Jmabel (talk) 04:59, 24 February 2016 (UTC)
 * Second and third sounds reasonable (Smalyshev's wording is fine too). I would prefer keeping the first but rewording so that it doesn't suggest an obligation (e.g. replace "expected" with "encouraged"). --Tgr (WMF) (talk) 08:04, 24 February 2016 (UTC)
 * to the three points (although seeing the comments it might be worth to have an own section about the third). I have expressed my opinions about the added moral obligations of administrators and maintainers, but I'm fine removing that line. I think this point is more contentious in theory than in practice, and I see no point in keeping fighting about it.--Qgil-WMF (talk) 08:29, 24 February 2016 (UTC)
 * First and second points, regarding third one Smalyshev's wording seems better to me.Jo-Jo Eumerus (talk) 08:34, 24 February 2016 (UTC)

Whole (or majority of) committee disqualification for CoI
The section about CoIs should probably mention what to do in this case (and probably any case below a certain number of qualified committee members). Also, confidentiality should be clarified - it would not be okay for someone disqualified from participating to be able to see confidential parts of the case. -- Krenair (talk &bull; contribs) 02:06, 24 February 2016 (UTC)

"unwanted public ... communication"
I would not restrict public communication simply on the basis of whether the recipient wants to read it. That is too close to censorship and too likely to be abused. I would guess that most misconduct in research and business results in unwanted public communication necessary to resolve the situation. 67.6.166.191 13:02, 24 February 2016 (UTC)

Seems to be a lot of unanswered questions and gray areas
I realize this is in a very rough draft but I notice there seems to be a few problems with the mechanics of this new idea. For example:
 * 1) Comment: If the same people doing enforcement on this new "committee" are the same ones who currently aren't doing it and should be within their individual projects (such as the Arbcom's), I doubt it will make much difference.
 * 2) Recommendation: I recommend that if the person is currently on an Arbcom, OTRS or is a member of another like committee, they cannot be on this as well.
 * 3) The Code of Conduct also seems to indicate there would be some boomerang effect if the submission was deemed to be in bad faith. So here is my concern. Editor X submits a concern to the code of conduct committee on admin/editor Y and then the committee blocks the editor for bad faith which would hurt the credibility of the committee.
 * 4) Can an editor submit a request to the code of conduct committee on a group (like a group of editors at an ANI decision, RFC or OTRS)? I request clarification because it's almost certainly going to happen.
 * 5) Will this committee have the power to override the Arbcom's or a community RFC? For example, can the committee desysop, block or remove a member of one of the Arbcom's or OTRS type groups or would they be bound only to lower status individuals?
 * 6) It mentions IRC being included, but will they have the ability to overrule the current IRC operator? Currently, the policy in Freenode is that the operators can do anything they want, to anyone, for any reason. And they do, so my question is whether this committee would bind the IRC ops to WMF rules of conduct or would they follow Freenode/IRC's rules of conduct there, which differ greatly.
 * 7) Would this committee be retroactive? Currently there are several editors and admins on multiple projects with long term patterns of abuse such as blocking to win discussions, outing, contacting employers to try and get editors they don't like fired from employment, frequent use of telling editors to F off, F you or others, etc. So, either this committee is willing to deal with some of these right off from the go to set a tone and do some much needed housecleaning or it wants to start from day 1 and go forward, but either way I think it needs to state that so it is clear.

I see a lot more than this but I don't want to be too long. I hold out hope that this won't turn into another ENWP arbcom that attracts the wrong people for the wrong reasons and ends up doing more damage than it fixes but I think, if this is done right and implemented, it could have a tremendously positive effect on the long term health of the projects. Reguyla (talk) 19:47, 24 February 2016 (UTC)