The right place for COC related stuff is probably on the Gerrit user interface. On Fri, Jun 8, 2018, 11:48 AM Daniel Zahn <dzahn(a)wikimedia.org> wrote:

On Fri, Jun 8, 2018 at 8:18 AM Daniel Zahn <dzahn(a)wikimedia.org> wrote: I'd argue we should, but let me say first that if we do make it mandatory, that should happen via some mechanism that's appropriate for making policy (RfC, TechCom decree, CoC committee decision, whatever) and not by making threats in a gerrit comment thread. I don't doubt that everyone involved had good intentions but the way the patch was merged was unfortunate IMO. That said: * The code of conduct is a tool to make contributors feel welcome. For some of us being welcomed when we contribute our time and knowledge to an opensource project is so natural that the effort might seem weird. Others (especially those belonging to a historically oppressed or heavily stereotyped group) have different experiences and might have become more cautious about putting time and mental and emotional effort into getting involved with a project, when such involvement in the past often resulted in them being criticized or insulted for reasons having nothing to do with their contributions. We should reach out to those people and tell them that we care, that the MediaWiki/Wikimedia developer community is a respectful space and they should feel safe to invest their time energy. * Site footers are not a good place for that message, because people only see them when they are fairly involved already. (Realistically, not even then. Do you use Github? Have you ever read Github's terms of servce? I didn't think so.) People interact with the files first, so that's the most obvious place to put such a message. Moreover, CODE_OF_CONDUCT.md is now the standard way of doing that notice, thanks to Github's efforts to promote it, so that's where people will look. If we want to signal something very conspicuously, and there is a standard way of signaling it, it would be dumb not to make use of that. * Wikimedia technical spaces are the ones where we can directly enforce the code of conduct. I don't think this means it ceases to exist at the borders of those spaces. I stand by the thought experiment I gave when this topic was discussed last year in the task Yaron linked: "Imagine 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 developers 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 the abuse happens outside our technical spaces." * There can be all kinds of reasons why the CoC file is not appropriate for some repository (which is why it wasn't added to all repositories, just MediaWiki and its extensions). But if we let people remove it for the sole reason that they don't like the code of conduct, what does it say about out commitment to enforce it? It sends the message "we have a code of conduct, and we'll use it to protect you, except when the maintainer of some repository disagrees". I do not think we want that. I would be more sympathetic if I saw how having the CoC file there might harm or even just inconvenience maintainers, but removing it just to make some kind of philosophical point is unhelpful. Yaron, I respect you a lot as a developer, I think your involvement in the CoC discussions was always constructive despite clearly not liking the whole idea, and I'm sure you wouldn't act (inside or outside Wikimedia technical spaces) in ways inconsistent with the spirit of the code of conduct anyway, but this was a silly fight to pick and I hope you'll reconsider (or if you have pragmatic reasons for not wanting the file, you'll explain those).

This! It is not the first time that individual developers have misused their +2 rights to sidestep community processes and enforce their political views. It is this kind of repeated overreach and casual disregard for the wishes and opinions of the repo owner that makes people choose GitHub over Gerrit. It is a pity that there is even a need for a CoC, but I am more than happy to have one if it helps to make people feel more comfortable. But insinuating that not wanting that file in each and every repo would imply disagreement with the code itself is not only insulting, it has a chilling effect on the communication here. And by now, since this has happened and has been called out repeatedly in this discussion, I consider it intentional. The whole issue is another nice demonstration of why "benevolent" dictatorship and decisions taken "for your own good" do not work. Incidentally, what is the procedure to request removal of +2 rights for somebody on my extension repo? Stephan

On Fri, Jun 8, 2018 at 3:26 PM, Stephan Gambke <s7eph4n(a)protonmail.com> wrote: If you really wanted, and your extension is not deployed to Wikimedia wikis, I think it could be done if you requested it on Phabricator. There are definitely repositories where the "normal" +2 reviewers (able to +2/-2 patches in mediawiki/core and extensions) do not have access (e.g. operations/mediawiki-config). But I'm not sure how it is implemented technically, the reviewers' righs might apply to the "mediawiki/* namespace"? in which case it could be a problem to change it for one repo. In this particular case though, Chad is a Gerrit administrator, so he would be able to merge the patch anyway. I don't think this problem calls for a technical solution. -- Matma Rex

