On Fri, Jun 8, 2018 at 9:44 AM, 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.
>

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


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

Reply via email to