[PATCH] code-of-conduct: Remove explicit list of discrimination factors

[PATCH] code-of-conduct: Remove explicit list of discrimination factors

[Geert Uytterhoeven]

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.

Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
The use of "race" may also conflict with the United Nation's views on
this matter, cfr. e.g. the UNESCO's "Four statements on the race
question"[1][2] and "Declaration on Race and Racial Prejudice"[3].

[1] https://en.wikipedia.org/wiki/The_Race_Question
[2] http://unesdoc.unesco.org/images/0012/001229/122962eo.pdf
[3] http://portal.unesco.org/en/ev.php-URL_ID=13161&URL_DO=DO_TOPIC&URL_SECTION=201.html
---
 Documentation/process/code-of-conduct.rst | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
index ab7c24b5478c6b30..e472c9f86ff00b34 100644
--- a/Documentation/process/code-of-conduct.rst
+++ b/Documentation/process/code-of-conduct.rst
@@ -6,10 +6,7 @@ Our Pledge
 
 In the interest of fostering an open and welcoming environment, we as
 contributors and maintainers pledge to making participation in our project and
-our community a harassment-free experience for everyone, regardless of age, body
-size, disability, ethnicity, sex characteristics, gender identity and
-expression, level of experience, education, socio-economic status, nationality,
-personal appearance, race, religion, or sexual identity and orientation.
+our community a harassment-free experience for everyone.
 
 Our Standards
 =============
-- 
2.17.1

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

[Josh Triplett]

On Wed, Oct 17, 2018 at 09:19:01AM +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.

This impression is, in fact, false, as has already been discussed
elsewhere. I had hoped that discussion would suffice.

As mentioned there: The original commit explicitly said "Explicit
guidelines have demonstrated success in other projects and other areas
of the kernel."; this is precisely the kind of explicit guideline it
refers to. Listing explicit cases to cover does not imply other cases
are not covered; it does, however, ensure that the listed cases *are*,
and helps people know that they're covered.

This patch is not OK, and defeats one of the purposes of the original
change.

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

[Geert Uytterhoeven]

Hi Josh,

Thanks for your comments!

On Wed, Oct 17, 2018 at 11:13 AM Josh Triplett <josh@joshtriplett.org> wrote:
> On Wed, Oct 17, 2018 at 09:19:01AM +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.
>
> This impression is, in fact, false, as has already been discussed
> elsewhere. I had hoped that discussion would suffice.

The CoC FAQ is not part of the CoC, and not part of the Linux kernel.
If the CoC is imprecise, it should be fixed in the CoC, not in a separate
document hosted elsewhere, as discussed elsewhere.

Comparison with the GPL and the GPL FAQ is not appropriate, as the GPL
is still the precise legal document, while its FAQ is a clarification using
laymen's terms.

> As mentioned there: The original commit explicitly said "Explicit
> guidelines have demonstrated success in other projects and other areas
> of the kernel."; this is precisely the kind of explicit guideline it

Given the original commit was not submitted for and objected to public
review, nobody had the chance to question these statements, and ask for
pointers of proof, which would surely have happened.

> refers to. Listing explicit cases to cover does not imply other cases
> are not covered;

It does, if not accompanied by "examples of...", like in the other sections.

> it does, however, ensure that the listed cases *are*,
> and helps people know that they're covered.

So you agree people cannot know if the unlisted cases are covered or not?

> This patch is not OK, and defeats one of the purposes of the original
> change.

So the purpose of the original change was to list a number of factors,
without saying that it was just a list of examples?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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

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

[Guenter Roeck]

