Talk:Code of Conduct/Archive 4

Wider participation
A user has mentioned above that they would like to see wider participation in this thread from the technical community, and I think that's definitely something we'll want when it comes to full approval rather than just drafting. So, who has ideas for what we could to do involve people who are part of the technical community, or interested in becoming part of it? Off the top of my head we could do a sitenotice or similar notice on Wikitech (the wiki rather than the mailing list). Ironholds (talk) 19:30, 18 September 2015 (UTC)
 * Since there are whole teams at WMF charged with Communications, Community Engagement, Community Advocacy and Community Tech, I suggest that you may be better placed than I for suggestions. However, I note that there is a list of physical and virtual spaces in the opening paragraph of the code.  For maximal support, th community in each of those spaces should be specifically engaged.  As far as physical spaces are concerned, consider an invitation to past event organisers to share, as far as they are able, their experiences and lessons learned from their events, for example from their feedback and their own internal review discussions.  For events in the near future, consider asking the organisers to schedule a panel, round-table, debate or similar in-person session, and a section in he feedback addressing the question of whether the code in force at the event was adequate and whether this code would have been an improvement.  All this takes time and effort of course, which is why the WMF community engagement teams, broadly considered, should already have been involved from the start. Rogol Domedonfors (talk) 19:46, 18 September 2015 (UTC)
 * We have etherpad (no technical community), mediawiki.org, wikitech, phabricator (the work started there), gerrit, the IRC channels, and the mailing lists (where there has been an extensive thread). So that leaves mediawiki.org, wikitech, gerrit and the IRC channels. We could do something like a sitenotice on wikitech and mediawiki, a /NOTICE on the prominent IRC channels, and for gerrit..I'm not sure short of emailing recent committers, which might lead to flashback (mass-mailing often does).
 * I'm not sure if there are any upcoming events centred around or including a tech component; there's WikiConference USA, of course, but there's no real tech element to it. As I already mentioned, the WMF community engagement teams, broadly considered, have been engaged from the start - we have a community engagement team just for the Engineering community, and Quim leads it. Ironholds (talk) 19:57, 18 September 2015 (UTC)
 * If there is no technical community associated with Etherpad then perhaps it should not be mentioned at all? As far as events are concerned, I believe there's a Wikimedia Developer Summit 2016 planned, for example.  Whether the members of Community Engagement are engaged here in the discussion is beside the point -- it is whether they are engaged out in other places spreading the message effectively. Rogol Domedonfors (talk) 21:10, 18 September 2015 (UTC)
 * And as the ticks on the list above indicate, they are - but there's only one Quim ;). Etherpad has users and so should be subject to this but doesn't have a community in the sense of identifiable "etherpad people"; it's a largely anonymous note-taking thing. the Developer Summit is an excellent point. Ironholds (talk) 21:19, 18 September 2015 (UTC)
 * There is not a community in each space. There is one technical community where many (probably most) people participate in more than one space.  No one considers themselves solely an Etherpad user.  They use Etherpad to participate in our community's work.  That said, I think it's fine to use site notices where possible to make more people aware.  The WMFs community engagement teams have been aware of this work (and involved where appropriate) from the start. Mattflaschen-WMF (talk) 00:34, 25 September 2015 (UTC)

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)

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)