Honestly I find forcing documentation into repos to be abrasive, and overstepping the bounds of the CoC.I also find the behavior of those pushing such an approach to be hostile and overly aggressive. Why do you need to force a copy of the CoC into every repo? Why not keep it in a central location? What kind of mess would you need to cleanup if for some reason you needed to adjust the contents of that file? Instead of having one location to update you now have 800+ copies that need fixed. On Thu, Jun 7, 2018 at 8:23 PM, Yaron Koren <yaron(a)wikiworks.com> wrote:

*It's a reasonable ask to have the file there *Correct, its reasonable to ask. Forcing it down peoples throats and cluttering 830+ repos with the same file is not. Why not have it in the primary mediawiki directory and note that it covers all sub-projects? Threatening users and telling users that disagrees with your position about a file requirement not in the CoC is flat out intimidation. Instead of saying *Maybe this should be brought up for discussion *users are now defending and threatening users who questioned them. Just leaves a sour taste in my mouth. Feel free to continue to personally attack those who you disagree with, instead of the subject mater. Whatever On Thu, Jun 7, 2018 at 8:48 PM, Ryan Lane <rlane32(a)gmail.com> wrote:

I think that advertising the COC might still have been in "good faith", though it should have been done with a mail to the project owners. But what I find very objecting is the way the two developers have communicated on the gerrit thread. Both Antoine and Chad (both senior devs that we used to look up to) behaved in a rather dictatorish manner which is not even seen around profit making companies. Neither cared to explain and discuss on the issue, while Yaron was trying his best to. Regards, Nischay Nahata On Fri, Jun 8, 2018 at 9:49 AM MZMcBride <z(a)mzmcbride.com> wrote:

It did sound like a threat given that no policy has been framed around this, but I am glad to know that it was not your intent. Also, its strange that someone can just remove someone else's code review just like that on gerrit, add their own review and merge a patch. Regards, Nischay Nahata On Fri, Jun 8, 2018 at 3:46 PM Antoine Musso <hashar+wmf(a)free.fr> wrote:

On Fri, Jun 8, 2018 at 7:02 AM Alex Monk <krenair(a)gmail.com> wrote: https://gerrit.wikimedia.org/r/Documentation/access-control.html#category_r… Anyone who is a project owner on mediawiki/* could have done it, it had nothing to do with admin permissions. But that's not the point of this thread at all... -Chad

To directly answer the question in the subject: of course Yaron's extensions should stay in gerrit.wikimedia.org, without the file in question. We want MediaWiki's main development spaces to be inclusive and able to bring developers together. I think we all agree that it's a loss if more repositories end up being scattered on third party git servers. Meddling with the content of repositories we host by forcing Wikimedia-specific content is not responsible. For one, it makes it impossible to multi-host a repository if such Wikimedia-specific content is incompatible with the requirements of other hosts. Federico

On Fri, Jun 8, 2018 at 12:19 AM MZMcBride <z(a)mzmcbride.com> wrote: Probably. I was in a pretty crappy mood and I went "not again" and merged it. I don't actually care one way or the other if repos have the file (nb: I support the CoC), but I just want to be **consistent** If we're gonna have them: have them everywhere. If not, then we should be removing them everywhere. -Chad

On Fri, Jun 8, 2018 at 9:44 AM, Yaron Koren <yaron(a)wikiworks.com> wrote: Let's not lose sight of Yaron's proposal for compromise here. Having slightly different wording here seems like it would be a win-win for everyone: those who want to be sure new contributors get a pointer to the CoC would be satisfied, and Yaron would be satisfied that he is not misrepresenting the scope of the CoC in his own repositories. It seems that other multi-homed repositories might have similar wording tweaks. A repo which takes pull requests via github, for example, might have a CoC mentioning the applicability of github's CoC or WMF's CoC, depending on circumstances. I think there are a number of fascinating topics here, and it's probably certainly worth documenting the costs/benefits of WMF hosting (eg implicit +2 access by maintainers, which could be a con, but the pro side is that you get translatewiki integration, library upgrades, and other maintenance work done "for free") along with pointers so that new repo owners can easily find out exactly who has maintainer rights to their repo and a short history describing why that decision was made. That documentation would also be a good place for best practices such as README and CoC (as well as clarifying the circumstances where the CoC is expected to apply). A good question. My personal opinion is (a) it should be mandatory, but the contents not strictly proscribed -- in the same way that github loosely-requires an open source license statement in its public repos (ie, I think it's in the terms of service but not enforced by code), and (b) the proper mechanism is probably techcomm/archcomm. This is just my opinion -- I'm interested in hearing further discussion of these points --- but let's not get distracted from considering (and hopefully accepting) Yaron's compromise offer. --scott