On 10/17/2018 02:31 AM, Geert Uytterhoeven wrote:
> Hi Josh,
> 
> Thanks for your comments!
> 
> On Wed, Oct 17, 2018 at 11:13 AM Josh Triplett <josh@joshtriplett.org> wrote:
>> On Wed, Oct 17, 2018 at 09:19:01AM +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.
>>
>> This impression is, in fact, false, as has already been discussed
>> elsewhere. I had hoped that discussion would suffice.
> 
> The CoC FAQ is not part of the CoC, and not part of the Linux kernel.
> If the CoC is imprecise, it should be fixed in the CoC, not in a separate
> document hosted elsewhere, as discussed elsewhere.
> 
> Comparison with the GPL and the GPL FAQ is not appropriate, as the GPL
> is still the precise legal document, while its FAQ is a clarification using
> laymen's terms.
> 
>> As mentioned there: The original commit explicitly said "Explicit
>> guidelines have demonstrated success in other projects and other areas
>> of the kernel."; this is precisely the kind of explicit guideline it
> 
> Given the original commit was not submitted for and objected to public
> review, nobody had the chance to question these statements, and ask for
> pointers of proof, which would surely have happened.
> 
>> refers to. Listing explicit cases to cover does not imply other cases
>> are not covered;
> 
> It does, if not accompanied by "examples of...", like in the other sections.
> 
>> it does, however, ensure that the listed cases *are*,
>> and helps people know that they're covered.
> 
> So you agree people cannot know if the unlisted cases are covered or not?
> 
>> This patch is not OK, and defeats one of the purposes of the original
>> change.
> 
> So the purpose of the original change was to list a number of factors,
> without saying that it was just a list of examples?

One could consider adding something like "discrimination factors such as",
or maybe "or any other discrimination factors not listed here" to the
original text. Or a simple "regardless of, for example, ...".

Guenter

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

[Guenter Roeck]

On 10/17/2018 02:13 AM, Josh Triplett wrote:
> On Wed, Oct 17, 2018 at 09:19:01AM +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.
> 
> This impression is, in fact, false, as has already been discussed
> elsewhere. I had hoped that discussion would suffice.
> 
> As mentioned there: The original commit explicitly said "Explicit
> guidelines have demonstrated success in other projects and other areas
> of the kernel."; this is precisely the kind of explicit guideline it
> refers to. Listing explicit cases to cover does not imply other cases
> are not covered; it does, however, ensure that the listed cases *are*,
> and helps people know that they're covered.
> 

That is really a matter of opinion. Mathematically speaking, your statement
is incorrect. One may wonder why the list is made explicit without hint
that it is an example. For example, political or social views are _not_
listed. Wasn't the same CoC used in other projects to at least try to
punish individuals with specific political and/or social opinions,
just for having those opinions and expressing them outside the scope of
the project ?

> This patch is not OK, and defeats one of the purposes of the original
> change.

The CoC, as it stands, singles out maintainers for enforcement action.
Based on your statement, is it correct to assume that this was on
purpose ? If not, what is the explicit list of purposes of the
original change ?

Guenter

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

[Josh Triplett]

On Wed, Oct 17, 2018 at 11:31:35AM +0200, Geert Uytterhoeven wrote:
> Hi Josh,
> 
> Thanks for your comments!
> 
> On Wed, Oct 17, 2018 at 11:13 AM Josh Triplett <josh@joshtriplett.org> wrote:
> > On Wed, Oct 17, 2018 at 09:19:01AM +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.
> >
> > This impression is, in fact, false, as has already been discussed
> > elsewhere. I had hoped that discussion would suffice.
> 
> The CoC FAQ is not part of the CoC, and not part of the Linux kernel.

I wasn't referring just to that; I'm referring to the discussion we've
already had on this exact point.

> > refers to. Listing explicit cases to cover does not imply other cases
> > are not covered;
> 
> It does, if not accompanied by "examples of...", like in the other sections.

"for everyone, regardless of ..." still says "for everyone", making the
"regardless of ..." inherently a non-exhaustive list of factors.

> > it does, however, ensure that the listed cases *are*,
> > and helps people know that they're covered.
> 
> So you agree people cannot know if the unlisted cases are covered or not?

People in underrepresented and commonly marginalized groups, especially
those more commonly overlooked, don't always know if a given group has
taken their particular group into account or given any thought to it.
Explicit inclusion helps, and this is a standard guideline often cited
for good codes of conduct.