Legal standing of the Committee
What is the intended standing of the Committee? I presume that it is to be an entirely informal group whose only standing and authority derives from the community? As opposed, say, to a committee of the WMF Board? I preferred the latter solution but consensus seems to be the former. Assuming so it should be made clear. Does the WMF back the Committee in any way, for example, by way of indemnity or advice if there are legal repercussions to its decisions? Or is it intended that Committee members stand completely exposed personally in the event of legal action? Rogol Domedonfors (talk) 18:11, 22 September 2015 (UTC)
 * That's an active and open question, and will require consultation with WMF legal. IANAL and neither are most (all?) of us here. I am not sure whether it can be plausibly argued that its "only standing and authority derives from the community" given the connections to Developer Relations and the fact that the committee's decisions can have a significant impact on the ability of WMF employees to do their jobs, but a lawyer would have a better sense of whether that is possible. --Fhocutt (WMF) (talk) 22:54, 22 September 2015 (UTC)
 * My question is, what do we want it to be? Do we want it to be free-standing, so that its standing and authority derives only from the community?  Do we want it to be indemnified by WMF?  Do we want WMF to be able to give it instructions or not?  I agree that Legal will need to advise on how to achieve what we want, but what is it that we want? Rogol Domedonfors (talk) 06:25, 23 September 2015 (UTC)
 * Honestly, what I primarily want is for us to focus on getting the code up and running, and then work on the committee. If we're working on the committee already, I don't see a problem with it operating by community standards albeit with WMF backing, in the same way the Arbitration Committee works. Ironholds (talk) 15:48, 23 September 2015 (UTC)
 * In the current wording, per wmf:Resolution:Wikimedia Committees, this would look like a WMF staff committee. This doesn't mean much (certainly it doesn't have legal personality; no Wikimedia committee has) but it does have disadvantages. Nemo 07:32, 24 September 2015 (UTC)
 * My vision of the Code of Conduct committee fits with the definition of "an entirely informal group whose only standing and authority derives from the community". I see this committee as a community-wide committee which doesn't require any WMF member. When that committee decides that an issue goes over themselves, they can transfer the responsibility to handle that situation to the Wikimedia Foundation, who would have the Developer Relations team as point of contact. Note that in our draft the WMF/DevRel have no authority over the Committee.--Qgil-WMF (talk) 09:30, 24 September 2015 (UTC)
 * This is not a Staff Committee because the CoC (and thus the Committee which is part of the same package) will be created by community consensus, not by staff acting alone. Furthermore, it will not be led by WMF staff, nor is there any requirement that WMF staff ever be on the committee (though it is allowed). Mattflaschen-WMF (talk) 05:31, 28 September 2015 (UTC)
 * It could be temporarily led by a WMF staff member if the committee elects them as chair. But that's not what the document means. Mattflaschen-WMF (talk) 07:17, 28 September 2015 (UTC)
 * In addition to what I said below, WMF staff will not be giving it instructions. The authority derives from the Terms of Use and Code of Conduct (CoC), and the CoC itself provides the policy which must instruct the Committee's actions. Mattflaschen-WMF (talk) 04:39, 28 September 2015 (UTC)
 * The whole code is being created by fiat by a group of WMF employees and gives ultimate authority to a WMF employees team, hence I maintain the thing is led by WMF employees and definitely looks like a WMF staff committee. --Nemo 06:50, 6 October 2015 (UTC)
 * In my opinion, the Committee's authority will derive from the Code of Conduct itself (as a policy of the technical community) and also the ToU, which says, "The Wikimedia community and its members may also take action when so allowed by the community or Foundation policies applicable to the specific Project edition, including but not limited to warning, investigating, blocking, or banning users who violate those policies." Mattflaschen-WMF (talk) 00:10, 26 September 2015 (UTC)

Finishing the "Report a problem" section
We're now finishing up the report a problem section. This is the ideal time to discuss or make edits to the draft for this section. You can also create subsections for discussion here. Mattflaschen-WMF (talk) 03:51, 22 October 2015 (UTC)


 * Looks pretty good to me. I've made a couple of wording tweaks to make the words less loaded. While the committee will eventually be handling cases of abuse, some number of the reports will be of good-faith interactions that ended up harming someone, and the less fraught we can make the reporting process, the better.


 * There may be legal/practical issues with how much confidentiality can be promised, but I would like to keep it as close to this as possible. Particularly, I would like to avoid automatically getting HR involved, although there are some complex liability issues under California/US law regarding the WMF's duty to protect its employees and volunteers from harassment. --Fhocutt (WMF) (talk) 22:11, 22 October 2015 (UTC)


 * I polished some details. This section looks good to me as well.--Qgil-WMF (talk) 23:11, 28 October 2015 (UTC)

Ambiguous title
Please move the title back. There was no clear consensus on the proposal to move the page and the new title is in conflict with Code of conduct policy. Nemo 07:19, 28 October 2015 (UTC)
 * I recall quite a bit of agreement around the move, actually. The new title has a redirect from Code of conduct, so the 'conflict' isn't actually a problem. Ironholds (talk) 14:21, 28 October 2015 (UTC)
 * Nemo, there was clear consensus, although it was not formally closed (there are no particular conventions or policies for handling this on mediawikiwiki). I do understand that you don't want this policy to be here at all. If a substantial number of people find that the title is confused with the policy on foundationwiki, we could title this something like "Technical code of conduct". --Fhocutt (WMF) (talk) 20:52, 28 October 2015 (UTC)
 * I don't think this detail is very relevant at this point, but in the draft itself the page is called Code of conduct for technical spaces. I don't see any problem with this name that stresses the important fact that the CoC applies across multiple sites, not only mediawiki.org (althought the first sentence is clear enough in any case). This full name might feel redundant in the context of its own page in mediawiki.org, but we need to think in the name we want this CoC to be known across the Wikimedia movement. In this sense, when Luis Villa mentioned "Code of Conduct for technical spaces" in the monthly Metrics Meeting, the scope was clear.--Qgil-WMF (talk) 23:19, 28 October 2015 (UTC)
 * Personally, I think "Code of conduct for technical spaces" is more clear and less confusing (since we have other codes of conduct), but a redirect from Code of Conduct would probably be appropriate on mediawiki.org. Kaldari (talk) 22:18, 29 October 2015 (UTC)
 * +1 to "Code of conduct for technical spaces". +1 to this not being a very relevant issue as well. --Tgr (WMF) (talk) 05:46, 30 October 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)

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)