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 <[email protected]>
---
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
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.
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
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.
Hi Josh,
On Sun, Oct 7, 2018 at 1:35 PM Josh Triplett <[email protected]> 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 -- [email protected]
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
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.
> -----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
Hi Tim,
On Monday, 8 October 2018 17:12:05 EEST [email protected] 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
Hi Tim,
On Mon, Oct 8, 2018 at 4:12 PM <[email protected]> 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 -- [email protected]
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
> -----Original Message-----
> From: Laurent Pinchart
>
> Hi Tim,
>
> On Monday, 8 October 2018 17:12:05 EEST [email protected] 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
> 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
On Mon, Oct 8, 2018 at 4:30 PM Geert Uytterhoeven <[email protected]> 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 -- [email protected]
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
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 .
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 <[email protected]>
> ---
> 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 <[email protected]>
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 <[email protected]>
> > ---
> > 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 <[email protected]>
Acked-by: Arnaldo Carvalho de Melo <[email protected]>
- Arnaldo
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.)
Josh Triplett <[email protected]>:
> > 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.
On 10/10/18 15:33, Eric S. Raymond wrote:
> Josh Triplett <[email protected]>:
>>> 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
On 07/10/18 11: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 <[email protected]>
> ---
> 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
> =============
Acked-by: Tomi Valkeinen <[email protected]>
Tomi
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