Mentioned in SAL (#wikimedia-cloud) [2017-06-14T10:04:05Z] <Sebastian-WMSE> Deploy latest from Git master: e641fcb (T165540), dfee00f (T148623)

I think MZMcBride is the only person who has a problem with the CODE_OF_CONDUCT.md in mediawiki/core. Can we go back to the CODE_OF_CONDUCT.md files that were added to a hundred of repos without any form of approval by or notification to their maintainers? I would like to hear two things:

• A promise that you will not do such a silly thing for any remaining repos. Please, submit the changes through Gerrit, which will send an email to folks watching the repository and provide a well-visible record of who made the action. This is valuable even if you're going to self-merge the change afterwards.
• Clarification on whether it is required for all repositories hosted on Gerrit to have a CODE_OF_CONDUCT.md in their root directory.

In T165540#3350021, @matmarex wrote:

• Clarification on whether it is required for all repositories hosted on Gerrit to have a CODE_OF_CONDUCT.md in their root directory.

Based on the discussion in this task, the consensus seems like that it's not required, just recommended.

In T165540#3336712, @faidon wrote:

On the matter at hand, while I'm generally a proponent of the CoC, I find the addition of the blurb on every single Wikimedia repository a bit spammy as well, for reasons similar to those @ashley mentioned. GitHub is standardizing on adding it to the repositories because GitHub usually serves as a home page and issue tracker for many projects as well, or at least attempts to do so. In those cases, GitHub the primary medium over which people in a project communicate and collaborate, and for that reason, it makes sense. In our case, we usually don't use our Git repositories as our primary communication channels (I say primary, because I suppose it's conceivable someone may make an offensive or derogatory comment in a commit message). I think adding the CoC on prominent places on our technical wikis, as well as Phabricator, is enough to raise plenty of awareness to it. I cannot easily imagine situations where someone will be engaged with a project of ours but wouldn't first visit at least one of those two places.

We actually have quite a few projects which are Github-based (e.g. ORES stuff, much of the RESTBase ecosystem, the iOS app, some of the librarization projects), but I see your point. I am somewhat skeptical of "prominent places" - people tend to have banner/footer blindness and are much more likely to look at an info file with an attention-catching name IMO. (Wikipedia used to show huge policy blobs like this right under the edit box, to no particular effect.) Also, people browse repos well before deciding to contribute to that project and looking into what kind of bug tracking, code review etc. mechanisms it is using, and seeing a code of conduct might play part in that decision. Deterring negative interactions is not the only function of a code of conduct - it also serves as a signal that this community is probably a decent place (seriously broken ones would probably not accept a CoC in the first place).

In T165540#3336723, @Smalyshev wrote:

I wonder if adding the file to each repo is the best way. It looks like a rather ineffective solution. Maybe could be a link in the standard header we have in mirrored repos instead? It's rather easy to forget to create it when creating various new repos, and also some repos should have it and some (like deployment repos, etc.) maybe should not, so managing it could become a bit messy.

The Github header is very short (basically a single sentence) and IMO should be used to explain what the repo is about and link to useful places like the relevant gerrit (see T153614) or Phabricator project. Adding the CoC to the readme files would make more sense and probably less disruptive than adding a separate file but I doubt it could be automated.

In T165540#3336855, @Huji wrote:

If we are to keep these files, can we at least rename them to COC (with no extension) and make them plain text? That's how COPYING, README and other similar files are named and formatted anyway.

Much to their detriment (and hopefully not forever). We have a problem with attracting new developers, and making things more old-school is probably not the answer for that.

In T165540#3336735, @MaxSem wrote:

I would like to clarify our relationship with GitHub: do we have any plans of it being anything but readonly mirror with a great repo browser for us?

No.

If we discourage people from contributing on GH, why do we add contribution metadata specifically for GH, as if we encourage pull requests there?

Why would adding Github-specific metadata encourage people to make pull requests there? There is no relation whatsoever. (We might actually want to encourage pull requests once we a sane pipeline for handling them, per T37497. Why not? But that's completely unrelated.)
Also, it's not really Github-specific, as the largest hoster of opensource projects Github is just setting a convention here.

In T165540#3344745, @Yaron_Koren wrote:

If someone email an extension developer a patch to their extension, and the main developer likes the patch, then modifies the source code appropriately, and checks in the change, that means that the entire real development of the patch was done outside the domain of the Wikimedia Foundation. It could have been done by anyone in the world, on any platform, and under any sort of social conditions, and the Code of Conduct (which applies only to "Wikimedia technical spaces") doesn't cover it.

As a thought experiment, imagane a contributor who is very misogynist but also very respectful of social contracts. This person uses gerrit.wikimedia.org to host their code but runs their own issue tracker. Female dveelopers get mocked and insulted when they file bugs, but their code submissions are treated politely because the gerrit ToU demands that. It seems ridiculous to me to suggest that the Wikimedia technical community should accept such a situation and not do anything against it, on the grounds that only part of the development happens outside our technical spaces.

This discussion has become hard to follow, so I'll try to summarize:

• there was lots of debate over whether adding CODE_OF_CONDUCT.md to (almost) every repo is a good or bad idea. Quick tally: 16 were for it (I'm also counting people who awarded tokens), 10 against. (There were maybe half a dozen comments which could be read as implicitly implying one or the other; I tried to err on the side of not overinterpreting and did not count those.) So there was consensus to add the files, although not an overwhelming one. Several people pointed out though that adding the file would be weird or harmful for certain deployment-related repos (such as Debian packaging repos). So we should keep the files which have been added, and probably add CoC files to the other repos as well, as long as we can avoid build/deployment type repos.
• several people objected against pushing directly to the repo (and thus not leaving an audit trail in gerrit). Several other people objected against using gerrit changesets which would cause a torrent of notification mails, and DoS Jenkins with pointless build jobs. Nobody objected to Chad's proposal in T165540#3316733 to use auto-merge so I am assuming that's the consensus approach.
• some argued against using markdown, or a long filename, but neither opinion was popular.

In T165540#3359804, @Tgr wrote:

This discussion has become hard to follow, so I'll try to summarize:

• there was lots of debate over whether adding CODE_OF_CONDUCT.md to (almost) every repo is a good or bad idea. Quick tally: 16 were for it (I'm also counting people who awarded tokens), 10 against. (There were maybe half a dozen comments which could be read as implicitly implying one or the other; I tried to err on the side of not overinterpreting and did not count those.) So there was consensus to add the files, although not an overwhelming one. Several people pointed out though that adding the file would be weird or harmful for certain deployment-related repos (such as Debian packaging repos). So we should keep the files which have been added, and probably add CoC files to the other repos as well, as long as we can avoid build/deployment type repos.
• several people objected against pushing directly to the repo (and thus not leaving an audit trail in gerrit). Several other people objected against using gerrit changesets which would cause a torrent of notification mails, and DoS Jenkins with pointless build jobs. Nobody objected to Chad's proposal in T165540#3316733 to use auto-merge so I am assuming that's the consensus approach.
• some argued against using markdown, or a long filename, but neither opinion was popular.

My objection was solely that certain groups who maintain repos in gerrit but are largerly independent of MediaWiki core maintainers were not consulted, and did not have the opportunity to voice any objection they may or may not have had, prior to the action being taken. I don't care about the actual file one way or another, but making changes to repos maintained by independent groups without consultation leads to some groups feeling like second class citizens - which I consider to be a rather negative situation potentially leading to later resentments.

@Bawolff do you think that has been resolved now that a notification was sent to wikitech-l or should there be more / elsewhere?

In T165540#3360407, @Tgr wrote:

@Bawolff do you think that has been resolved now that a notification was sent to wikitech-l or should there be more / elsewhere?

At this point its basically spilled milk. I don't think there is anything more to be done, I just wanted to add it to the summary as I think its of a different nature than the other objections mentioned on the summary.

@Tgr:

As a thought experiment, imagane a contributor who is very misogynist but also very respectful of social contracts. This person uses gerrit.wikimedia.org to host their code but runs their own issue tracker. Female dveelopers get mocked and insulted when they file bugs, but their code submissions are treated politely because the gerrit ToU demands that. It seems ridiculous to me to suggest that the Wikimedia technical community should accept such a situation and not do anything against it, on the grounds that only part of the development happens outside our technical spaces.

That's an interesting thought experiment, and it seems obvious to me that, however the Wikimedia technical community feels about it, they would be obliged to accept the situation, because no rules would have been broken. Otherwise, what's the point of this whole "code of conduct", if the real rule is that whatever makes people feel sad is now forbidden?

So there was consensus to add the files, although not an overwhelming one.

I don't think this conclusion is warranted (note I am not saying it's false, just that the data we have does not support making it). Some people may have agreed with one of the positions, but avoided adding "me too" comments, or didn't feel like discussing it in this venue, or just didn't know about it. You can not equate number of people participating in active discussion as a vote. Not that I claim there *should* be a vote of any kind, but if we are going to make vote-like conclusion, it should be done in vote-like fashion - with announcement as a vote, etc. Or, alternatively, avoid taking numerical tallies and making conclusion based on it.

As a thought experiment, imagine a contributor

I don't think having or not having CoC constitutes an obligation to tolerate a person who is destructive. It's not like pre-CoC we had this obligation, and having CoC does not change it. CoC is a tool, and if situation arises where this tool is not enough to achieve the goals, other tools can be used. Of course, "destructive" is to some measure subjective, so we would have always to have some trust in each other and our ability to do the right thing. What the right thing is in each particular case, I think, should be discussed on the merits of the case.

Change 437555 had a related patch set uploaded (by Hashar; owner: Hashar):
[mediawiki/extensions/SiteSettings@master] Bring back CODE_OF_CONDUCT.md

https://gerrit.wikimedia.org/r/437555

Change 437555 merged by Chad:
[mediawiki/extensions/SiteSettings@master] Bring back CODE_OF_CONDUCT.md

https://gerrit.wikimedia.org/r/437555

Discussion is continuing at https://lists.wikimedia.org/pipermail/wikitech-l/2018-June/090086.html

In T165540#3337553, @Strainu wrote:

I am personally against using the markdown (and implicitly the .md extension). The code is not maintained in Github, gerrit does not implicitly display markdown and having some weird syntax (however well-known) decreases the readability of the file in command line. I would much rather have it in plain text.

I'll stress this point because it seems to have been overlooked by some who claim the file is conclusively harmless for the code. The court is still out on that.

We generally use plain text files (the classic COPYING, README etc.) and the inconsistency is unnerving, especially for a community as interested in precision as ours. It's not clear what dictated such a departure from our practices.

In T165540#4268283, @Nemo_bis wrote:

We generally use plain text files (the classic COPYING, README etc.) and the inconsistency is unnerving, especially for a community as interested in precision as ours. It's not clear what dictated such a departure from our practices.

MediaWiki code search gives 163 hits for README, 156 hits for README.md and 17 hits for README.mediawiki. There is no easy way to mass-check repo creation times but I'd wager there is a trend (driven by people expecting pretty rich text readmes these days).

The GitHub API apparently works just as well without the extension:

$ curl -sH 'Accept: application/vnd.github.scarlet-witch-preview+json' https://api.github.com/repos/tstarling/coc_test | jq .code_of_conduct
{
  "key": "other",
  "name": "Other",
  "url": "https://github.com/tstarling/coc_test/blob/master/CODE_OF_CONDUCT"
}

So the only reason to add the .md extension is to make the link clickable in the GitHub blob view. But note that they don't actually link to it at present when creating a pull request, as far as I can see. It seems like a very minor point. Leaving off the extension would seem to be more consistent for us.

Change 494149 had a related patch set uploaded (by BryanDavis; owner: Bryan Davis):
[wikimedia/github-community-health-defaults@master] Add CODE_OF_CONDUCT

https://gerrit.wikimedia.org/r/494149

Change 494149 merged by BryanDavis:
[wikimedia/github-community-health-defaults@master] Add CODE_OF_CONDUCT

https://gerrit.wikimedia.org/r/494149

Change 677903 had a related patch set uploaded (by Mainframe98; author: Mainframe98):

[mediawiki/extensions/Gravatar@master] Add CODE_OF_CONDUCT.md

https://gerrit.wikimedia.org/r/677903

Change 677904 had a related patch set uploaded (by Mainframe98; author: Mainframe98):

[mediawiki/extensions/DumpsOnDemand@master] Add CODE_OF_CONDUCT.md

https://gerrit.wikimedia.org/r/677904

Change 677904 merged by jenkins-bot:

[mediawiki/extensions/DumpsOnDemand@master] Add CODE_OF_CONDUCT.md

https://gerrit.wikimedia.org/r/677904

Change 677903 merged by jenkins-bot:

[mediawiki/extensions/Gravatar@master] Add CODE_OF_CONDUCT.md

https://gerrit.wikimedia.org/r/677903

Change 733068 had a related patch set uploaded (by Zoranzoki21; author: Zoranzoki21):

[mediawiki/extensions/StickyTOC@main] Add CODE_OF_CONDUCT.md

https://gerrit.wikimedia.org/r/733068

Change 733068 merged by Hashar:

[mediawiki/extensions/StickyTOC@main] Add CODE_OF_CONDUCT.md

https://gerrit.wikimedia.org/r/733068

For the records, there was another deletion in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/SmiteSpam/+/937466/