linux-kernel - Re: [Ksummit-discuss] [PATCH] code-of-conduct: Remove explicit list of discrimination factors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdVmz-ZF+ypp4WEkW6txxjw66DTb5PRsSGPsUfBqT+NbMQ@mail.gmail.com>
Date:   Mon, 8 Oct 2018 16:30:57 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     "Bird, Timothy" <Tim.Bird@...y.com>
Cc:     Josh Triplett <josh@...htriplett.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ksummit-discuss@...ts.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [PATCH] code-of-conduct: Remove explicit list
 of discrimination factors

Hi Tim,

On Mon, Oct 8, 2018 at 4:12 PM <Tim.Bird@...y.com> wrote:
> > From: Josh Triplett
> > On Sun, Oct 07, 2018 at 08:18:26PM +0300, Laurent Pinchart wrote:
> > > On Sunday, 7 October 2018 14:35:14 EEST Josh Triplett wrote:
> > > > On Sun, Oct 07, 2018 at 10:51:02AM +0200, Geert Uytterhoeven wrote:
> > > > > Providing an explicit list of discrimination factors may give the false
> > > > > impression that discrimination based on other unlisted factors would be
> > > > > allowed.
> > > > >
> > > > > Avoid any ambiguity by removing the list, to ensure "a harassment-free
> > > > > experience for everyone", period.
> > > >
> > > > I would suggest reading the commit message that added this in the first
> > > > place. "Explicit guidelines have demonstrated success in other projects
> > > > and other areas of the kernel." See also various comparisons of codes of
> > > > conduct, which make the same point. The point of this list is precisely
> > > > to serve as one such explicit guideline; removing it would rather defeat
> > > > the purpose.
> > > >
> > > > In any case, this is not the appropriate place for such patches, any
> > > > more than it's the place for patches to the GPL.
> > >
> > > So what's an appropriate place to discuss the changes that we would like,
> > > *together*, to make to the current document and propose upstream ?
> >
> > I didn't say "not the appropriate place to discuss" (ksummit-discuss is
> > not ideal but we don't currently have somewhere better), I said "not the
> > appropriate place for such patches".
> >
> > The Linux kernel is by no means the only project using the Contributor
> > Covenant. In general, we don't encourage people working on significant
> > changes to the Linux kernel to work in private for an extended period
> > and only pop up when "done"; rather, we encourage people to start
> > conversations early and include others in the design. Along the same
> > lines, I'd suggest that patches or ideas for patches belong upstream.
> > For instance, the idea of clarifying that email addresses already used
> > on a public mailing list don't count as "private information" seems like
> > a perfectly reasonable suggestion, and one that other projects would
> > benefit from as well.
>
> So I raised this issue with upstream about 2 weeks ago, and here is my
> experience:
> 1) I suggested that the email clarification could be put into the covenant
> itself, or in a supporting FAQ.
> 2) The project maintainer (Coraline Ada Ehmke) was pleasant and supportive
> of changes to enhance the document, and said either approach would be fine.
> 3) I noticed that there was a FAQ in progress of being created.
> 4) After thinking about it, I decided that I didn't want to alter the language
> of the covenant, because I didn't want to dilute the expression of a need to
> get permission when revealing private information.
>
> My own opinion is that putting clarifying language in a FAQ is sufficient.
> So I made the following recommendation for the (not yet included upstream)
> FAQ:
>
> Q: Does the prohibition on publishing private information include email addresses sent to a public list?
> A: No. Information that has voluntarily been published to a public location does not fall under the category of private information. Such public information may be used within the context of the project according to project norms (such as in commit meta-data in code repositories), without that constituting a breach of the CoC.

I noticed this morning this is actually already included in the FAQ
(I didn't know this is recent thing):
https://www.contributor-covenant.org/faq

> I don't know what progress is being made adopting the FAQ, but Coraline seems very
> supportive, and I've told here that I will come back and help with it if it stalls.

I'm glad to heart that!

FTR, I've submitted my patch earlier today, too:
https://github.com/ContributorCovenant/contributor_covenant/issues/610

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds