Page MenuHomePhabricator

Add CODE_OF_CONDUCT.md to Wikimedia repositories
Open, Needs TriagePublic

Tokens
"Party Time" token, awarded by D3r1ck01."Love" token, awarded by CKoerner_WMF."Hungry Hippo" token, awarded by zeljkofilipin."Love" token, awarded by Multichill."Love" token, awarded by Halfak."Love" token, awarded by MelodyKramer."Love" token, awarded by JMinor."Love" token, awarded by Qgil."Doubloon" token, awarded by Mattflaschen-WMF."Love" token, awarded by Lucie."Yellow Medal" token, awarded by Florian."Love" token, awarded by Ladsgroup."Yellow Medal" token, awarded by 01tonythomas."Love" token, awarded by greg."Like" token, awarded by Amire80.
Assigned To
None
Authored By
Tgr, May 16 2017

Description

Now that we have a Code of Conduct we need to advertise it. Github is standardizing CODE_OF_CONDUCT.md in the root of the repo as the place to put the CoC text; following this seems useful both because it is a reasonable convention where no other exists and because all our code is mirrored to Github.

Per discussion in this task and elsewhere, MediaWiki extensions and skins seem like the reasonable target for automated adding of the file; there are repos which are only used internally or where the file could cause problems, and while there are plenty of repos which should probably have the file (e.g. PHP libraries), except for extensions/skins there doesn't seem to be an easy way to list them.

See also:

Related Objects