On Fri, Jun 8, 2018 at 3:44 PM Yaron Koren <yaron(a)wikiworks.com> wrote: Thanks for the constructive proposal, Yaron. I agree this is an accurate description of what the code of conduct says now about scope. I still think limiting scope like that is problematic and in the unlikely case that someone does abuse or harass community members outside Wikimedia platforms while simultaneously making use of those platforms, I believe the CoC committee would leverage that to deter them (threaten to ban or fork if it comes to that) - that seems like the only morally tenable option. So I guess the best way to resolve the issue is to make a CoC amendment proposal. It still leaves open the question of whether the file should be made A CoC committee decision, presumably? They are probably in the best position to tell whether it would meaningfully help their work or not. That said, we still haven't solved adding the file to new repos automatically, or added it to the repos created since last summer, or determined which non-extension/skin repos makes it sense to add to, all of which have much more impact than anything that could happen with the handful of repos where it is actively opposed. So it does not make sense to invest a lot of energy into this right now, IMO. As I wrote briefly before, I just don't think the file I'd still like the understand what the assumed harm is. Is this strictly a moral issue, where you want to avoid giving misleading information, but otherwise that information would be harmless? Or a liability issue, where your clients think that working on / using a CoC-covered extension makes it more likely that they get sued or publicly attacked? Or do you think you might work with clients who might be deterred because they do development in ways that violate the CoC, and would be unwilling to change that? Or some clients might boycott such extensions for political reasons? On Fri, Jun 8, 2018 at 8:23 PM Greg Rundlett (freephile) <greg(a)freephile.com> wrote: Thanks for being specific about how the file is a problem for you. It is important for the health of the MediaWiki ecosystem that we make commercial MediaWiki development as frictionless as possible and don't create policies that place an undue burden on it. That said, code of conduct notices are already abundant in opensource software; we are not doing some kind of bold new experiment, just following the standard. Was there a chilling effect for projects that added such a file? Are you aware of consultants running into problems over that? How do you handle this issue in your own work in non-MediaWiki code? Do you, for example, choose between Javascript frameworks or PHP libraries you include in your extensions based on whether they include a code of conduct? On Sat, Jun 9, 2018 at 3:28 AM C. Scott Ananian <cananian(a)wikimedia.org> wrote: On reflection, I think trying to involve TechCom would be a bad idea. In a contentious issue like this, any decision (or even the refusal to make one) would probably result in a loss of social capital, which is better spent on getting people on board with transforming MediaWiki architecture. The CoC committee on the other hand was selected and trained for expertise in specifically these kinds of social issues, and they don't have much standing to lose in the eyes of people who are dubious about the CoC anyway. On Fri, Jun 8, 2018 at 6:13 PM Brian Wolff <bawolff(a)gmail.com> wrote: While I disagree that this would be an accurate description of what happened, in general I think it's a good idea to let arguments with no clear winner rest for a while before looking at them again, instead of trying to force a resolution no matter the cost. Opinions evolve, cultural trends shift, demographics change, people might gain more experience in the topic that was discussed, the community's decisionmaking infrastructure might improve; closing off a debate might became much cheaper with a little patience. We are in this for the long run, as the Wikipedia people say. On Fri, Jun 8, 2018 at 6:32 PM Brian Wolff <bawolff(a)gmail.com> wrote: On Fri, Jun 8, 2018 at 3:26 PM Stephan Gambke <s7eph4n(a)protonmail.com> wrote: Thanks both for bringing that up. It is important to acknowledge that people on every side of this debate might feel stressed or threatened, and do what we can to minimize that. Extrapolating from comments to presumed views about the code of conduct is something I should try harder to avoid; I apologize.