That doesn't make other groups *not* covered. But *if* there is a
particular commonly marginalized group that you feel this should
*explicitly* cover and doesn't, I'd suggest *adding* that group rather
than deleting the existing effort to be explicitly inclusive. (And
again, I'd suggest doing so upstream first.)

> > This patch is not OK, and defeats one of the purposes of the original
> > change.
> 
> So the purpose of the original change was to list a number of factors,
> without saying that it was just a list of examples?

You seem to be actively trying to read something more into what I said.
One of the key purposes of the original change was to make the kernel a
"a welcoming environment to participate in", and to provide "explicit
guidelines".

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

[Josh Triplett]

On Wed, Oct 17, 2018 at 06:32:36AM -0700, Guenter Roeck wrote:
> One could consider adding something like "discrimination factors such as",
> or maybe "or any other discrimination factors not listed here" to the
> original text. Or a simple "regardless of, for example, ...".

These sound like perfectly reasonable ways to address this. Please
consider submitting a patch upstream based on this reasoning.

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

[James Bottomley]

On Wed, 2018-10-17 at 08:21 -0700, Josh Triplett wrote:
> People in underrepresented and commonly marginalized groups,
> especially those more commonly overlooked, don't always know if a
> given group has taken their particular group into account or given
> any thought to it. Explicit inclusion helps, and this is a standard
> guideline often cited for good codes of conduct.

Actually, that's not a good thing to do in a vacuum: you have to be
really careful about how you do this from a legal point of view.  The
argument over whether enumerating specific rights or classes disparages
others has been going on for centuries.  To give you an example of how
far back it goes: it's the reason for the ninth amendment to the US
constitution.

The commonly accepted legal way of doing this today is the statement

"examples of X include but are not limited to: ..."

which is thought to work in most jurisdictions and is what you'll find
in all US corporate codes of conduct or ethics.

James

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

[Josh Triplett]

On Wed, Oct 17, 2018 at 08:49:15AM -0700, James Bottomley wrote:
> On Wed, 2018-10-17 at 08:21 -0700, Josh Triplett wrote:
> > People in underrepresented and commonly marginalized groups,
> > especially those more commonly overlooked, don't always know if a
> > given group has taken their particular group into account or given
> > any thought to it. Explicit inclusion helps, and this is a standard
> > guideline often cited for good codes of conduct.
> 
> Actually, that's not a good thing to do in a vacuum: you have to be
> really careful about how you do this from a legal point of view.  The
> argument over whether enumerating specific rights or classes disparages
> others has been going on for centuries.  To give you an example of how
> far back it goes: it's the reason for the ninth amendment to the US
> constitution.
> 
> The commonly accepted legal way of doing this today is the statement
> 
> "examples of X include but are not limited to: ..."
> 
> which is thought to work in most jurisdictions and is what you'll find
> in all US corporate codes of conduct or ethics.

Which is a much better proposal than removing the list entirely.

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

[Joe Perches]

On Wed, 2018-10-17 at 02:13 -0700, Josh Triplett wrote:
> On Wed, Oct 17, 2018 at 09:19:01AM +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.
> 
> This impression is, in fact, false, as has already been discussed
> elsewhere.

The use of fact above is instead merely an assertion.

>  I had hoped that discussion would suffice.

Nope.

> As mentioned there: The original commit explicitly said "Explicit
> guidelines have demonstrated success in other projects and other areas
> of the kernel."

Correlation etc...

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1601 bytes --]

On Wed, Oct 17, 2018 at 08:21:02AM -0700, Josh Triplett wrote:
> On Wed, Oct 17, 2018 at 11:31:35AM +0200, Geert Uytterhoeven wrote:
> > On Wed, Oct 17, 2018 at 11:13 AM Josh Triplett <josh@joshtriplett.org> wrote:

> > > it does, however, ensure that the listed cases *are*,
> > > and helps people know that they're covered.

> > So you agree people cannot know if the unlisted cases are covered or not?

> People in underrepresented and commonly marginalized groups, especially
> those more commonly overlooked, don't always know if a given group has
> taken their particular group into account or given any thought to it.
> Explicit inclusion helps, and this is a standard guideline often cited
> for good codes of conduct.

I have heard some complaints that the strong push to include these lists
has ended up devaluing them, it becomes hard for people to tell if the
list is just a cut'n'paste job or if the people responsible for the code
of conduct really understand the issues affecting the groups they
include and it can be extra disappointing if there are problems.  I
particularly remember a friend of mine getting into an argument with a
conference being hosted somewhere where being gay was a capital offence
questioning the inclusion of sexuality on their list, it seemed fairly
clear that the organizers meant well and were trying to do the right
thing but weren't really aware.

