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