On Wed, Sep 25, 2019 at 5:42 PM Jeff King <p...@peff.net> wrote: > > We've never had a formally written Code of Conduct document. Though it > has been discussed off and on over the years, for the most part the > behavior on the mailing list has been good enough that nobody felt the > need to push one forward. > > However, even if there aren't specific problems now, it's a good idea to > have a document: > > - it puts everybody on the same page with respect to expectations. > This might avoid poor behavior, but also makes it easier to handle > it if it does happen. > > - it publicly advertises that good conduct is important to us and will > be enforced, which may make some people more comfortable with > joining our community > > - it may be a good time to cement our expectations when things are > quiet, since it gives everybody some distance rather than focusing > on a current contentious issue > > This patch adapts the Contributor Covenant Code of Conduct. As opposed > to writing our own from scratch, this uses common and well-accepted > language, and strikes a good balance between illustrating expectations > and avoiding a laundry list of behaviors. It's also the same document > used by the Git for Windows project. > > The text is taken mostly verbatim from: > > https://www.contributor-covenant.org/version/1/4/code-of-conduct.html > > I also stole a very nice introductory paragraph from the Git for Windows > version of the file. > > There are a few subtle points, though: > > - the document refers to "the project maintainers". For the code, we > generally only consider there to be one maintainer: Junio C Hamano. > But for dealing with community issues, it makes sense to involve > more people to spread the responsibility. I've listed the project > committee address of g...@sfconservancy.org as the contact point. > > - the document mentions banning from the community, both in the intro > paragraph and in "Our Responsibilities". The exact mechanism here is > left vague. I can imagine it might start with social enforcement > (not accepting patches, ignoring emails) and could escalate to > technical measures if necessary (asking vger admins to block an > address). It probably make sense _not_ to get too specific at this > point, and deal with specifics as they come up. > > Signed-off-by: Jeff King <p...@peff.net> > --- > Obviously related to the discussion in: > > https://public-inbox.org/git/71fba9e7-6314-6ef9-9959-6ae06843d...@gmail.com/ > > After some poking around at various CoC options, this one seemed like > the best fit to me. But I'm open to suggestions or more discussion. It > seems to me that the important piece is having _some_ CoC, and picking > something standard-ish seems a safe bet. > > I did find this nice set of guidelines in an old discussion: > > > https://github.com/mhagger/git/commit/c6e6196be8fab3d48b12c4e42eceae6937538dee > > I think it's missing some things that are "standard" in more modern CoCs > (in particular, there's not much discussion of enforcement or > responsibilities, and I think those are important for the "making people > comfortable" goal). But maybe there are bits we'd like to pick out for > other documents; not so much "_what_ we expect" as "here are some tips > on _how_". > > If people are on board with this direction, it might be fun to pick up a > bunch of "Acked-by" trailers from people in the community who agree with > it. It might give it more weight if many members have publicly endorsed > it.
Acked-by: Elijah Newren <new...@gmail.com> (including the small update you sent elsewhere to individually list the members of project leader team.)
