Resend to show accumulated tags and also to add a third patch listing
the TAB as the reporting point as a few people seem to want. If it
gets the same level of support, I'll send it in with the other two.
---
Previous cover letter:
We've had several threads discussing potential changes to the code of
conduct but Mauro is the only person to have proposed an actual patch.
In order to move the debate on, I'm presenting two patches, one to fix
the email problem Mauro identified and the other to strip the
enforcement section pending community discussion as Shuah suggested.
I'll take responsibility for collecting any tags people want to add
(review/ack/sign off, etc) and sending the patch in as a signed pull
request before 4.19 final if they get enough community support.
Note, I've sent both patches in as a series to facilitate review and
discussion, but they are separable if one is looked on with less favour
than the other.
It was also a bit unclear which list to send this to, but I finally
settled on linux-kernel as the catch all and ksummit-discuss since
that's where most of the current discussion is. I can add other lists
as people suggest them.
James
---
James Bottomley (3):
code-of-conduct: Fix the ambiguity about collecting email addresses
code-of-conduct: Strip the enforcement paragraph pending community
discussion
code-of-conduct: Add back the TAB as the central reporting point
Documentation/process/code-of-conduct.rst | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
--
2.13.7
The current code of conduct has an ambiguity in the it considers publishing
private information such as email addresses unacceptable behaviour. Since
the Linux kernel collects and publishes email addresses as part of the patch
process, add an exception clause for email addresses ordinarily collected by
the project to correct this ambiguity.
Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
Acked-by: Geert Uytterhoeven <[email protected]>
Acked-by: Shuah Khan <[email protected]>
Acked-by: Guenter Roeck <[email protected]>
Reviewed-by: Alan Cox <[email protected]>
Reviewed-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
---
Documentation/process/code-of-conduct.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
index ab7c24b5478c..aa40e34e7785 100644
--- a/Documentation/process/code-of-conduct.rst
+++ b/Documentation/process/code-of-conduct.rst
@@ -31,7 +31,7 @@ Examples of unacceptable behavior by participants include:
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others’ private information, such as a physical or electronic
- address, without explicit permission
+ address not ordinarily collected by the project, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
--
2.13.7
Add a Reporting section where the Enforcement section used to be. The
intention is still to debate what should go here, but in the meantime, this
gives us back the central reporting point we had in the old code of conflict.
Signed-off-by: James Bottomley <[email protected]>
---
v2: Added this patch to allay concerns we were stripping the reporting
mechanism entirely.
---
Documentation/process/code-of-conduct.rst | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
index 4dd90987305b..2000bdc2a6ad 100644
--- a/Documentation/process/code-of-conduct.rst
+++ b/Documentation/process/code-of-conduct.rst
@@ -59,6 +59,16 @@ address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.
+Reporting
+=========
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the Technical Advisory Board (TAB) at
+<[email protected]>. All complaints will be reviewed and
+investigated and will result in a response that is deemed necessary and
+appropriate to the circumstances. The TAB is obligated to maintain
+confidentiality with regard to the reporter of an incident.
+
Attribution
===========
--
2.13.7
Significant concern has been expressed about the responsibilities outlined in
the enforcement clause of the new code of conduct. Since there is concern
that this becomes binding on the release of the 4.19 kernel, strip the
enforcement clauses to give the community time to consider and debate how this
should be handled.
Note, this patch is expected to be the starting point for a discussion not the
end point, so there is an expectation that an Enforcement section will be
added again to our code of conduct once we have sufficient community consensus
on what it should say.
Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
Acked-by: Shuah Khan <[email protected]>
Acked-by: Guenter Roeck <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Alan Cox <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
---
v2: Added additional commit paragraph clarifying we do expect eventually to
have an enforcement section (as requested by Shuah)
---
Documentation/process/code-of-conduct.rst | 15 ---------------
1 file changed, 15 deletions(-)
diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
index aa40e34e7785..4dd90987305b 100644
--- a/Documentation/process/code-of-conduct.rst
+++ b/Documentation/process/code-of-conduct.rst
@@ -59,21 +59,6 @@ address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.
-Enforcement
-===========
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the Technical Advisory Board (TAB) at
-<[email protected]>. All complaints will be reviewed and
-investigated and will result in a response that is deemed necessary and
-appropriate to the circumstances. The TAB is obligated to maintain
-confidentiality with regard to the reporter of an incident. Further details of
-specific enforcement policies may be posted separately.
-
-Maintainers who do not follow or enforce the Code of Conduct in good faith may
-face temporary or permanent repercussions as determined by other members of the
-project’s leadership.
-
Attribution
===========
--
2.13.7
On Wed, 10 Oct 2018 13:10:30 -0700
> +appropriate to the circumstances. The TAB is obligated to maintain
> +confidentiality with regard to the reporter of an incident.
I would add (except where required by law.)
Alan
> the enforcement clause of the new code of conduct. Since there is concern
> that this becomes binding on the release of the 4.19 kernel
Is there some logic behind that concern? What's magic about the release
of 4.19?
Our benevolent dictator committed that patch. Didn't it take effect
as soon as he ran "git push" to make it visible to the world?
-Tony
On Wed, Oct 10, 2018 at 01:10:30PM -0700, James Bottomley wrote:
> Add a Reporting section where the Enforcement section used to be. The
> intention is still to debate what should go here, but in the meantime, this
> gives us back the central reporting point we had in the old code of conflict.
>
Reviewed-by: Konrad Rzeszutek Wilk <[email protected]>
Thank you!
> Signed-off-by: James Bottomley <[email protected]>
>
> ---
>
> v2: Added this patch to allay concerns we were stripping the reporting
> mechanism entirely.
> ---
> Documentation/process/code-of-conduct.rst | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
> index 4dd90987305b..2000bdc2a6ad 100644
> --- a/Documentation/process/code-of-conduct.rst
> +++ b/Documentation/process/code-of-conduct.rst
> @@ -59,6 +59,16 @@ address, posting via an official social media account, or acting as an appointed
> representative at an online or offline event. Representation of a project may be
> further defined and clarified by project maintainers.
>
> +Reporting
> +=========
> +
> +Instances of abusive, harassing, or otherwise unacceptable behavior may be
> +reported by contacting the Technical Advisory Board (TAB) at
> +<[email protected]>. All complaints will be reviewed and
> +investigated and will result in a response that is deemed necessary and
> +appropriate to the circumstances. The TAB is obligated to maintain
> +confidentiality with regard to the reporter of an incident.
> +
> Attribution
> ===========
>
> --
> 2.13.7
>
On Wed, 2018-10-10 at 21:04 +0000, Luck, Tony wrote:
> > the enforcement clause of the new code of conduct. Since there is
> > concern that this becomes binding on the release of the 4.19 kernel
>
> Is there some logic behind that concern?
Well, yes, Linux as a project goes through numbered releases, so
releases are the usual official points we try to stop changing stuff,
so if we want to reset the expectation the committed CoC is final,
doing it before the release is helpful.
> What's magic about the release of 4.19?
It's the first one after the CoC change.
> Our benevolent dictator committed that patch. Didn't it take effect
> as soon as he ran "git push" to make it visible to the world
Not usually: people usually have to agree to a change like this. Of
course "agree" is a variable concept and can be as simple as not object
by a certain time or by using certain infrastructure.
James
> Not usually: people usually have to agree to a change like this. Of
> course "agree" is a variable concept and can be as simple as not object
> by a certain time or by using certain infrastructure.
Perhaps you should review the meaning of the word "dictator". :-)
-Tony
James Bottomley <[email protected]> writes:
> The current code of conduct has an ambiguity in the it considers publishing
> private information such as email addresses unacceptable behaviour. Since
> the Linux kernel collects and publishes email addresses as part of the patch
> process, add an exception clause for email addresses ordinarily collected by
> the project to correct this ambiguity.
Acked-by: "Eric W. Biederman" <[email protected]>
>
> Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
> Acked-by: Geert Uytterhoeven <[email protected]>
> Acked-by: Shuah Khan <[email protected]>
> Acked-by: Guenter Roeck <[email protected]>
> Reviewed-by: Alan Cox <[email protected]>
> Reviewed-by: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: James Bottomley <[email protected]>
> ---
> Documentation/process/code-of-conduct.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
> index ab7c24b5478c..aa40e34e7785 100644
> --- a/Documentation/process/code-of-conduct.rst
> +++ b/Documentation/process/code-of-conduct.rst
> @@ -31,7 +31,7 @@ Examples of unacceptable behavior by participants include:
> * Trolling, insulting/derogatory comments, and personal or political attacks
> * Public or private harassment
> * Publishing others’ private information, such as a physical or electronic
> - address, without explicit permission
> + address not ordinarily collected by the project, without explicit permission
> * Other conduct which could reasonably be considered inappropriate in a
> professional setting
James Bottomley <[email protected]> writes:
> Resend to show accumulated tags and also to add a third patch listing
> the TAB as the reporting point as a few people seem to want. If it
> gets the same level of support, I'll send it in with the other two.
There is also:
> Our Responsibilities
> ====================
>
> Maintainers are responsible for clarifying the standards of acceptable behavior
> and are expected to take appropriate and fair corrective action in response to
> any instances of unacceptable behavior.
>
> Maintainers have the right and responsibility to remove, edit, or reject
> comments, commits, code, wiki edits, issues, and other contributions that are
> not aligned to this Code of Conduct, or to ban temporarily or permanently any
> contributor for other behaviors that they deem inappropriate, threatening,
> offensive, or harmful.
Which is very problematic.
a) In append only logs like git we can not edit history.
Making it a mainters responsibility to edit the history, to do the
impossible is a problem.
b) There are no responsibilities of for people who are not Maintainers.
That is another problem.
c) The entire tone of the reponsibilities section is out of line with a
community where there are no enforcement powers only the power to
accept or not accept a patch. Only the power to persuade not to
enforce.
Overall in the discussions I have heard people talking about persuading,
educating, and not feeding trolls. Nowhere have I heard people talking
about policing the community which I understand that responsiblity
section to be talking about.
Increasingly I am getting the feeling that this document does not the
linux development community. Perhaps a revert and trying to come up
with better language from scratch would be better.
I don't know how to rephrase that reponsibility section but if we don't
go with the revert something looks like it need sot be done there.
Eric
On Wed, Oct 10, 2018 at 06:23:24PM -0500, Eric W. Biederman wrote:
> Which is very problematic.
> a) In append only logs like git we can not edit history.
> Making it a mainters responsibility to edit the history, to do the
> impossible is a problem.
>
> b) There are no responsibilities of for people who are not Maintainers.
> That is another problem.
>
> c) The entire tone of the reponsibilities section is out of line with a
> community where there are no enforcement powers only the power to
> accept or not accept a patch. Only the power to persuade not to
> enforce.
d) In effect, it either leaves the maillists exempt, or, if they are
not as would seem to be the intent, dumps physically unsustainable
load on somebody (davem, by default, for vger-based lists).
And anyone who wants to claim that moderating l-k, l-scsi, fsdevel,
etc., etc. is *not* physically unsustainable is welcome to try.
Just make sure that your insurance covers the psychiatric care you
are certain to need afterwards.
> Overall in the discussions I have heard people talking about persuading,
> educating, and not feeding trolls. Nowhere have I heard people talking
> about policing the community which I understand that responsiblity
> section to be talking about.
>
> Increasingly I am getting the feeling that this document does not the
> linux development community.
Quite. Not the use of open maillists, not the amount of trees and the
depth of pull chains, not the size of community, not the cross-area work...
Frankly, it reminds me of "well, if everyone had only switched to one true
revision control system and used the one true integrated IDE with this nifty
set of plugins..." kind of proposals. Good for you if it works for your
workflow, but forget about having everyone else switch to it.
On Wed, 2018-10-10 at 18:23 -0500, Eric W. Biederman wrote:
> James Bottomley <[email protected]> writes:
>
> > Resend to show accumulated tags and also to add a third patch
> > listing the TAB as the reporting point as a few people seem to
> > want. If it gets the same level of support, I'll send it in with
> > the other two.
>
>
> There is also:
>
> > Our Responsibilities
> > ====================
> >
> > Maintainers are responsible for clarifying the standards of
> > acceptable behavior and are expected to take appropriate and fair
> > corrective action in response to any instances of unacceptable
> > behavior.
> >
> > Maintainers have the right and responsibility to remove, edit, or
> > reject comments, commits, code, wiki edits, issues, and other
> > contributions that are not aligned to this Code of Conduct, or to
> > ban temporarily or permanently any contributor for other behaviors
> > that they deem inappropriate, threatening, offensive, or harmful.
>
> Which is very problematic.
> a) In append only logs like git we can not edit history.
> Making it a mainters responsibility to edit the history, to do the
> impossible is a problem.
Git isn't entirely append only. We can do limited history changes by
rebasing. Some trees do that quite a lot. Github has this same
history problem, so certainly we could amend commits before they hit
Linus' tree but after that it isn't "fair corrective action" because it
can't be done technically.
> b) There are no responsibilities of for people who are not
> Maintainers.
> That is another problem.
Yes, I don't disagree with this. It's one of the huge problems with
this whole CoC thing: in a community which has apparent leaders but no
real power structure, conforming to a CoC becomes everyone's
responsibility not just the maintainers.
> c) The entire tone of the reponsibilities section is out of line with
> a
> community where there are no enforcement powers only the power to
> accept or not accept a patch. Only the power to persuade not to
> enforce.
Persuasion and Leadership go hand in hand. I agree there's no backing
power to compel, but persuasive leaders are still not powerless.
There's always potentially an outlier who simply won't listen and won't
be persuaded, but they're usually not members of the community either
...
> Overall in the discussions I have heard people talking about
> persuading, educating, and not feeding trolls. Nowhere have I heard
> people talking about policing the community which I understand that
> responsiblity section to be talking about.
Policing is the wrong word: no-one has policing power. However, we
still have persuasive power. The point is there's a reasonable line
you can tread as a persuader. Some very few people simply won't
listen, but we have, actually, excluded them before without a code of
conduct.
> Increasingly I am getting the feeling that this document does not the
> linux development community. Perhaps a revert and trying to come up
> with better language from scratch would be better.
I'm open to pushing a revert instead. However, I think this one is
workable too if interpreted reasonably.
> I don't know how to rephrase that reponsibility section but if we
> don't go with the revert something looks like it need sot be done
> there.
That is an argument for keeping what we have ... these things are
difficult to write.
James
Em Wed, 10 Oct 2018 21:13:13 +0100
Alan Cox <[email protected]> escreveu:
> On Wed, 10 Oct 2018 13:10:30 -0700
> > +appropriate to the circumstances. The TAB is obligated to maintain
> > +confidentiality with regard to the reporter of an incident.
>
> I would add (except where required by law.)
With the proposed change by Alan, you can add my:
Reviewed-by: Mauro Carvalho Chehab <[email protected]>
Thanks,
Mauro
Em Wed, 10 Oct 2018 13:08:35 -0700
James Bottomley <[email protected]> escreveu:
> The current code of conduct has an ambiguity in the it considers publishing
> private information such as email addresses unacceptable behaviour. Since
> the Linux kernel collects and publishes email addresses as part of the patch
> process, add an exception clause for email addresses ordinarily collected by
> the project to correct this ambiguity.
>
> Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
> Acked-by: Geert Uytterhoeven <[email protected]>
> Acked-by: Shuah Khan <[email protected]>
> Acked-by: Guenter Roeck <[email protected]>
> Reviewed-by: Alan Cox <[email protected]>
> Reviewed-by: Mauro Carvalho Chehab <[email protected]>
In time, please change my reviewed by to:
Reviewed-by: Mauro Carvalho Chehab <[email protected]>
As I'm speaking for myself, not for my employer.
> Signed-off-by: James Bottomley <[email protected]>
> ---
> Documentation/process/code-of-conduct.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
> index ab7c24b5478c..aa40e34e7785 100644
> --- a/Documentation/process/code-of-conduct.rst
> +++ b/Documentation/process/code-of-conduct.rst
> @@ -31,7 +31,7 @@ Examples of unacceptable behavior by participants include:
> * Trolling, insulting/derogatory comments, and personal or political attacks
> * Public or private harassment
> * Publishing others’ private information, such as a physical or electronic
> - address, without explicit permission
> + address not ordinarily collected by the project, without explicit permission
> * Other conduct which could reasonably be considered inappropriate in a
> professional setting
>
Thanks,
Mauro
Em Wed, 10 Oct 2018 13:09:40 -0700
James Bottomley <[email protected]> escreveu:
> Significant concern has been expressed about the responsibilities outlined in
> the enforcement clause of the new code of conduct. Since there is concern
> that this becomes binding on the release of the 4.19 kernel, strip the
> enforcement clauses to give the community time to consider and debate how this
> should be handled.
>
> Note, this patch is expected to be the starting point for a discussion not the
> end point, so there is an expectation that an Enforcement section will be
> added again to our code of conduct once we have sufficient community consensus
> on what it should say.
>
> Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
> Acked-by: Shuah Khan <[email protected]>
> Acked-by: Guenter Roeck <[email protected]>
> Acked-by: Geert Uytterhoeven <[email protected]>
> Reviewed-by: Alan Cox <[email protected]>
> Signed-off-by: James Bottomley <[email protected]>
Reviewed-by: Mauro Carvalho Chehab <[email protected]>
I still think that this series should contain a 4th patch removing
"responsibilities" with that text proposed by Alan.
E. g. instead of:
Maintainers have the right and responsibility to remove, edit, or reject
it should say, instead:
Maintainers should remove, edit or reject
>
> ---
>
> v2: Added additional commit paragraph clarifying we do expect eventually to
> have an enforcement section (as requested by Shuah)
> ---
> Documentation/process/code-of-conduct.rst | 15 ---------------
> 1 file changed, 15 deletions(-)
>
> diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
> index aa40e34e7785..4dd90987305b 100644
> --- a/Documentation/process/code-of-conduct.rst
> +++ b/Documentation/process/code-of-conduct.rst
> @@ -59,21 +59,6 @@ address, posting via an official social media account, or acting as an appointed
> representative at an online or offline event. Representation of a project may be
> further defined and clarified by project maintainers.
>
> -Enforcement
> -===========
> -
> -Instances of abusive, harassing, or otherwise unacceptable behavior may be
> -reported by contacting the Technical Advisory Board (TAB) at
> -<[email protected]>. All complaints will be reviewed and
> -investigated and will result in a response that is deemed necessary and
> -appropriate to the circumstances. The TAB is obligated to maintain
> -confidentiality with regard to the reporter of an incident. Further details of
> -specific enforcement policies may be posted separately.
> -
> -Maintainers who do not follow or enforce the Code of Conduct in good faith may
> -face temporary or permanent repercussions as determined by other members of the
> -project’s leadership.
> -
> Attribution
> ===========
>
Thanks,
Mauro
Em Wed, 10 Oct 2018 17:00:01 -0700
James Bottomley <[email protected]> escreveu:
> On Wed, 2018-10-10 at 18:23 -0500, Eric W. Biederman wrote:
> > James Bottomley <[email protected]> writes:
> >
> > > Resend to show accumulated tags and also to add a third patch
> > > listing the TAB as the reporting point as a few people seem to
> > > want. If it gets the same level of support, I'll send it in with
> > > the other two.
> >
> >
> > There is also:
> >
> > > Our Responsibilities
> > > ====================
> > >
> > > Maintainers are responsible for clarifying the standards of
> > > acceptable behavior and are expected to take appropriate and fair
> > > corrective action in response to any instances of unacceptable
> > > behavior.
> > >
> > > Maintainers have the right and responsibility to remove, edit, or
> > > reject comments, commits, code, wiki edits, issues, and other
> > > contributions that are not aligned to this Code of Conduct, or to
> > > ban temporarily or permanently any contributor for other behaviors
> > > that they deem inappropriate, threatening, offensive, or harmful.
> >
> > Which is very problematic.
> > a) In append only logs like git we can not edit history.
> > Making it a mainters responsibility to edit the history, to do the
> > impossible is a problem.
>
> Git isn't entirely append only. We can do limited history changes by
> rebasing. Some trees do that quite a lot. Github has this same
> history problem, so certainly we could amend commits before they hit
> Linus' tree but after that it isn't "fair corrective action" because it
> can't be done technically.
We should discuss more about this during MS/KS. Even before pushing upstream,
it is a problem on some subsytems, as sub-maintainers and driver developers
may have issues with rebases.
I'm sure maintainers will do rebases if they think it is worth enough,
provided that it won't break things, but rebases should be the exception,
not the rule.
So, I would add on a FAQ (or at the CoC itself) that maintainers won't
do git rebases due to CoC. So, people complaining about CoC violations
inside patches should reply ASAP, in order for the maintainer to be
able to see it *before* merging the patch on his tree.
> > Overall in the discussions I have heard people talking about
> > persuading, educating, and not feeding trolls. Nowhere have I heard
> > people talking about policing the community which I understand that
> > responsiblity section to be talking about.
>
> Policing is the wrong word: no-one has policing power. However, we
> still have persuasive power. The point is there's a reasonable line
> you can tread as a persuader. Some very few people simply won't
> listen, but we have, actually, excluded them before without a code of
> conduct.
Yes, but this particular CoC assumes that maintainer has policing power.
This needs to be reviewed. For now, I would get rid of
"have the right and responsibility"
in favor of something lighter:
"should"
Later we may need something else.
>
> > Increasingly I am getting the feeling that this document does not the
> > linux development community. Perhaps a revert and trying to come up
> > with better language from scratch would be better.
>
> I'm open to pushing a revert instead. However, I think this one is
> workable too if interpreted reasonably.
Agreed.
> > I don't know how to rephrase that reponsibility section but if we
> > don't go with the revert something looks like it need sot be done
> > there.
>
> That is an argument for keeping what we have ... these things are
> difficult to write.
A simple change like the above (plus this /3 patch series) should work for
now, but, IMHO, this CoC model is too bound to a centralized web-based
site-hosted development model, lacking ways for it to work with
de-centralized e-mail based workflows.
For next Kernels, we may need to either replace it by something else
or do more changes on it, in order for it to make sense with our
workflow.
Thanks,
Mauro
On 10/10/18 23:07, James Bottomley wrote:
> Resend to show accumulated tags and also to add a third patch listing
> the TAB as the reporting point as a few people seem to want. If it
> gets the same level of support, I'll send it in with the other two.
>
> ---
>
> Previous cover letter:
>
>
> We've had several threads discussing potential changes to the code of
> conduct but Mauro is the only person to have proposed an actual patch.
> In order to move the debate on, I'm presenting two patches, one to fix
> the email problem Mauro identified and the other to strip the
> enforcement section pending community discussion as Shuah suggested.
>
> I'll take responsibility for collecting any tags people want to add
> (review/ack/sign off, etc) and sending the patch in as a signed pull
> request before 4.19 final if they get enough community support.
>
> Note, I've sent both patches in as a series to facilitate review and
> discussion, but they are separable if one is looked on with less favour
> than the other.
>
> It was also a bit unclear which list to send this to, but I finally
> settled on linux-kernel as the catch all and ksummit-discuss since
> that's where most of the current discussion is. I can add other lists
> as people suggest them.
>
> James
>
> ---
>
> James Bottomley (3):
> code-of-conduct: Fix the ambiguity about collecting email addresses
> code-of-conduct: Strip the enforcement paragraph pending community
> discussion
> code-of-conduct: Add back the TAB as the central reporting point
>
> Documentation/process/code-of-conduct.rst | 13 ++++---------
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
For the three patches (preferably with Alan's "except where required by
law"):
Acked-by: Tomi Valkeinen <[email protected]>
Although I think reverting 8a104f8b5867c682 is the best option.
Tomi
On Wed, Oct 10, 2018 at 10:14 PM Alan Cox <[email protected]> wrote:
> On Wed, 10 Oct 2018 13:10:30 -0700
> > +appropriate to the circumstances. The TAB is obligated to maintain
> > +confidentiality with regard to the reporter of an incident.
>
> I would add (except where required by law.)
With the above change:
Acked-by: Geert Uytterhoeven <[email protected]>
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
Am Mittwoch, 10. Oktober 2018, 18:23:24 schrieb Eric W. Biederman:
> James Bottomley <[email protected]> writes:
>
> > Resend to show accumulated tags and also to add a third patch listing
> > the TAB as the reporting point as a few people seem to want. If it
> > gets the same level of support, I'll send it in with the other two.
>
>
> There is also:
>
> > Our Responsibilities
> > ====================
> >
> > Maintainers are responsible for clarifying the standards of acceptable behavior
> > and are expected to take appropriate and fair corrective action in response to
> > any instances of unacceptable behavior.
> >
> > Maintainers have the right and responsibility to remove, edit, or reject
> > comments, commits, code, wiki edits, issues, and other contributions that are
> > not aligned to this Code of Conduct, or to ban temporarily or permanently any
> > contributor for other behaviors that they deem inappropriate, threatening,
> > offensive, or harmful.
>
> Which is very problematic.
> a) In append only logs like git we can not edit history.
> Making it a mainters responsibility to edit the history, to do the
> impossible is a problem.
>
> b) There are no responsibilities of for people who are not Maintainers.
> That is another problem.
>
As a reminder/clarification one could introduce a line like this:
Responsibilities
================
All participants are responsible for complying with this Code of Conduct.
Maintainers are responsible for[...]
> c) The entire tone of the reponsibilities section is out of line with a
> community where there are no enforcement powers only the power to
> accept or not accept a patch. Only the power to persuade not to
> enforce.
>
> Overall in the discussions I have heard people talking about persuading,
> educating, and not feeding trolls. Nowhere have I heard people talking
> about policing the community which I understand that responsiblity
> section to be talking about.
>
I think Eward Cree aired this concerns early on in the discussion:
https://lkml.org/lkml/2018/9/19/234
> Increasingly I am getting the feeling that this document does not the
> linux development community. Perhaps a revert and trying to come up
> with better language from scratch would be better.
[...]
+1.
Nobody would get hurt or loose face by doing so. On the contrary.
My suggestion would be:
- revert the patch
- discuss the matter (and the way it was introduced) at least at the next MS
- setup a task-force to come up with a new proposal
- discuss the proposal
- make corrections, if necessary
- implement it
IMO there's no need to rush things in a matter so important for the future
of the project.
So long!
Rainer Fiebig
--
The truth always turns out to be simpler than you thought.
Richard Feynman
On Wed, Oct 10, 2018 at 1:08 PM, James Bottomley
<[email protected]> wrote:
> The current code of conduct has an ambiguity in the it considers publishing
> private information such as email addresses unacceptable behaviour. Since
> the Linux kernel collects and publishes email addresses as part of the patch
> process, add an exception clause for email addresses ordinarily collected by
> the project to correct this ambiguity.
>
> Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
> Acked-by: Geert Uytterhoeven <[email protected]>
> Acked-by: Shuah Khan <[email protected]>
> Acked-by: Guenter Roeck <[email protected]>
> Reviewed-by: Alan Cox <[email protected]>
> Reviewed-by: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: James Bottomley <[email protected]>
Acked-by: Kees Cook <[email protected]>
-Kees
> ---
> Documentation/process/code-of-conduct.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
> index ab7c24b5478c..aa40e34e7785 100644
> --- a/Documentation/process/code-of-conduct.rst
> +++ b/Documentation/process/code-of-conduct.rst
> @@ -31,7 +31,7 @@ Examples of unacceptable behavior by participants include:
> * Trolling, insulting/derogatory comments, and personal or political attacks
> * Public or private harassment
> * Publishing others’ private information, such as a physical or electronic
> - address, without explicit permission
> + address not ordinarily collected by the project, without explicit permission
> * Other conduct which could reasonably be considered inappropriate in a
> professional setting
>
> --
> 2.13.7
>
--
Kees Cook
Pixel Security
On Wed, Oct 10, 2018 at 2:04 PM, Luck, Tony <[email protected]> wrote:
>> the enforcement clause of the new code of conduct. Since there is concern
>> that this becomes binding on the release of the 4.19 kernel
>
> Is there some logic behind that concern? What's magic about the release
> of 4.19?
Greg KH said 4.19 was going to be the next LTS. But, regardless, if we
view bugs in the CoC as "just bugs", then can't we also include their
fixes in -stable? It'll land in 4.19.z just like anything else. I
don't think we need to rush anything into 4.19 -- as so many others
have said: it's in our best interest to take the time to get the CoC
right.
-Kees
--
Kees Cook
Pixel Security