On Fri, Jun 8, 2018 at 3:44 PM Yaron Koren <ya...@wikiworks.com> wrote:

> I suppose that one solution which hasn't been discussed yet is to change
> the wording of that file so that it says something more defensible, like
> "This extension is hosted on facilities governed by the Code of Conduct",
> or that kind of thing - that would at least remove the pragmatic objection
> that I (and some others in this thread) have raised.
>

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
> mandatory, and if so, what the mechanism should be to determine that.
>

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
> is making an accurate statement, given that it implies that *all*
> development of the extension is governed by the CoC, which is not the case.


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) <g...@freephile.com>
wrote:

> I can also (as a consultant) see
> how written policies which my clients see in my code could be construed as
> a possible LIABILITY or RISK on their  part. They'll either want me to
> carry more indemnity insurance, or even be disinclined to do business with
> me. Not because they don't abide by the code of conduct, but because
> there's an explicit notice of some obligation that creates liability.


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 <canan...@wikimedia.org>
wrote:

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


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 <bawo...@gmail.com> wrote:

> * Generally speaking, its usually considered in poorform to have an
> argument about something, lose the argument (or at least not win it), wait
> a year until people forget about it, and then try and do the exact same
> thing.
>

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 <bawo...@gmail.com> wrote:

> Fwiw, I also had a discussion last night with someone who hasnt
> participated in this discussion as of yet but stated that incidents like
> this make them want to host their extensions elsewhere except they are not
> willing to pass up translatewiki integration-so the people not commenting
> objection goes both ways


On Fri, Jun 8, 2018 at 3:26 PM Stephan Gambke <s7ep...@protonmail.com>
wrote:

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

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.
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to