This doesn't mean don't try but it's definitely a factor to consider,
especially when using an off the shelf code of conduct - there's just
never going to be a single right answer with a lot of this stuff.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] code-of-conduct: Remove explicit list of discrimination factors

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

On Wed 2018-10-17 09:19:01, 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.
> 
> Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>

Acked-by: Pavel Machek <pavel@ucw.cz>

[I'd preffer going to old code of conflict. But even this is an improvement.]

									Pavel

									
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Rainer Fiebig]

Am Mittwoch, 10. Oktober 2018, 15:16:12 schrieb Josh Triplett:
> On Wed, Oct 10, 2018 at 01:55:04PM -0700, Frank Rowand wrote:
> > On 10/07/18 01:51, 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.
> [...]
> > > diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
> > > index ab7c24b5478c6b30..e472c9f86ff00b34 100644
> > > --- a/Documentation/process/code-of-conduct.rst
> > > +++ b/Documentation/process/code-of-conduct.rst
> > > @@ -6,10 +6,7 @@ Our Pledge
> > >  
> > >  In the interest of fostering an open and welcoming environment, we as
> > >  contributors and maintainers pledge to making participation in our project and
> > > -our community a harassment-free experience for everyone, regardless of age, body
> > > -size, disability, ethnicity, sex characteristics, gender identity and
> > > -expression, level of experience, education, socio-economic status, nationality,
> > > -personal appearance, race, religion, or sexual identity and orientation.
> > > +our community a harassment-free experience for everyone.
> > >  
> > >  Our Standards
> > >  =============
> > > 
> > 
> > 
> > The words removed by this patch are a political statement.
> 
> Choosing not to say those words is a political statement.

No. If there's an implicit statement it's "No politics here." 

The patch makes the sentence and its message completely neutral. And what can be more inclusive and encompassing than "everyone"?

> 
> See the original commit message for the code of conduct: "Explicit
> guidelines have demonstrated success in other projects and other areas
> of the kernel."
> 

Which does not mean that this is generally true. I guess you know the difference between deduction and induction.

> And see the FAQ entry at https://www.contributor-covenant.org/faq for
> "The Contributor Covenant explicitly lists a set of protected classes;

"protected classes" is imo very unfortunate wording and very close to "privileged classes". I bet this won't go down well with lots of people, especially in the eastern hemisphere.

Reminds me of "All animals are equal. But some animals are more equal than others."[1]

History has shown were this leads to.

> does this make it acceptable to discriminate or make others feel
> unwelcome based on other factors?" (I wrote that FAQ entry and submitted
> it upstream, where it was enthusiastically merged.)
> 

Not really surprising.


So long!


Rainer Fiebig


[1] https://en.wikipedia.org/wiki/Animal_Farm

-- 
The truth always turns out to be simpler than you thought.
Richard Feynman

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

[Frank Rowand]

On 10/10/18 15:33, Eric S. Raymond wrote:
> Josh Triplett <josh@joshtriplett.org>:
>>> The words removed by this patch are a political statement.
>>
>> Choosing not to say those words is a political statement.
> 
> The situation is not symmetrical.  Choosing the protected classes
> in the CoC is a *change* in its implied politics. 
> 
> It's a change that is, obviously from LKML traffic, very contentious.
> If this were a tpurely technical matter, it would be described as
> not backwards-compatible.
> 
> It's a change that, I submit, should not have been made without a clear
> consensus *in favor* of the change.
> 
> Our culture has a process for this. It's called RFCs. If we want to
> designate protected classes to be called out in conductt guidelines,
> an RFC should be floated first and the change should be made only
> if rough consensus has been achieved.
> 

Thank you for stating that clearly and concisely Eric.

I will bow out of further discussion on this specific point as I
have already seen this concept discussed on many threads already
in recent weeks.

-Frank

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

[Eric S. Raymond]

Josh Triplett <josh@joshtriplett.org>:
> > The words removed by this patch are a political statement.
> 
> Choosing not to say those words is a political statement.

The situation is not symmetrical.  Choosing the protected classes
in the CoC is a *change* in its implied politics. 

It's a change that is, obviously from LKML traffic, very contentious.
If this were a tpurely technical matter, it would be described as
not backwards-compatible.