Mentioned In
rESRDf6bbc681515c: Add CODE_OF_CONDUCT.md
T202047: CODE_OF_CONDUCT.md should link to the mediawiki.org page in user's preferred language
T136863: Should Wikimedia have standard policies for managing github mirror repos?
T148623: Highlight recited word
T165860: Request for +2 rights on mediawiki/* for Ladsgroup
rESHMd30bfa7d9c4a: Add CODE_OF_CONDUCT.md
rESHH4e8869aebb58: Add CODE_OF_CONDUCT.md
rEZI0eb871f32352: Add CODE_OF_CONDUCT.md
rEULL76837deef72d: Add CODE_OF_CONDUCT.md
R1898:2dbed593f830: Add CODE_OF_CONDUCT.md
rERECef6018d21d27: Add CODE_OF_CONDUCT.md
rETLIbadf983b83e2: Add CODE_OF_CONDUCT.md
rEWPEd100f232ad1e: Add CODE_OF_CONDUCT.md
rEPTQ2530492895d2: Add CODE_OF_CONDUCT.md
rEBST9caebaf74a54: Add CODE_OF_CONDUCT.md
rECOCGEPUB83e6c3a8b8ce: Add CODE_OF_CONDUCT.md
rEMEM5d2bb83b93b9: Add CODE_OF_CONDUCT.md
rEPPcea74413cc62: Add CODE_OF_CONDUCT.md
rEBSCe85b19e93010: Add CODE_OF_CONDUCT.md
rEOLYc5ab5c183d6c: Add CODE_OF_CONDUCT.md
rESSO42b5ba67a229: Add CODE_OF_CONDUCT.md
rEEDIbd7c4db7c91d: Add CODE_OF_CONDUCT.md
rERXBb3c7c3d2586c: Add CODE_OF_CONDUCT.md
rEWOPdc34bb2e02a9: Add CODE_OF_CONDUCT.md
rEUSNbe3601d67e1a: Add CODE_OF_CONDUCT.md
rEREL4d663c37becb: Add CODE_OF_CONDUCT.md
rETHR6579fd3891cc: Add CODE_OF_CONDUCT.md
rEENFb19c246b327f: Add CODE_OF_CONDUCT.md
rEUCA72edf24b3a6f: Add CODE_OF_CONDUCT.md
rESSba7929b135a7: Add CODE_OF_CONDUCT.md
rEMWV494cf206c48b: Add CODE_OF_CONDUCT.md
rEMOOCc158f70cde56: Add CODE_OF_CONDUCT.md
rESRX836ab9ff9f2e: Add CODE_OF_CONDUCT.md
R1899:4f2ec064cac9: Add CODE_OF_CONDUCT.md
rEWISe641fcbe9c96: Add CODE_OF_CONDUCT.md
rEWBI8f5406307a03: Add CODE_OF_CONDUCT.md
rEQGVb8a015d4c2cb: Add CODE_OF_CONDUCT.md
R1902:9ab00f97c5bb: Add CODE_OF_CONDUCT.md
rENUAC1cf73ac6ead4: Add CODE_OF_CONDUCT.md
rEUPE803e06c1c845: Add CODE_OF_CONDUCT.md
rEXFA50e363a1760c: Add CODE_OF_CONDUCT.md
rEWPL955d4f6b9140: Add CODE_OF_CONDUCT.md
rEWLE0ad63e704001: Add CODE_OF_CONDUCT.md
rEURD0c39f4915449: Add CODE_OF_CONDUCT.md
rEPPU46c698aaea09: Add CODE_OF_CONDUCT.md
rESTLH1e049c3c8a75: Add CODE_OF_CONDUCT.md
rEIDS4547c5e53979: Add CODE_OF_CONDUCT.md
rEULKdf84b47e9733: Add CODE_OF_CONDUCT.md
rENPU693d634ee73a: Add CODE_OF_CONDUCT.md
rESCCeca973ca48d6: Add CODE_OF_CONDUCT.md
rEIMRcf742bf0ee8f: Add CODE_OF_CONDUCT.md
rEPCE0f4696834170: Add CODE_OF_CONDUCT.md
rEQSf63e8a5e81a8: Add CODE_OF_CONDUCT.md
rECPU751f32cd7dc2: Add CODE_OF_CONDUCT.md
rERSLef55b36ab08d: Add CODE_OF_CONDUCT.md
rEPI931963a4b919: Add CODE_OF_CONDUCT.md
rECWee6298424832: Add CODE_OF_CONDUCT.md
rEPKL7817a38a2364: Add CODE_OF_CONDUCT.md
rEPFM4a753dc1930f: Add CODE_OF_CONDUCT.md
rEPNF10b485547300: Add CODE_OF_CONDUCT.md
rEOTPd373b90b932b: Add CODE_OF_CONDUCT.md
rMSMA20f7c942fa1a: Add CODE_OF_CONDUCT.md
rEBSH5771a5cf24e6: Add CODE_OF_CONDUCT.md
rECWAd7b423ff4437: Add CODE_OF_CONDUCT.md
rEMCO3c9cf867d68c: Add CODE_OF_CONDUCT.md
rEDBT8b08a7f1f401: Add CODE_OF_CONDUCT.md
rEAUG43e29c87f114: Add CODE_OF_CONDUCT.md
rEMWFb88d65e1a7fc: Add CODE_OF_CONDUCT.md
rSVEVda06ea80fe6b: Add CODE_OF_CONDUCT.md
rEGCN2fc470b9b989: Add CODE_OF_CONDUCT.md
rEHJSaca2b38597c3: Add CODE_OF_CONDUCT.md
rELDGcb52586b59f6: Add CODE_OF_CONDUCT.md
rEMNHa1230da2df81: Add CODE_OF_CONDUCT.md
rSEXAMPLEa0c353576637: Add CODE_OF_CONDUCT.md
rELGN84c80d5f0931: Add CODE_OF_CONDUCT.md
rEDPT1a8db5aacc46: Add CODE_OF_CONDUCT.md
rELINT3e6341f5b732: Add CODE_OF_CONDUCT.md
rEIWS11e7586e3619: Add CODE_OF_CONDUCT.md
rEEMA57f65f861815: Add CODE_OF_CONDUCT.md
R1894:9de54f1f22cd: Add CODE_OF_CONDUCT.md
rEBHK2bb625eb921a: Add CODE_OF_CONDUCT.md
rEBSV4e9fcfde7b0b: Add CODE_OF_CONDUCT.md
R1893:dd605c92e695: Add CODE_OF_CONDUCT.md
rMSPO0a74cb892fab: Add CODE_OF_CONDUCT.md
rEGNEe1fb9f40180d: Add CODE_OF_CONDUCT.md
rSATH56b21f7b5b42: Add CODE_OF_CONDUCT.md
rECOG59139519e465: Add CODE_OF_CONDUCT.md
rEEPS88ba578b9124: Add CODE_OF_CONDUCT.md
rEDTL7212dff8a466: Add CODE_OF_CONDUCT.md
rEBOPab3f4fef61c7: Add CODE_OF_CONDUCT.md
rEBSMU49ed4a96fef7: Add CODE_OF_CONDUCT.md
rEBSSMWC4b634c933848: Add CODE_OF_CONDUCT.md
rEBSEF90795f972be9: Add CODE_OF_CONDUCT.md
rEBSENC1ad0c6e49394: Add CODE_OF_CONDUCT.md
rEATHbd097dac4fa7: Add CODE_OF_CONDUCT.md
rECOS92e49530670d: Add CODE_OF_CONDUCT.md
rECKTf41729946ba0: Add CODE_OF_CONDUCT.md
rEBSM5c33a5aeb74a: Add CODE_OF_CONDUCT.md
rEBSI5fb6139ad22b: Add CODE_OF_CONDUCT.md
rEARA09c88dfc16fd: Add CODE_OF_CONDUCT.md
rEASRf3b09dd9cc06: Add CODE_OF_CONDUCT.md
rETHRf9ad0ded7f0b: Add CODE_OF_CONDUCT.md
rLTZB2a7b0cf58065: Add Code of Conduct.md per policy
rLTZB8fec83e20d30: Add Code of Conduct.md per policy
rQRRYbaf7f6346367: Add Code of Conduct.md per policy
Mentioned Here
T202047: CODE_OF_CONDUCT.md should link to the mediawiki.org page in user's preferred language
T37497: Implement a way to bring GitHub pull requests into gerrit
T153614: GitHub repository descriptions should point directly to the Gerrit projects
rEWISe641fcbe9c96: Add CODE_OF_CONDUCT.md
rEWISdfee00f1c531: Highlight recited word
T148623: Highlight recited word
P5546 Add a file to every repo
T90908: Goal: Binding code of conduct for all Wikimedia technical spaces with consequences for breaches
T136863: Should Wikimedia have standard policies for managing github mirror repos?

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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.

Also, can you clarify if agreeing to host a CODE_OF_CONDUCT.md at the root of one's repository is a condition for one's project to remain hosted on Gerrit?

For some deployment repos that would be somewhat unfortunate requirement. While most of them would probably tolerate this file sitting around, it would be a nuisance and IMHO rather unnecessary one.

Isarra added a subscriber: Isarra.Jun 10 2017, 12:14 AM

I disagree with this task as well. Even if you support the CoC in general, it really doesn't make sense to put it in every single repository when the CoC is for the people and the interactive spaces in which they work, not the technical output thereof. We don't even have separate files for the license in every single repository, and that actually is for the code itself.

Essentially: how the code is developed within Wikimedia is determined by policies present on gerrit, phabricator, etc. It does not pertain to the code itself where it is distributed to or picked up by third parties (unless you want to add this to the license or something, but that probably wouldn't be enforceable either). Thus the relevant policies (the CoC) should be made known and available on gerrit, phabricator, etc, not included in the code.

MaxSem added a subscriber: MaxSem.Jun 10 2017, 12:19 AM

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? If we discourage people from contributing on GH, why do we add contribution metadata specifically for GH, as if we encourage pull requests there?

…snip…
I tried to use gerrit but then I realized it's 900 extension repos and that can't be done using gerrit so I asked for a temporary push access and pushed to all.

Did you discuss this anyone? I'm sure @demon would have considered this when he gave his previous advise or could have provided input on ways around this. I haven't counted the number of repos that l10n bot commits to, but I would assume its a similar range…

Did you discuss this anyone? I'm sure @demon would have considered this when he gave his previous advise or could have provided input on ways around this. I haven't counted the number of repos that l10n bot commits to, but I would assume its a similar range…

I know you mean well, but I'd just like to point out to everyone contributing in this task that what's done is done, whether you thought it was a good or a bad move. Let's be a little more forward-looking and focus on building consensus regarding the change itself, i.e. whether we want a CODE_OF_CONDUCT.md added to every repository of ours after all.

If the answer turns out to be "yes", we can then discuss how it can be optimally applied, and find the sweet spot between not needlessly spamming people and not going around them. The execution seems fairly separated from the decision itself in this case, so this is an orthogonal concern, the specifics of which we can discuss later IMHO.

Huji added a comment.Jun 10 2017, 1:27 AM

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.

And if there is an absolute preference to keep them as markdown, can we at least rename them to COC.md instead?

If we are to keep these files, can we at least rename them to COC (with no extension)

I wouldn't recommend that, Try announcing that filename…

You were heavily involved in discussions surrounding this code of conduct; how is it appropriate for you, working with Matt F., to merge this changeset when there's such a clear conflict of interest?

Are you suggesting that people that are heavily involved in discussions can't merge changesets related to these discussions? :) That's absurd.

I'm suggesting that people with conflicts of interest should not act in cases where that conflict is raised. This is very standard and expected practice in many different places.

Pointing fingers because of a technicality defeats the purpose of this CoC IMHO.

It's kind of amazing to me that a small group of people has set out to judge and try to dictate others' behavior with a "code of conduct," but when called out for violating basic community standards—both ethical and technical—a few of their colleagues come around to say "but shouldn't you be focusing on the bigger picture" and "well, they've already committed this rash act, so let's just move forward."

Count me as one of the people who think adding this text file to every Git repository is a bad idea. In my opinion, this was a poorly advertised and ill-advised series of changes that was implemented by people with an apparent conflict of interest on the matter. I wanted to make clear on this task that this change was both noticed and unwelcome. And with that, the civility police can continue their march toward... whatever.

TheDJ added a subscriber: TheDJ.Jun 10 2017, 1:39 PM
  1. I have no objection to having the code of conduct in the repositories
  2. If anything i would encourage it
  3. I do not think that a code of conduct file in a repo is a requirement for enforcement of said code of conduct
  4. As much as i'm a old-hand Mac fan, i think files without file extensions are annoying
  5. I don't think we need to do things because github does them, but if we can piggyback on an emerging convention that requires us to add 3 characters that should already have been there, to a filename, than that seems totally logical.
  1. I have no objection to having the code of conduct in the repositories
  2. If anything i would encourage it
  3. I do not think that a code of conduct file in a repo is a requirement for enforcement of said code of conduct
  4. As much as i'm a old-hand Mac fan, i think files without file extensions are annoying
  5. I don't think we need to do things because github does them, but if we can piggyback on an emerging convention that requires us to add 3 characters that should already have been there, to a filename, than that seems totally logical.

Agreeing to everything here. I would better spend my time on improving the codebase in my capacity than being worried about someone adding a file that makes it safer for contributors to help me with the same. I also acknowledge that everyone has the right to worry - and I do respect that. Thinking about the greater good - I am happy to let these files be in my repos - as I was a beginner myself few years before and I really wished there was an entity to report poor conduct to.

Regarding adding files to every repos - I think it makes sense as a beginner always end up in the Github repo to look at the code for some reason (I had been doing it from day 1 - to use Github search inside files, etc). Since newcomers are the ones who are mostly at the receiving end of bad conduct from experienced programmers (world works like that), adding it there does the job.

More importantly, terms of use is not something that people realistically read, or are expected to read

This made me boil. The terms of use contain things such as the fact we produce free knowledge (free licenses are required etc.). That's the whole point of this Wikimedia thing.

At the time I did protest about the text growing without control (also for the privacy policy). One good way to reduce the TL;DR effect is to abolish redundant policies, avoid new ones and significantly cut the important ones we can't do without. We're still on time to have some improvement in this regard. :-)

In T165540#3337149, @TheDJ wrote:

[…]to add 3 characters that should already have been there, to a filename, than that seems totally logical

Couldn't agree more with all points given!

Zppix added a comment.Jun 10 2017, 9:36 PM

If we are to keep these files, can we at least rename them to COC (with no extension)

I wouldn't recommend that, Try announcing that filename…

So we cant name files "COC" because some people are immature? "HEHE it sounds like c****" so what? We're adults, either be mature or giggle about it, its not the developers/maintainers fault, we shouldn't be responsible for the end user's maturity level.

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. With extension or not, that's bikeshedding.

I also find the wording a bit confusing, as it implies that the code should be written according to the CoC, which is not true. However, I currently don't have a better phrasing in mind.

Speaking of which, why not add link to CoC to https://www.mediawiki.org/wiki/Developer_access ? It is linked to literally every repo on github, and if a newcomer is going to click any links, that would probably one of the first.
Same question for https://www.mediawiki.org/wiki/How_to_contribute.

TheDJ added a comment.EditedJun 11 2017, 11:37 AM

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. With extension or not, that's bikeshedding.

Eh. Markdown is like the defacto standard throughout the development world atm. (pretty much because it IS still readable even as pure text). Not only in Github, but also in Gitlab, phabricator etc. And lets not forget that we already use it all over the place.
https://github.com/search?l=Markdown&o=asc&q=org:wikimedia+extension:md&ref=advsearch&s=indexed&type=Code&utf8=✓

jeblad added a subscriber: jeblad.Jun 11 2017, 8:51 PM

I have a repo at GitHub where this file is added, and even if I do like the idea of a CoC (this is really a bad TLA) it is out of place in a code repo. Especially as in this case the repo at Gerrit only act as a lazy-update mirror.

This kind of stuff should go in the footer on all sites used by WMF, not only technical sites, as this is a kind of obvious stuff that everyone should know.

I have not made up my mind, but I believe I'm going to remove the file.

Eh. Markdown is like the defacto standard throughout the development world atm. (pretty much because it IS still readable even as pure text). Not only in Github, but also in Gitlab, phabricator etc. And lets not forget that we already use it all over the place.

Phabricator does not interpret markdown on browsing the code, and this is the relevant use-case here. See for instance https://phabricator.wikimedia.org/source/phabricator/browse/wmf%252Fstable/README.md.

TheDJ added a comment.Jun 12 2017, 9:50 AM

Eh. Markdown is like the defacto standard throughout the development world atm. (pretty much because it IS still readable even as pure text). Not only in Github, but also in Gitlab, phabricator etc. And lets not forget that we already use it all over the place.

Phabricator does not interpret markdown on browsing the code, and this is the relevant use-case here. See for instance https://phabricator.wikimedia.org/source/phabricator/browse/wmf%252Fstable/README.md.

Well yes and no. For instance, it does interpret it when you get the repo view: https://phabricator.wikimedia.org/source/phabricator/browse/wmf%252Fstable/

This is mostly because phabricator has not yet implemented 'file previewing' in general (only syntaxhighlighting). There's a long ticket about that: https://secure.phabricator.com/T5698 For now, they indeed only special cased README.md for the root browse view of a repo.

Huji added a comment.Jun 12 2017, 11:27 PM
This comment was removed by Huji.
Elitre added a subscriber: Elitre.Jun 13 2017, 8:22 AM

I'm not sure I should wade into this controversy, but here goes...

Huji somewhat made this point earlier, but I think it's worth stating it in full: whatever you think of the Code of Conduct and the way it was created and approved, these new files are stating something that's simply false. The text of the current "Code of Conduct" files reads:

The development of this software is covered by a Code of Conduct.

That's not true, though. 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. So while I think there are a number of valid reasons to remove these files, the main one is that what they're stating is false.

Nuria added a comment.Jun 13 2017, 6:09 PM

It could have been done by anyone in the world, on any platform, and under any sort of social conditions,

As stated several times on this thread this case is also covered by CoC. Wikimedia technical spaces are spaces in which software for Wikimedia projects is developed. The CoC applies because the committer is working on the project.

@Nuria - I believe that's incorrect; the code of conduct defines Wikimedia technical spaces as "physical spaces, such as Wikimedia technical events and Wikimedia technical presentations in other events, and virtual spaces (MediaWiki.org, wikitech.wikimedia.org, Phabricator, Gerrit, technical mailing lists, technical IRC channels, and Etherpad)."

demon removed a subscriber: demon.Jun 13 2017, 7:06 PM

@Tgr: I'm struggling to see how you filing this task, reviewing https://gerrit.wikimedia.org/r/355875 with a +1, and then merging the changeset yourself (+2) is kosher. You have a pretty clear conflict of interest with respect to this change.
Even if you hadn't filed this task and reviewed the changeset, both you and @Mattflaschen-WMF are both partisan crusaders for establishing this code of conduct. How is it ethical for you two to be making changes like this to any repository?

I wrote the text of CODE_OF_CONDUCT.md. Three other people then supported putting that exact text in core, no one opposed adding it to core, and then one of those three merged it.

That is a straightforward and appropriate use of Gerrit (in fact, far more affirmation than a typical Gerrit change gets); it's not unusual for the filer of a bug to +2 a fix. Having the same opinion on multiple occasions is not a conflict of interest, and @Tgr's +2 was appropriate.

You should retract your post above.

Okay, so you mean it is not a "Foundation"-specific issue, but more general to the whole Wikimedia movement (a movement, who among other things, motivates volunteers to code for a related software called MediaWiki). I get that. I still think, though, that Wikimedia *happens to be* very related to MediaWiki, and should try to minimize its footprint in the code. MW is not a Wikimedia-only product, and we all know it.

The Wikimedia technical community (part of the overall movement) wrote MediaWiki. It doesn't make sense for the Wikimedia technical community to minimize its footprint in MW. In fact, MW is a key part of the footprint of the community (using footprint in a neutral sense).

The "consensus" to add this file to MediaWiki core came from two individuals who were heavily involved in campaigning for this code of conduct.

This characterization is simply false. See above.

I'm not here to point fingers or start an outright riot, but I am more confused on how this is going to be formatted, do we need to attribute, do we need to include CoC contributors names?

I don't completely understand the question. The text is at https://gerrit.wikimedia.org/r/#/c/355875/ and extremely simple. There is no attribution and the formatting is simple (just a link). It just points to the policy document.

Obviously patch contributors should familiarize themselves with the appropriate documentation, and this includes not just coding conventions etc. but also the code of conduct.

It's a binding policy (and that includes being binding on all activity on our Gerrit, period) whether the .md file is there or not, but if you want people to familiarize themselves, doesn't putting a one-line file into the repo make it easier for them to do so?

And if there is an absolute preference to keep them as markdown, can we at least rename them to COC.md instead?

It apparently has to be that exact filename if we want GitHub to automatically recognize it. And there's no real downside to that filename.

Speaking of which, why not add link to CoC to https://www.mediawiki.org/wiki/Developer_access ? It is linked to literally every repo on github, and if a newcomer is going to click any links, that would probably one of the first.

Added to Developer access.

As for the wording of the .md file, I don't claim my wording is perfect, but let's use it until someone suggests a better alternative.

Dzahn added a subscriber: Dzahn.Jun 13 2017, 11:00 PM

doesn't make sense to put it in every single repository when the CoC is for the people and the interactive spaces in which they work, not the technical output thereof.
Essentially: how the code is developed within Wikimedia is determined by policies present on gerrit, phabricator, etc. It does not pertain to the code itself where it is distributed to or picked up by third parties (unless you want to add this to the license or something, but that probably wouldn't be enforceable either). Thus the relevant policies (the CoC) should be made known and available on gerrit, phabricator, etc, not included in the code.

I want to support this point of view, i would also say it should be on Gerrit, Phabricator etc but not in every single repo for the reasons above. That is independent from the content of the CoC or an opinion on it.

Oh, I didn't realize that @Isarra also made essentially the same point that I did.

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.
  • 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.

Tgr added a comment.Jun 19 2017, 10:23 AM

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

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.

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.

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.

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.

Tgr added a comment.Jun 19 2017, 10:44 AM

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.

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.

Tgr added a comment.Jun 19 2017, 12:50 PM

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

@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.

Tgr moved this task from Backlog to Pending on the User-Tgr board.

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

Dzahn removed a subscriber: Dzahn.Jun 5 2018, 8:09 PM
matmarex removed a subscriber: matmarex.Jun 5 2018, 10:39 PM

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

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

Nemo_bis added a comment.EditedJun 8 2018, 9:27 PM

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.

Tgr added a subscriber: Nemo_bis.Jun 10 2018, 9:40 PM

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.

Reedy moved this task from Backlog to Other on the Repository-Admins board.Sep 21 2018, 2:05 AM
D3r1ck01 updated the task description. (Show Details)Sep 21 2018, 8:43 PM
D3r1ck01 awarded a token.
hashar closed this task as Resolved.Sep 21 2018, 9:07 PM
hashar claimed this task.
hashar added a subscriber: hashar.

The Code of Conduct is already listed everywhere (eg Phabricator, soon Gerrit etc). It has been added to all mediawiki extensions and skins.

If one really want to get it added to all repositories on Gerrit and GitHub that is a daunting task. Come up with a script that list open repositories, add the file to each of them and most importantly, have a way to enforce it or at least verify repositories missing it.

For now, that seems sufficient.

Tgr reopened this task as Open.Sep 22 2018, 4:58 PM

IMO before we close this task we should

  • decide on the final language. There was that monstre email thread which pointed out some problems and recommended an alternative language; do we want to follow through on that?
  • make sure all MediaWiki extensions and skins (that use Gerrit as the primary repo) have the CoC file. There was a one-time effort in 2007 July; extensions/skins created since then do not generally have the file.
  • make sure future extensions and skins have the file (unless the repo owner explicitly opts out). That probably means integrating it somehow into new repository requests.
Tgr updated the task description. (Show Details)Sep 22 2018, 5:01 PM

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