Code of Conduct drafting process/Wikimedia Developer Summit 2016
Session name: Code of Conduct Meeting goal: The code of conduct (CoC) we are writing will help promote a more welcoming and respectful community. Let's discuss the ongoing work. Phabricator task link: https://phabricator.wikimedia.org/T90908 Meeting style: Education
Topics for discussion
Why have a CoC
What we've done so far
What we want to do in the future
Work on sections that have not been finalized
Discuss how the code can be approved
General notes
Discussion of the CoC was initially very fast-paced and overwhelming. Now it has slowed, and we would like to increase momentum again.
CoC meant to be more specific and enforceable than a general statement of values
What we have done so far: https://www.mediawiki.org/wiki/Code_of_Conduct/Draft
Went through these sections: Intro, Principles, Unacceptable behavior, Report a problem (a single point of contact is available, so people don't need to figure where to report).
Main code of conduct page has been finalized.
Currently working on Cases page (Handling reports, Responses and resolutions, Appealing a resolution).
Next: Committee page (composition, diversity, confidentiality), reviewing the existing draft. It is still in flux, changes are expected.
How the CoC will be approved. Still to be defined.
Discussion oingoing at https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft
We are keeping HR and Legal at WMF in the loop about this, but they are not leading or contributing to a significant degree.
The WMF wants (needs?) to be informed of cases involving a WMF employee or contractor, but otherwise does not need to be involved in the process.
Might require an exception to the promise of confidentiality, which might discourage potential reporters.
Maybe for all employers, not just WMF. WMF may want forwarding regardless of WMF people on committee.
Valerie (expert in CoCs) has reviewed the draft and has a number of notes/suggestions/pieces of advice.
Sections that remain unfinished are mostly about process, not principles.
Language on maintainers' duty to report has been moderated.
Required skills for maintainers seem orthogonal to required skills for policing conduct. Expecting them to do so and having them not do so could weaken confidence in the entire document.
But technical leadership does require some level of skill managing inter-personal issues like this
Could be a self-selected group of maintainers who take reports; otherwise, you go straight to the committee.
Valerie: language about project maintainers should be more clear it's not a binding expectation.
This comes from Contributor Covenant. (But the meaning of maintainer may be different here—anyone with +2 rights on a repo?)
Committee composition
Initial selection by Developer Relations from pool of self-nominations (because nominations by other raises the issue of people getting pushed into high-profile roles they don't want).
If people report to a maintainer of some space, are they required to forward to committee?
According to the draft, no, although they can if they want.
Anyone can choose to report to the committee in place of or in addition to a maintainer.
Kaldari: what if something's reported to both a maintainer and the committee, and the two take different actions?
Katie: who will approve and how hard would it be to change afterwards?
Changes could be up to the committee—they'll be on the front lines of the cases
Moriel: should the committee be allowed to be all volunteers, or should at least one WMF person have to be included?
Having a paid person could help volunteers by taking some of the workload.
Need to clear on time commitments.
Is load going to change over time? Maybe there will be an inital flurry of cases when the CoC goes into effect.
Replacing the committee if they're doing a terrible job? No way for either Developer Relations or the community to do that currently.
Valerie: in other organizations, the community's loss of confidence in the governing body tends ultimately to be resolved by the members of that body voluntarily resigning. Not clear if a formal mechanism would be better.
Mechanism to help sanctioned people come back from sanctions in a positive way?
Nothing explicit right now. There is an expected behaviour page that has been split off from the CoC.
With Bugzilla (and now Phabricator) etiquette, in most cases just showing the offender the link is enough to stop their bad behaviour.
Maybe committee could also have a positive role calling out people who model good behavior?
Might not be a good use of their time.
How will the CoC be approved?
Moriel: public vote would be a bad process. For example, what happens if the vote is no? You shouldn't vote on rights.
Valerie: often, CoCs come from a technical committee or a governing board. Closest analogue would be the Architecture Committee.
Precedent: Friendly Spaces policy? WMF promulgated the process, but it only applied to WMF events. So, not really any precedent for making binding social decision-making in Wikimedia tech spaces.
Would ArchCom be willing to take on this role? Roan is somewhat willing to take this step, but can't speak for the members of the committee.
Roan: trying to get the ArchCom to do this would provoke a serious discussion about its role.
MediaWiki doesn't really have a governance model at all. Some people want to start a MediaWiki foundation.
Secret vote (as opposed to a public vote) is another option. Moriel would not feel any better about this.
Valerie: have never had a code adopted by a public vote. Don't know of any places where it's been tried. Usually, the technical governing authority just enacts it.
Valerie: could also just publish it and tell people they can start using the process. Question is, how much do people want this? Also, how is the technical ability to ban doled out right now?
Committee members should not all have technical ban powers for all spaces to which the code applies. Maybe they could tell Community Advocacy what to do? But CA doesn't want to be a super-admin.
Action items with owners
Roan broaches topic with ArchCom at next meeting.
Valerie to continue to work with Foundation
DON’T FORGET: When the meeting is over, copy any relevant notes (especially areas of agreement or disagreement, useful proposals, and action items) into the Phabricator task.
See https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016/Session_checklist for more details.