It's a change that, I submit, should not have been made without a clear
consensus *in favor* of the change.

Our culture has a process for this. It's called RFCs. If we want to
designate protected classes to be called out in conductt guidelines,
an RFC should be floated first and the change should be made only
if rough consensus has been achieved.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

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

[Josh Triplett]

On Wed, Oct 10, 2018 at 01:55:04PM -0700, Frank Rowand wrote:
> On 10/07/18 01:51, 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.
[...]
> > diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
> > index ab7c24b5478c6b30..e472c9f86ff00b34 100644
> > --- a/Documentation/process/code-of-conduct.rst
> > +++ b/Documentation/process/code-of-conduct.rst
> > @@ -6,10 +6,7 @@ Our Pledge
> >  
> >  In the interest of fostering an open and welcoming environment, we as
> >  contributors and maintainers pledge to making participation in our project and
> > -our community a harassment-free experience for everyone, regardless of age, body
> > -size, disability, ethnicity, sex characteristics, gender identity and
> > -expression, level of experience, education, socio-economic status, nationality,
> > -personal appearance, race, religion, or sexual identity and orientation.
> > +our community a harassment-free experience for everyone.
> >  
> >  Our Standards
> >  =============
> > 
> 
> 
> The words removed by this patch are a political statement.

Choosing not to say those words is a political statement.

See the original commit message for the code of conduct: "Explicit
guidelines have demonstrated success in other projects and other areas
of the kernel."

And see the FAQ entry at https://www.contributor-covenant.org/faq for
"The Contributor Covenant explicitly lists a set of protected classes;
does this make it acceptable to discriminate or make others feel
unwelcome based on other factors?" (I wrote that FAQ entry and submitted
it upstream, where it was enthusiastically merged.)

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

[Arnaldo Carvalho de Melo]

Em Wed, Oct 10, 2018 at 01:55:04PM -0700, Frank Rowand escreveu:
> On 10/07/18 01:51, 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.
> > 
> > Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
> > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > ---
> > The use of "race" may also conflict with the United Nation's views on
> > this matter, cfr. e.g. the UNESCO's "Four statements on the race
> > question"[1][2] and "Declaration on Race and Racial Prejudice"[3].
> > 
> > [1] https://en.wikipedia.org/wiki/The_Race_Question
> > [2] http://unesdoc.unesco.org/images/0012/001229/122962eo.pdf
> > [3] http://portal.unesco.org/en/ev.php-URL_ID=13161&URL_DO=DO_TOPIC&URL_SECTION=201.html
> > ---
> >  Documentation/process/code-of-conduct.rst | 5 +----
> >  1 file changed, 1 insertion(+), 4 deletions(-)
> > 
> > diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
> > index ab7c24b5478c6b30..e472c9f86ff00b34 100644
> > --- a/Documentation/process/code-of-conduct.rst
> > +++ b/Documentation/process/code-of-conduct.rst
> > @@ -6,10 +6,7 @@ Our Pledge
> >  
> >  In the interest of fostering an open and welcoming environment, we as
> >  contributors and maintainers pledge to making participation in our project and
> > -our community a harassment-free experience for everyone, regardless of age, body
> > -size, disability, ethnicity, sex characteristics, gender identity and
> > -expression, level of experience, education, socio-economic status, nationality,
> > -personal appearance, race, religion, or sexual identity and orientation.
> > +our community a harassment-free experience for everyone.
> >  
> >  Our Standards
> >  =============
> > 
> 
> 
> The words removed by this patch are a political statement.  They do not belong
> in the document.
> 
> Acked-by: Frank Rowand <frowand.list@gmail.com>

Acked-by: Arnaldo Carvalho de Melo <acme@kernel.org>

- Arnaldo

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

[Josh Triplett]

On Mon, Oct 08, 2018 at 04:42:47PM +0100, Alan Cox wrote:
> > In any case, this is not the appropriate place for such patches, any
> > more than it's the place for patches to the GPL.
> 
> I disagree. We had the GPLv2 or GPLv3 discussion on the kernel mailing
> list. The syscall clarification was discussed on the list. The
> EXPORT_SYMBOL and EXPORT_SYMBOL_GPL stuff was discussed on the list.

And discussion of this could occur on the list, as well. I said "for
such patches", not "for such discussion".

And, incidentally, this particular issues has now been addressed
upstream. I proposed a change to the FAQ, which has now been merged. See
https://www.contributor-covenant.org/faq and
https://github.com/ContributorCovenant/contributor_covenant/pull/612 .

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

[Geert Uytterhoeven]

On Mon, Oct 8, 2018 at 4:30 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> FTR, I've submitted my patch earlier today, too:
> https://github.com/ContributorCovenant/contributor_covenant/issues/610

Will be clarified in the (external-to-Linux) FAQ.

Quoting Coraline: "However, any adopting project is free to modify the document
according to the license."

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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

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

[Alan Cox]

> In any case, this is not the appropriate place for such patches, any
> more than it's the place for patches to the GPL.

I disagree. We had the GPLv2 or GPLv3 discussion on the kernel mailing
list. The syscall clarification was discussed on the list. The
EXPORT_SYMBOL and EXPORT_SYMBOL_GPL stuff was discussed on the list.

Alan

RE: [Ksummit-discuss] [PATCH] code-of-conduct: Remove explicit list of discrimination factors

[Tim.Bird]

> -----Original Message-----
> From: Laurent Pinchart
> 
> Hi Tim,
> 
> On Monday, 8 October 2018 17:12:05 EEST Tim.Bird@sony.com wrote:
> > > -----Original Message-----
> > > 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.
> >
> > You can see the history of discussion in these two issues, online:
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_ContributorCovenant_contributor-
> 5Fcovenant_issues_590&d=DwICAg&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7-
> GLPtvShAo4cc&r=rUvFawR4KzgZu1gSN5tuozUn7iTTP0Y-
> INWqfY8MsF0&m=b6Q42NB0w9BZPta7p9Iyr2Lw91cD5dszFL52DzV3FL0&s=17
> HaUjlX7xwXIvGmJLYhuclrQ1ze-ySl5xLrWIKUDbU&e=
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_ContributorCovenant_contributor-
> 5Fcovenant_issues_575&d=DwICAg&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7-
> GLPtvShAo4cc&r=rUvFawR4KzgZu1gSN5tuozUn7iTTP0Y-
> INWqfY8MsF0&m=b6Q42NB0w9BZPta7p9Iyr2Lw91cD5dszFL52DzV3FL0&s=p
> MGMapO3n9KVVxipezDC8cn2BvpY2xmJKq0T7p-Gt1E&e=
> >
> > I hesitated to post these, because a formatting error in one of the posts
> > makes me look a bit dumb. :-)
> >
> > 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.
> >
> > Honestly, I believe Linux will adopt its own FAQ or some similar document,
> > so with the Contributor Covenant adopting the clarification as a separate
> > document, I don't know if Linux would inherit it (ie include the Covenant
> > FAQ in our source tree).  However, I think that the existence of this email
> > clarification in the upstream FAQ would still have a beneficial effect for
> > all downstream users of the covenant, so I view this as a useful exercise.
> 
> The main argument I have heard against amending the code of conduct
> document
> itself is that a fork would make it more complicated for project members to
> understand the expectations, in a similar fashion than the fragmentation
> created by license forks. If we end up having our own FAQ, which would
> need to
> be considered in combination with the main document to understand its
> impact,
> doesn't that create the same problem ?

I'm not currently persuaded by the argument about modifying the CoC.
I see pros and cons, but 1) we have already changed the wording, and
2) I suspect that wording changes we adopt will not be that confusing
to rationalize with the upstream document, and 3) I don't think that
upstream will change so radically that it will be difficult for us to adopt.

So I guess a shorter way of putting this is that I'm not worried about a
fork.  The document is not long, and there should probably be debate
in the kernel community before adopting any significant upstream change
to the CoC. (similar to the debate and eventual rejection of GPL v3)

I have a similar opinion about a supporting FAQ.
 -- Tim

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

[Geert Uytterhoeven]

Hi Tim,

On Mon, Oct 8, 2018 at 4:12 PM <Tim.Bird@sony.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@linux-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

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

[Laurent Pinchart]

Hi Tim,

On Monday, 8 October 2018 17:12:05 EEST Tim.Bird@sony.com wrote:
> > -----Original Message-----
> > 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.
> 
> You can see the history of discussion in these two issues, online:
> https://github.com/ContributorCovenant/contributor_covenant/issues/590
> https://github.com/ContributorCovenant/contributor_covenant/issues/575
> 
> I hesitated to post these, because a formatting error in one of the posts
> makes me look a bit dumb. :-)
> 
> 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.
> 
> Honestly, I believe Linux will adopt its own FAQ or some similar document,
> so with the Contributor Covenant adopting the clarification as a separate
> document, I don't know if Linux would inherit it (ie include the Covenant
> FAQ in our source tree).  However, I think that the existence of this email
> clarification in the upstream FAQ would still have a beneficial effect for
> all downstream users of the covenant, so I view this as a useful exercise.

The main argument I have heard against amending the code of conduct document 
itself is that a fork would make it more complicated for project members to 
understand the expectations, in a similar fashion than the fragmentation 
created by license forks. If we end up having our own FAQ, which would need to 
be considered in combination with the main document to understand its impact, 
doesn't that create the same problem ?

-- 
Regards,

Laurent Pinchart

RE: [Ksummit-discuss] [PATCH] code-of-conduct: Remove explicit list of discrimination factors

[Tim.Bird]

> -----Original Message-----
> From: Josh Triplett
> 
> On Sun, Oct 07, 2018 at 08:18:26PM +0300, Laurent Pinchart wrote:
> > Hi Josh,
> >
> > 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.

You can see the history of discussion in these two issues, online:
https://github.com/ContributorCovenant/contributor_covenant/issues/590
https://github.com/ContributorCovenant/contributor_covenant/issues/575

I hesitated to post these, because a formatting error in one of the posts makes
me look a bit dumb. :-)

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.

Honestly, I believe Linux will adopt its own FAQ or some similar document, so with the
Contributor Covenant adopting the clarification as a separate document, I don't know
if Linux would inherit it (ie include the Covenant FAQ in our source tree).  However, I think
that the existence of this email clarification in the upstream FAQ would still have a
beneficial effect for all downstream users of the covenant, so I view this as a useful
exercise.

 -- Tim

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

On Sun, Oct 07, 2018 at 04:35:14AM -0700, 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.

The Debian code of conduct also omits the explicit list of factors.  In
their case it was a deliberate decision due to a real fear that people
involved in and adjacent to the project would try to rules lawyer an
explict list and wanting to make the code of conduct robust against
that.  The communities seem similar enough that it's worth thinking
about for the kernel as well, Debian has had to deal with some serious
problems in the past so there's some experience behind the decisions
there.

> In any case, this is not the appropriate place for such patches, any
> more than it's the place for patches to the GPL.

We do need some way to talk about what we're trying to do here.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Geert Uytterhoeven]

Hi Josh,

On Sun, Oct 7, 2018 at 1:35 PM Josh Triplett <josh@joshtriplett.org> 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

The first paragraph of the commit message (the "why" part) is exactly the
part we've been waiting for a clarification since the inception of the
commit...

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

Then (at least) the list should be marked containing examples, cfr. the other
examples in the document.

> In any case, this is not the appropriate place for such patches, any
> more than it's the place for patches to the GPL.

There are precedents:

Until recent, the file named "COPYING" (which you referred to in another
email related to patching the CoC), was a verbatim copy of the GPL, with
clarifications added at the top.

Documentation/process/code-of-conduct.rst is already a slightly modified
version of the original.

Now, if amending the CoC locally is not an option, I'm afraid a plain revert
is the only option, like for any other commit that breaks the userspace ABI
(Linux kernel developers are also users ;-), until the raised issues have
been resolved upstream.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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

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

[Josh Triplett]

On Sun, Oct 07, 2018 at 08:18:26PM +0300, Laurent Pinchart wrote:
> Hi Josh,
> 
> 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.

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

[Laurent Pinchart]

Hi Josh,

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 ? As stated 
in another e-mail in a similar thread, I believe we need to come together and 
decide on what we want to do. We still have no official forum to do so, and 
repeatedly telling people that ksummit-discuss and LKML are not the right 
place won't make the concerns go away. Only by discussing problems will we 
come to solutions.

-- 
Regards,

Laurent Pinchart

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

[Josh Triplett]

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.