Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
On Mon, Oct 08, 2018 at 04:37:48PM +0100, Alan Cox wrote: > > > I happen to think that the fact that the TAB cannot compel where it > > cannot persuade is a huge strength of the system because it means > > there's no power structure to subvert if someone were interested in > > using it to try to impose their own viewpoint on the community. But > > that's just my opinion and I did write the TAB charter, so I'm probably > > biased in this viewpoint. > > The TAB can't handle it anyway because the privacy promise about > reporting is incompatible with reality for three reasons (and I bet there > are more) Really you want to keep any reporting private from people on the TAB because they're going to be interviewing you for a job in a couple years. regards, dan carpenter
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
On Mon, Oct 08, 2018 at 04:37:48PM +0100, Alan Cox wrote: > > > I happen to think that the fact that the TAB cannot compel where it > > cannot persuade is a huge strength of the system because it means > > there's no power structure to subvert if someone were interested in > > using it to try to impose their own viewpoint on the community. But > > that's just my opinion and I did write the TAB charter, so I'm probably > > biased in this viewpoint. > > The TAB can't handle it anyway because the privacy promise about > reporting is incompatible with reality for three reasons (and I bet there > are more) Really you want to keep any reporting private from people on the TAB because they're going to be interviewing you for a job in a couple years. regards, dan carpenter
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
Em Wed, 10 Oct 2018 21:09:48 +0100 Alan Cox escreveu: > On Wed, 10 Oct 2018 14:19:17 -0300 > Mauro Carvalho Chehab wrote: > > > Em Wed, 10 Oct 2018 16:53:08 +0100 > > Alan Cox escreveu: > > > > > > -Maintainers have the right and responsibility to remove, edit, or > > > > reject > > > > +Maintainers may 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, > > > > > > > > The previous text seems too much legal for my taste. > > > > > > > > > > That is just as confusing. Maintainers have the right to remove, edit, > > > reject commits that *are* aligned with the code as well. > > > > Good point. Yeah, a maintainer can do whatever he thinks it is > > appropriate for a patch - even when it follows the CoC. > > > > > So what exactly is the point here ? > > > > The point is "responsibility" - that sounds like it is bounding a legal > > duty to a maintainer. > > If you remove the responsibility aspect you might as well remove the > entire clause. It doesn't say anything as it's simply a subset of what > maintainers do anyway. > > So how about > > "Maintainers should remove, edit or reject..." > > that keeps the sense that there should be pressure against abusive > behaviour. Works for me. > except of course someone will attach a zero day exploit and fix to a > coc-violating rant and then you are a bit stuffed 8) :-) Thanks, Mauro
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
Em Wed, 10 Oct 2018 21:09:48 +0100 Alan Cox escreveu: > On Wed, 10 Oct 2018 14:19:17 -0300 > Mauro Carvalho Chehab wrote: > > > Em Wed, 10 Oct 2018 16:53:08 +0100 > > Alan Cox escreveu: > > > > > > -Maintainers have the right and responsibility to remove, edit, or > > > > reject > > > > +Maintainers may 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, > > > > > > > > The previous text seems too much legal for my taste. > > > > > > > > > > That is just as confusing. Maintainers have the right to remove, edit, > > > reject commits that *are* aligned with the code as well. > > > > Good point. Yeah, a maintainer can do whatever he thinks it is > > appropriate for a patch - even when it follows the CoC. > > > > > So what exactly is the point here ? > > > > The point is "responsibility" - that sounds like it is bounding a legal > > duty to a maintainer. > > If you remove the responsibility aspect you might as well remove the > entire clause. It doesn't say anything as it's simply a subset of what > maintainers do anyway. > > So how about > > "Maintainers should remove, edit or reject..." > > that keeps the sense that there should be pressure against abusive > behaviour. Works for me. > except of course someone will attach a zero day exploit and fix to a > coc-violating rant and then you are a bit stuffed 8) :-) Thanks, Mauro
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
On Wed, 10 Oct 2018 14:19:17 -0300 Mauro Carvalho Chehab wrote: > Em Wed, 10 Oct 2018 16:53:08 +0100 > Alan Cox escreveu: > > > > -Maintainers have the right and responsibility to remove, edit, or reject > > > +Maintainers may 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, > > > > > > The previous text seems too much legal for my taste. > > > > > > > That is just as confusing. Maintainers have the right to remove, edit, > > reject commits that *are* aligned with the code as well. > > Good point. Yeah, a maintainer can do whatever he thinks it is > appropriate for a patch - even when it follows the CoC. > > > So what exactly is the point here ? > > The point is "responsibility" - that sounds like it is bounding a legal > duty to a maintainer. If you remove the responsibility aspect you might as well remove the entire clause. It doesn't say anything as it's simply a subset of what maintainers do anyway. So how about "Maintainers should remove, edit or reject..." that keeps the sense that there should be pressure against abusive behaviour. except of course someone will attach a zero day exploit and fix to a coc-violating rant and then you are a bit stuffed 8) Alan
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
On Wed, 10 Oct 2018 14:19:17 -0300 Mauro Carvalho Chehab wrote: > Em Wed, 10 Oct 2018 16:53:08 +0100 > Alan Cox escreveu: > > > > -Maintainers have the right and responsibility to remove, edit, or reject > > > +Maintainers may 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, > > > > > > The previous text seems too much legal for my taste. > > > > > > > That is just as confusing. Maintainers have the right to remove, edit, > > reject commits that *are* aligned with the code as well. > > Good point. Yeah, a maintainer can do whatever he thinks it is > appropriate for a patch - even when it follows the CoC. > > > So what exactly is the point here ? > > The point is "responsibility" - that sounds like it is bounding a legal > duty to a maintainer. If you remove the responsibility aspect you might as well remove the entire clause. It doesn't say anything as it's simply a subset of what maintainers do anyway. So how about "Maintainers should remove, edit or reject..." that keeps the sense that there should be pressure against abusive behaviour. except of course someone will attach a zero day exploit and fix to a coc-violating rant and then you are a bit stuffed 8) Alan
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
Em Wed, 10 Oct 2018 16:53:08 +0100 Alan Cox escreveu: > > -Maintainers have the right and responsibility to remove, edit, or reject > > +Maintainers may 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, > > > > The previous text seems too much legal for my taste. > > > > That is just as confusing. Maintainers have the right to remove, edit, > reject commits that *are* aligned with the code as well. Good point. Yeah, a maintainer can do whatever he thinks it is appropriate for a patch - even when it follows the CoC. > So what exactly is the point here ? The point is "responsibility" - that sounds like it is bounding a legal duty to a maintainer. While this makes sense for Github (as the company doesn't want to be responsible for sanitizing every single post), this doesn't work for e-mail based workflow, where the message is stored on a distributed way, as a maintainer can't "remove, edit or reject" an e-mail. Thanks, Mauro
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
Em Wed, 10 Oct 2018 16:53:08 +0100 Alan Cox escreveu: > > -Maintainers have the right and responsibility to remove, edit, or reject > > +Maintainers may 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, > > > > The previous text seems too much legal for my taste. > > > > That is just as confusing. Maintainers have the right to remove, edit, > reject commits that *are* aligned with the code as well. Good point. Yeah, a maintainer can do whatever he thinks it is appropriate for a patch - even when it follows the CoC. > So what exactly is the point here ? The point is "responsibility" - that sounds like it is bounding a legal duty to a maintainer. While this makes sense for Github (as the company doesn't want to be responsible for sanitizing every single post), this doesn't work for e-mail based workflow, where the message is stored on a distributed way, as a maintainer can't "remove, edit or reject" an e-mail. Thanks, Mauro
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
> -Maintainers have the right and responsibility to remove, edit, or reject > +Maintainers may 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, > > The previous text seems too much legal for my taste. > That is just as confusing. Maintainers have the right to remove, edit, reject commits that *are* aligned with the code as well. So what exactly is the point here ? Alan
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
> -Maintainers have the right and responsibility to remove, edit, or reject > +Maintainers may 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, > > The previous text seems too much legal for my taste. > That is just as confusing. Maintainers have the right to remove, edit, reject commits that *are* aligned with the code as well. So what exactly is the point here ? Alan
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
Em Sat, 06 Oct 2018 14:37:31 -0700 James Bottomley 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. > > Signed-off-by: James Bottomley With my maintainer's hat, my main concern would be solved with this hunk: diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst index ab7c24b5478c..f07d51129d4b 100644 --- a/Documentation/process/code-of-conduct.rst +++ b/Documentation/process/code-of-conduct.rst @@ -43,7 +43,7 @@ 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 +Maintainers may 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, The previous text seems too much legal for my taste. > --- > 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 > -. 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 > === After looking at the comments, I would just keep TAB as a point of contact for CoC violations: diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst index ab7c24b5478c..fa908dbff51c 100644 --- a/Documentation/process/code-of-conduct.rst +++ b/Documentation/process/code-of-conduct.rst @@ -59,20 +59,12 @@ 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 -=== +Reports +=== Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the Technical Advisory Board (TAB) at -. 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 === Keeping the rest implicit. This can be revisited after having more discussions. Thanks, Mauro - Both hunks are shown below. diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst index ab7c24b5478c..df44867a2db5 100644 --- a/Documentation/process/code-of-conduct.rst +++ b/Documentation/process/code-of-conduct.rst @@ -43,7 +43,7 @@ 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 +Maintainers may 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, @@ -59,20 +59,12 @@ address, posting via an
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
Em Sat, 06 Oct 2018 14:37:31 -0700 James Bottomley 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. > > Signed-off-by: James Bottomley With my maintainer's hat, my main concern would be solved with this hunk: diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst index ab7c24b5478c..f07d51129d4b 100644 --- a/Documentation/process/code-of-conduct.rst +++ b/Documentation/process/code-of-conduct.rst @@ -43,7 +43,7 @@ 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 +Maintainers may 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, The previous text seems too much legal for my taste. > --- > 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 > -. 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 > === After looking at the comments, I would just keep TAB as a point of contact for CoC violations: diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst index ab7c24b5478c..fa908dbff51c 100644 --- a/Documentation/process/code-of-conduct.rst +++ b/Documentation/process/code-of-conduct.rst @@ -59,20 +59,12 @@ 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 -=== +Reports +=== Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the Technical Advisory Board (TAB) at -. 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 === Keeping the rest implicit. This can be revisited after having more discussions. Thanks, Mauro - Both hunks are shown below. diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst index ab7c24b5478c..df44867a2db5 100644 --- a/Documentation/process/code-of-conduct.rst +++ b/Documentation/process/code-of-conduct.rst @@ -43,7 +43,7 @@ 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 +Maintainers may 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, @@ -59,20 +59,12 @@ address, posting via an
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
On Mon, Oct 08, 2018 at 02:15:25PM -0400, Chris Mason wrote: > On 6 Oct 2018, at 17:37, James Bottomley wrote: > > 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. > > Even in the places where I don't agree with the discussion about what our > code of conduct should be, I love that we're having it. Removing the > enforcement clause basically goes back to the way things were. We'd be > recognizing that we know issues happen, and explicitly stating that when > serious events do happen, the community as a whole isn't committing to > helping. > > It's true there are a lot of questions about how the community resolves > problems and holds each other accountable for maintaining any code of > conduct. I think the enforcement section leaves us the room we need to > continue discussions and still make it clear that we're making an effort to > shift away from the harsh discussions in the past. Emphatically seconded. I absolutely agree that we should to work on the enforcement section over time; for instance, I agree that a dedicated team (ideally with some training) would be better than vesting this in a technical decision-making body. But I agree with Chris that we should not remove this entirely. And I don't think there's any special significance to this being in the 4.19 release as compared to an -rc or git HEAD.
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
On Mon, Oct 08, 2018 at 02:15:25PM -0400, Chris Mason wrote: > On 6 Oct 2018, at 17:37, James Bottomley wrote: > > 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. > > Even in the places where I don't agree with the discussion about what our > code of conduct should be, I love that we're having it. Removing the > enforcement clause basically goes back to the way things were. We'd be > recognizing that we know issues happen, and explicitly stating that when > serious events do happen, the community as a whole isn't committing to > helping. > > It's true there are a lot of questions about how the community resolves > problems and holds each other accountable for maintaining any code of > conduct. I think the enforcement section leaves us the room we need to > continue discussions and still make it clear that we're making an effort to > shift away from the harsh discussions in the past. Emphatically seconded. I absolutely agree that we should to work on the enforcement section over time; for instance, I agree that a dedicated team (ideally with some training) would be better than vesting this in a technical decision-making body. But I agree with Chris that we should not remove this entirely. And I don't think there's any special significance to this being in the 4.19 release as compared to an -rc or git HEAD.
RE: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
> -Original Message- > From: James Bottomley > > On Mon, 2018-10-08 at 17:58 +, tim.b...@sony.com wrote: > > > -Original Message- > > > From: James Bottomley > > > > > > On Mon, 2018-10-08 at 13:51 +, tim.b...@sony.com wrote: > > > > > -Original Message- > > > > > From: James Bottomley > > > > > On Sat, 2018-10-06 at 21:43 +, tim.b...@sony.com wrote: > > > > > > > -Original Message- > > > > > > > From: James Bottomley > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > Signed-off-by: James Bottomley > > > > > > > > > > > > > > --- > > > > > > > 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 > > > > > > > -. 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. > > > > > > > > > > > > I think it's OK to leave the above section, as it doesn't > > > > > > speak > > > > > > to enforcement, but rather is just a set of reporting > > > > > > instructions, with an assurance of confidentiality. This > > > > > > seems > > > > > > to me not to be the objectionable part of this section. > > > > > > (IOW, I would omit this removal from the patch). > > > > > > > > > > So I did think about that, but it struck me that with both > > > > > paragraphs removed, the current CoC is very similar to the > > > > > status quo: namely every subsystem handles their own issues and > > > > > that's formalised by the "Our Responsibilities" section. That > > > > > also makes me think that whether we want a centralised channel > > > > > of reporting or enforcement and what it should be also ought to > > > > > be part of the debate. The TAB was created to channel > > > > > community technical input into the Linux Foundation. That's > > > > > not to say it can't provide the reporting and arbitration > > > > > structure, but if we're going to do it right we should debate > > > > > the expansion of its duties (and powers). > > > > > > > > When the Code of Conflict was adopted 3 years ago, we already > > > > created the central reporting mechanism, so I actually think > > > > leaving (ie including) the above paragraph is closer to the > > > > status quo. I think it's the expanded powers and duties (or > > > > perception thereof) that are causing concern and I think debating > > > > those to clarify intent, and adopting changes as needed to > > > > ameliorate concerns is worthwhile. > > > If we want to go back to the status quo, then a plain revert is the > > > patch series I should submit. > > > > Let me try to be more clear. I don't want to go back to the status > > quo. I was saying that if we keep this document, but omit the central > > reporting mechanism, that is a large departure from the status quo, > > because the Code of Conflict already established that. And I think > > that having an ombudsman-type role somewhere in the community > > is beneficial. > > The purpose of this patch is not to be the final point but to take us > up to a useful starting point for Shuah's CoC debate proposal at the > kernel summit (and beyond). Shuah asked that I clarify this in the > commit message, so I will in v2. > > > I believe parts of the Code of Conduct are an improvement over the > > Code of Conflict, so my personal preference would be to keep
RE: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
> -Original Message- > From: James Bottomley > > On Mon, 2018-10-08 at 17:58 +, tim.b...@sony.com wrote: > > > -Original Message- > > > From: James Bottomley > > > > > > On Mon, 2018-10-08 at 13:51 +, tim.b...@sony.com wrote: > > > > > -Original Message- > > > > > From: James Bottomley > > > > > On Sat, 2018-10-06 at 21:43 +, tim.b...@sony.com wrote: > > > > > > > -Original Message- > > > > > > > From: James Bottomley > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > Signed-off-by: James Bottomley > > > > > > > > > > > > > > --- > > > > > > > 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 > > > > > > > -. 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. > > > > > > > > > > > > I think it's OK to leave the above section, as it doesn't > > > > > > speak > > > > > > to enforcement, but rather is just a set of reporting > > > > > > instructions, with an assurance of confidentiality. This > > > > > > seems > > > > > > to me not to be the objectionable part of this section. > > > > > > (IOW, I would omit this removal from the patch). > > > > > > > > > > So I did think about that, but it struck me that with both > > > > > paragraphs removed, the current CoC is very similar to the > > > > > status quo: namely every subsystem handles their own issues and > > > > > that's formalised by the "Our Responsibilities" section. That > > > > > also makes me think that whether we want a centralised channel > > > > > of reporting or enforcement and what it should be also ought to > > > > > be part of the debate. The TAB was created to channel > > > > > community technical input into the Linux Foundation. That's > > > > > not to say it can't provide the reporting and arbitration > > > > > structure, but if we're going to do it right we should debate > > > > > the expansion of its duties (and powers). > > > > > > > > When the Code of Conflict was adopted 3 years ago, we already > > > > created the central reporting mechanism, so I actually think > > > > leaving (ie including) the above paragraph is closer to the > > > > status quo. I think it's the expanded powers and duties (or > > > > perception thereof) that are causing concern and I think debating > > > > those to clarify intent, and adopting changes as needed to > > > > ameliorate concerns is worthwhile. > > > If we want to go back to the status quo, then a plain revert is the > > > patch series I should submit. > > > > Let me try to be more clear. I don't want to go back to the status > > quo. I was saying that if we keep this document, but omit the central > > reporting mechanism, that is a large departure from the status quo, > > because the Code of Conflict already established that. And I think > > that having an ombudsman-type role somewhere in the community > > is beneficial. > > The purpose of this patch is not to be the final point but to take us > up to a useful starting point for Shuah's CoC debate proposal at the > kernel summit (and beyond). Shuah asked that I clarify this in the > commit message, so I will in v2. > > > I believe parts of the Code of Conduct are an improvement over the > > Code of Conflict, so my personal preference would be to keep
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
On Mon, 2018-10-08 at 17:58 +, tim.b...@sony.com wrote: > > -Original Message- > > From: James Bottomley > > > > On Mon, 2018-10-08 at 13:51 +, tim.b...@sony.com wrote: > > > > -Original Message- > > > > From: James Bottomley > > > > On Sat, 2018-10-06 at 21:43 +, tim.b...@sony.com wrote: > > > > > > -Original Message- > > > > > > From: James Bottomley > > > > > > > > > > > > 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. > > > > > > > > > > > > Signed-off-by: James Bottomley > > > > > > > > > > > > --- > > > > > > 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 > > > > > > -. 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. > > > > > > > > > > I think it's OK to leave the above section, as it doesn't > > > > > speak > > > > > to enforcement, but rather is just a set of reporting > > > > > instructions, with an assurance of confidentiality. This > > > > > seems > > > > > to me not to be the objectionable part of this section. > > > > > (IOW, I would omit this removal from the patch). > > > > > > > > So I did think about that, but it struck me that with both > > > > paragraphs removed, the current CoC is very similar to the > > > > status quo: namely every subsystem handles their own issues and > > > > that's formalised by the "Our Responsibilities" section. That > > > > also makes me think that whether we want a centralised channel > > > > of reporting or enforcement and what it should be also ought to > > > > be part of the debate. The TAB was created to channel > > > > community technical input into the Linux Foundation. That's > > > > not to say it can't provide the reporting and arbitration > > > > structure, but if we're going to do it right we should debate > > > > the expansion of its duties (and powers). > > > > > > When the Code of Conflict was adopted 3 years ago, we already > > > created the central reporting mechanism, so I actually think > > > leaving (ie including) the above paragraph is closer to the > > > status quo. I think it's the expanded powers and duties (or > > > perception thereof) that are causing concern and I think debating > > > those to clarify intent, and adopting changes as needed to > > > ameliorate concerns is worthwhile. > > If we want to go back to the status quo, then a plain revert is the > > patch series I should submit. > > Let me try to be more clear. I don't want to go back to the status > quo. I was saying that if we keep this document, but omit the central > reporting mechanism, that is a large departure from the status quo, > because the Code of Conflict already established that. And I think > that having an ombudsman-type role somewhere in the community > is beneficial. The purpose of this patch is not to be the final point but to take us up to a useful starting point for Shuah's CoC debate proposal at the kernel summit (and beyond). Shuah asked that I clarify this in the commit message, so I will in v2. > I believe parts of the Code of Conduct are an improvement over the > Code of Conflict, so my personal preference would be to keep it > and try to adjust it moving forward. I think your patches, with > clear suggestions for improvements (or for deletions in the case > where we want more debate on particular sections before adopting > them) is a good approach, and I like that
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
On Mon, 2018-10-08 at 17:58 +, tim.b...@sony.com wrote: > > -Original Message- > > From: James Bottomley > > > > On Mon, 2018-10-08 at 13:51 +, tim.b...@sony.com wrote: > > > > -Original Message- > > > > From: James Bottomley > > > > On Sat, 2018-10-06 at 21:43 +, tim.b...@sony.com wrote: > > > > > > -Original Message- > > > > > > From: James Bottomley > > > > > > > > > > > > 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. > > > > > > > > > > > > Signed-off-by: James Bottomley > > > > > > > > > > > > --- > > > > > > 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 > > > > > > -. 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. > > > > > > > > > > I think it's OK to leave the above section, as it doesn't > > > > > speak > > > > > to enforcement, but rather is just a set of reporting > > > > > instructions, with an assurance of confidentiality. This > > > > > seems > > > > > to me not to be the objectionable part of this section. > > > > > (IOW, I would omit this removal from the patch). > > > > > > > > So I did think about that, but it struck me that with both > > > > paragraphs removed, the current CoC is very similar to the > > > > status quo: namely every subsystem handles their own issues and > > > > that's formalised by the "Our Responsibilities" section. That > > > > also makes me think that whether we want a centralised channel > > > > of reporting or enforcement and what it should be also ought to > > > > be part of the debate. The TAB was created to channel > > > > community technical input into the Linux Foundation. That's > > > > not to say it can't provide the reporting and arbitration > > > > structure, but if we're going to do it right we should debate > > > > the expansion of its duties (and powers). > > > > > > When the Code of Conflict was adopted 3 years ago, we already > > > created the central reporting mechanism, so I actually think > > > leaving (ie including) the above paragraph is closer to the > > > status quo. I think it's the expanded powers and duties (or > > > perception thereof) that are causing concern and I think debating > > > those to clarify intent, and adopting changes as needed to > > > ameliorate concerns is worthwhile. > > If we want to go back to the status quo, then a plain revert is the > > patch series I should submit. > > Let me try to be more clear. I don't want to go back to the status > quo. I was saying that if we keep this document, but omit the central > reporting mechanism, that is a large departure from the status quo, > because the Code of Conflict already established that. And I think > that having an ombudsman-type role somewhere in the community > is beneficial. The purpose of this patch is not to be the final point but to take us up to a useful starting point for Shuah's CoC debate proposal at the kernel summit (and beyond). Shuah asked that I clarify this in the commit message, so I will in v2. > I believe parts of the Code of Conduct are an improvement over the > Code of Conflict, so my personal preference would be to keep it > and try to adjust it moving forward. I think your patches, with > clear suggestions for improvements (or for deletions in the case > where we want more debate on particular sections before adopting > them) is a good approach, and I like that
RE: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
> -Original Message- > From: James Bottomley > > On Mon, 2018-10-08 at 13:51 +, tim.b...@sony.com wrote: > > > -Original Message- > > > From: James Bottomley > > > On Sat, 2018-10-06 at 21:43 +, tim.b...@sony.com wrote: > > > > > -Original Message- > > > > > From: James Bottomley > > > > > > > > > > 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. > > > > > > > > > > Signed-off-by: James Bottomley > > > > > > > > > > --- > > > > > 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 > > > > > -. 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. > > > > > > > > I think it's OK to leave the above section, as it doesn't speak > > > > to enforcement, but rather is just a set of reporting > > > > instructions, with an assurance of confidentiality. This seems > > > > to me not to be the objectionable part of this section. > > > > (IOW, I would omit this removal from the patch). > > > > > > So I did think about that, but it struck me that with both > > > paragraphs removed, the current CoC is very similar to the status > > > quo: namely every subsystem handles their own issues and that's > > > formalised by the "Our Responsibilities" section. That also makes > > > me think that whether we want a centralised channel of reporting or > > > enforcement and what it should be also ought to be part of the > > > debate. The TAB was created to channel community technical input > > > into the Linux Foundation. That's not to say it can't provide the > > > reporting and arbitration structure, but if we're going to do it > > > right we should debate the expansion of its duties (and powers). > > > > When the Code of Conflict was adopted 3 years ago, we already created > > the central reporting mechanism, so I actually think leaving (ie > > including) the above paragraph is closer to the status quo. I think > > it's the expanded powers and duties (or perception thereof) that are > > causing concern and I think debating those to clarify intent, and > > adopting changes as needed to ameliorate concerns is worthwhile. > > If we want to go back to the status quo, then a plain revert is the > patch series I should submit. Let me try to be more clear. I don't want to go back to the status quo. I was saying that if we keep this document, but omit the central reporting mechanism, that is a large departure from the status quo, because the Code of Conflict already established that. And I think that having an ombudsman-type role somewhere in the community is beneficial. I believe parts of the Code of Conduct are an improvement over the Code of Conflict, so my personal preference would be to keep it and try to adjust it moving forward. I think your patches, with clear suggestions for improvements (or for deletions in the case where we want more debate on particular sections before adopting them) is a good approach, and I like that process as opposed to starting over from scratch. > > > I believe that in the vast majority of cases, the TAB will end up > > performing a mediator role to smooth hurt feelings and remind and > > encourage improved communication - very similar to what we've done in > > the past. I really believe that bans will continue to be very few > > and far between, as they have been historically (I can only think of > > 3 in the past decade.) > > That might very well be the position the discussion arrives at; > however, I really think making the process fully transparent
RE: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
> -Original Message- > From: James Bottomley > > On Mon, 2018-10-08 at 13:51 +, tim.b...@sony.com wrote: > > > -Original Message- > > > From: James Bottomley > > > On Sat, 2018-10-06 at 21:43 +, tim.b...@sony.com wrote: > > > > > -Original Message- > > > > > From: James Bottomley > > > > > > > > > > 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. > > > > > > > > > > Signed-off-by: James Bottomley > > > > > > > > > > --- > > > > > 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 > > > > > -. 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. > > > > > > > > I think it's OK to leave the above section, as it doesn't speak > > > > to enforcement, but rather is just a set of reporting > > > > instructions, with an assurance of confidentiality. This seems > > > > to me not to be the objectionable part of this section. > > > > (IOW, I would omit this removal from the patch). > > > > > > So I did think about that, but it struck me that with both > > > paragraphs removed, the current CoC is very similar to the status > > > quo: namely every subsystem handles their own issues and that's > > > formalised by the "Our Responsibilities" section. That also makes > > > me think that whether we want a centralised channel of reporting or > > > enforcement and what it should be also ought to be part of the > > > debate. The TAB was created to channel community technical input > > > into the Linux Foundation. That's not to say it can't provide the > > > reporting and arbitration structure, but if we're going to do it > > > right we should debate the expansion of its duties (and powers). > > > > When the Code of Conflict was adopted 3 years ago, we already created > > the central reporting mechanism, so I actually think leaving (ie > > including) the above paragraph is closer to the status quo. I think > > it's the expanded powers and duties (or perception thereof) that are > > causing concern and I think debating those to clarify intent, and > > adopting changes as needed to ameliorate concerns is worthwhile. > > If we want to go back to the status quo, then a plain revert is the > patch series I should submit. Let me try to be more clear. I don't want to go back to the status quo. I was saying that if we keep this document, but omit the central reporting mechanism, that is a large departure from the status quo, because the Code of Conflict already established that. And I think that having an ombudsman-type role somewhere in the community is beneficial. I believe parts of the Code of Conduct are an improvement over the Code of Conflict, so my personal preference would be to keep it and try to adjust it moving forward. I think your patches, with clear suggestions for improvements (or for deletions in the case where we want more debate on particular sections before adopting them) is a good approach, and I like that process as opposed to starting over from scratch. > > > I believe that in the vast majority of cases, the TAB will end up > > performing a mediator role to smooth hurt feelings and remind and > > encourage improved communication - very similar to what we've done in > > the past. I really believe that bans will continue to be very few > > and far between, as they have been historically (I can only think of > > 3 in the past decade.) > > That might very well be the position the discussion arrives at; > however, I really think making the process fully transparent
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
> I happen to think that the fact that the TAB cannot compel where it > cannot persuade is a huge strength of the system because it means > there's no power structure to subvert if someone were interested in > using it to try to impose their own viewpoint on the community. But > that's just my opinion and I did write the TAB charter, so I'm probably > biased in this viewpoint. The TAB can't handle it anyway because the privacy promise about reporting is incompatible with reality for three reasons (and I bet there are more) 1. Things like the EUCD can force almost all but the name to be revealed to the person complained about as the tab has no legal privilege. 2. There are lots of laws in lots of locations where some allegations *MUST* be reported to law enforcement. 3. We know from things like the catholic church debacle that serious allegations need to be fast-pathed to the legal system - yet the privacy promises are incompatible with that. It ever got really nasty then the scenario that unfolds is potentially the following Developer A makes a complaint about developer B Developer B's employer fires developer B Developer B then uses things like the EUCD to force the TAB to provide the complaint details (with personal data redacted) and the TAB has no real defence as it's not legally privileged. Developer B then sues developer A, the TAB for all sorts of things, the LF and their employer. In court what's going to happen to the TAB ? = Where is your written policy ? = Who approved it and reviewed it for legal compliance ? = What are your qualifications in this area ? = Where are the full minutes of the decision ? = Which of you work for rival companies ? = What personal connections do or your frends have to A and B ? Needless to say answers like 'we don't have one, nobody, none, umm I think there's an email thread' are not going to go down well. This sort of mess works with big company HR departments because they've got lawyers and they have lots of written process. If it hits a court then B's employer is able to point at all their rules and policies, employment contracts etc. All of the decisions were either legally privileged or minuted properly. The people who made the decisions have appropriate professional qualifications. The TAB can't enforce anything. If maintainers decide to carry on accepting patches from someone what can they do ? So both patches: Reviewed-by: Alan Cox
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
> I happen to think that the fact that the TAB cannot compel where it > cannot persuade is a huge strength of the system because it means > there's no power structure to subvert if someone were interested in > using it to try to impose their own viewpoint on the community. But > that's just my opinion and I did write the TAB charter, so I'm probably > biased in this viewpoint. The TAB can't handle it anyway because the privacy promise about reporting is incompatible with reality for three reasons (and I bet there are more) 1. Things like the EUCD can force almost all but the name to be revealed to the person complained about as the tab has no legal privilege. 2. There are lots of laws in lots of locations where some allegations *MUST* be reported to law enforcement. 3. We know from things like the catholic church debacle that serious allegations need to be fast-pathed to the legal system - yet the privacy promises are incompatible with that. It ever got really nasty then the scenario that unfolds is potentially the following Developer A makes a complaint about developer B Developer B's employer fires developer B Developer B then uses things like the EUCD to force the TAB to provide the complaint details (with personal data redacted) and the TAB has no real defence as it's not legally privileged. Developer B then sues developer A, the TAB for all sorts of things, the LF and their employer. In court what's going to happen to the TAB ? = Where is your written policy ? = Who approved it and reviewed it for legal compliance ? = What are your qualifications in this area ? = Where are the full minutes of the decision ? = Which of you work for rival companies ? = What personal connections do or your frends have to A and B ? Needless to say answers like 'we don't have one, nobody, none, umm I think there's an email thread' are not going to go down well. This sort of mess works with big company HR departments because they've got lawyers and they have lots of written process. If it hits a court then B's employer is able to point at all their rules and policies, employment contracts etc. All of the decisions were either legally privileged or minuted properly. The people who made the decisions have appropriate professional qualifications. The TAB can't enforce anything. If maintainers decide to carry on accepting patches from someone what can they do ? So both patches: Reviewed-by: Alan Cox
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
On Mon, Oct 8, 2018 at 9:51 AM wrote: > > > > > -Original Message- > > From: James Bottomley > > On Sat, 2018-10-06 at 21:43 +, tim.b...@sony.com wrote: > > > > -Original Message- > > > > From: James Bottomley > > > > > > > > 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. > > > > > > > > Signed-off-by: James Bottomley > > > > > > > > --- > > > > 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 > > > > -. 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. > > > > > > I think it's OK to leave the above section, as it doesn't speak to > > > enforcement, but rather is just a set of reporting instructions, > > > with an assurance of confidentiality. This seems to me not to be > > > the objectionable part of this section. > > > (IOW, I would omit this removal from the patch). > > > > So I did think about that, but it struck me that with both paragraphs > > removed, the current CoC is very similar to the status quo: namely > > every subsystem handles their own issues and that's formalised by the > > "Our Responsibilities" section. That also makes me think that whether > > we want a centralised channel of reporting or enforcement and what it > > should be also ought to be part of the debate. The TAB was created to > > channel community technical input into the Linux Foundation. That's > > not to say it can't provide the reporting and arbitration structure, > > but if we're going to do it right we should debate the expansion of its > > duties (and powers). > > When the Code of Conflict was adopted 3 years ago, we already created > the central reporting mechanism, so I actually think leaving (ie including) > the above > paragraph is closer to the status quo. I think it's the expanded powers and > duties (or perception thereof) that are causing concern and I think debating > those to clarify intent, and adopting changes as needed to ameliorate > concerns > is worthwhile. In most cases any CoC is not going to be much of a problem. The problem is going to occur when one of the top five or so people is accused of a violation. That is going to end up in the mainstream press. Big money and corporate power will be at play. The CoC needs needs to be designed to handle something like the Bredan Eich situation. In that situation he was initially attacked by external parties. I will keep recommending that the legal community weigh in before making this official policy. We are focusing on the case of the random individual, but I suspect the problem lies in an attack on the leadership. > > I believe that in the vast majority of cases, the TAB will end up > performing a mediator role to smooth hurt feelings and remind and encourage > improved communication - very similar to what we've done in the past. I > really > believe that bans will continue to be very few and far between, as they have > been historically (I can only think of 3 in the past decade.) > -- Tim > > ___ > Ksummit-discuss mailing list > ksummit-disc...@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss -- Jon Smirl jonsm...@gmail.com
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
On Mon, Oct 8, 2018 at 9:51 AM wrote: > > > > > -Original Message- > > From: James Bottomley > > On Sat, 2018-10-06 at 21:43 +, tim.b...@sony.com wrote: > > > > -Original Message- > > > > From: James Bottomley > > > > > > > > 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. > > > > > > > > Signed-off-by: James Bottomley > > > > > > > > --- > > > > 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 > > > > -. 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. > > > > > > I think it's OK to leave the above section, as it doesn't speak to > > > enforcement, but rather is just a set of reporting instructions, > > > with an assurance of confidentiality. This seems to me not to be > > > the objectionable part of this section. > > > (IOW, I would omit this removal from the patch). > > > > So I did think about that, but it struck me that with both paragraphs > > removed, the current CoC is very similar to the status quo: namely > > every subsystem handles their own issues and that's formalised by the > > "Our Responsibilities" section. That also makes me think that whether > > we want a centralised channel of reporting or enforcement and what it > > should be also ought to be part of the debate. The TAB was created to > > channel community technical input into the Linux Foundation. That's > > not to say it can't provide the reporting and arbitration structure, > > but if we're going to do it right we should debate the expansion of its > > duties (and powers). > > When the Code of Conflict was adopted 3 years ago, we already created > the central reporting mechanism, so I actually think leaving (ie including) > the above > paragraph is closer to the status quo. I think it's the expanded powers and > duties (or perception thereof) that are causing concern and I think debating > those to clarify intent, and adopting changes as needed to ameliorate > concerns > is worthwhile. In most cases any CoC is not going to be much of a problem. The problem is going to occur when one of the top five or so people is accused of a violation. That is going to end up in the mainstream press. Big money and corporate power will be at play. The CoC needs needs to be designed to handle something like the Bredan Eich situation. In that situation he was initially attacked by external parties. I will keep recommending that the legal community weigh in before making this official policy. We are focusing on the case of the random individual, but I suspect the problem lies in an attack on the leadership. > > I believe that in the vast majority of cases, the TAB will end up > performing a mediator role to smooth hurt feelings and remind and encourage > improved communication - very similar to what we've done in the past. I > really > believe that bans will continue to be very few and far between, as they have > been historically (I can only think of 3 in the past decade.) > -- Tim > > ___ > Ksummit-discuss mailing list > ksummit-disc...@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss -- Jon Smirl jonsm...@gmail.com
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
On Mon, 2018-10-08 at 13:51 +, tim.b...@sony.com wrote: > > -Original Message- > > From: James Bottomley > > On Sat, 2018-10-06 at 21:43 +, tim.b...@sony.com wrote: > > > > -Original Message- > > > > From: James Bottomley > > > > > > > > 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. > > > > > > > > Signed-off-by: James Bottomley > > > > > > > > --- > > > > 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 > > > > -. 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. > > > > > > I think it's OK to leave the above section, as it doesn't speak > > > to enforcement, but rather is just a set of reporting > > > instructions, with an assurance of confidentiality. This seems > > > to me not to be the objectionable part of this section. > > > (IOW, I would omit this removal from the patch). > > > > So I did think about that, but it struck me that with both > > paragraphs removed, the current CoC is very similar to the status > > quo: namely every subsystem handles their own issues and that's > > formalised by the "Our Responsibilities" section. That also makes > > me think that whether we want a centralised channel of reporting or > > enforcement and what it should be also ought to be part of the > > debate. The TAB was created to channel community technical input > > into the Linux Foundation. That's not to say it can't provide the > > reporting and arbitration structure, but if we're going to do it > > right we should debate the expansion of its duties (and powers). > > When the Code of Conflict was adopted 3 years ago, we already created > the central reporting mechanism, so I actually think leaving (ie > including) the above paragraph is closer to the status quo. I think > it's the expanded powers and duties (or perception thereof) that are > causing concern and I think debating those to clarify intent, and > adopting changes as needed to ameliorate concerns is worthwhile. If we want to go back to the status quo, then a plain revert is the patch series I should submit. > I believe that in the vast majority of cases, the TAB will end up > performing a mediator role to smooth hurt feelings and remind and > encourage improved communication - very similar to what we've done in > the past. I really believe that bans will continue to be very few > and far between, as they have been historically (I can only think of > 3 in the past decade.) That might very well be the position the discussion arrives at; however, I really think making the process fully transparent this time requires not prejudging the outcome. James
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
On Mon, 2018-10-08 at 13:51 +, tim.b...@sony.com wrote: > > -Original Message- > > From: James Bottomley > > On Sat, 2018-10-06 at 21:43 +, tim.b...@sony.com wrote: > > > > -Original Message- > > > > From: James Bottomley > > > > > > > > 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. > > > > > > > > Signed-off-by: James Bottomley > > > > > > > > --- > > > > 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 > > > > -. 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. > > > > > > I think it's OK to leave the above section, as it doesn't speak > > > to enforcement, but rather is just a set of reporting > > > instructions, with an assurance of confidentiality. This seems > > > to me not to be the objectionable part of this section. > > > (IOW, I would omit this removal from the patch). > > > > So I did think about that, but it struck me that with both > > paragraphs removed, the current CoC is very similar to the status > > quo: namely every subsystem handles their own issues and that's > > formalised by the "Our Responsibilities" section. That also makes > > me think that whether we want a centralised channel of reporting or > > enforcement and what it should be also ought to be part of the > > debate. The TAB was created to channel community technical input > > into the Linux Foundation. That's not to say it can't provide the > > reporting and arbitration structure, but if we're going to do it > > right we should debate the expansion of its duties (and powers). > > When the Code of Conflict was adopted 3 years ago, we already created > the central reporting mechanism, so I actually think leaving (ie > including) the above paragraph is closer to the status quo. I think > it's the expanded powers and duties (or perception thereof) that are > causing concern and I think debating those to clarify intent, and > adopting changes as needed to ameliorate concerns is worthwhile. If we want to go back to the status quo, then a plain revert is the patch series I should submit. > I believe that in the vast majority of cases, the TAB will end up > performing a mediator role to smooth hurt feelings and remind and > encourage improved communication - very similar to what we've done in > the past. I really believe that bans will continue to be very few > and far between, as they have been historically (I can only think of > 3 in the past decade.) That might very well be the position the discussion arrives at; however, I really think making the process fully transparent this time requires not prejudging the outcome. James
RE: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
> -Original Message- > From: James Bottomley > On Sat, 2018-10-06 at 21:43 +, tim.b...@sony.com wrote: > > > -Original Message- > > > From: James Bottomley > > > > > > 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. > > > > > > Signed-off-by: James Bottomley > > > > > > --- > > > 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 > > > -. 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. > > > > I think it's OK to leave the above section, as it doesn't speak to > > enforcement, but rather is just a set of reporting instructions, > > with an assurance of confidentiality. This seems to me not to be > > the objectionable part of this section. > > (IOW, I would omit this removal from the patch). > > So I did think about that, but it struck me that with both paragraphs > removed, the current CoC is very similar to the status quo: namely > every subsystem handles their own issues and that's formalised by the > "Our Responsibilities" section. That also makes me think that whether > we want a centralised channel of reporting or enforcement and what it > should be also ought to be part of the debate. The TAB was created to > channel community technical input into the Linux Foundation. That's > not to say it can't provide the reporting and arbitration structure, > but if we're going to do it right we should debate the expansion of its > duties (and powers). When the Code of Conflict was adopted 3 years ago, we already created the central reporting mechanism, so I actually think leaving (ie including) the above paragraph is closer to the status quo. I think it's the expanded powers and duties (or perception thereof) that are causing concern and I think debating those to clarify intent, and adopting changes as needed to ameliorate concerns is worthwhile. I believe that in the vast majority of cases, the TAB will end up performing a mediator role to smooth hurt feelings and remind and encourage improved communication - very similar to what we've done in the past. I really believe that bans will continue to be very few and far between, as they have been historically (I can only think of 3 in the past decade.) -- Tim
RE: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
> -Original Message- > From: James Bottomley > On Sat, 2018-10-06 at 21:43 +, tim.b...@sony.com wrote: > > > -Original Message- > > > From: James Bottomley > > > > > > 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. > > > > > > Signed-off-by: James Bottomley > > > > > > --- > > > 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 > > > -. 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. > > > > I think it's OK to leave the above section, as it doesn't speak to > > enforcement, but rather is just a set of reporting instructions, > > with an assurance of confidentiality. This seems to me not to be > > the objectionable part of this section. > > (IOW, I would omit this removal from the patch). > > So I did think about that, but it struck me that with both paragraphs > removed, the current CoC is very similar to the status quo: namely > every subsystem handles their own issues and that's formalised by the > "Our Responsibilities" section. That also makes me think that whether > we want a centralised channel of reporting or enforcement and what it > should be also ought to be part of the debate. The TAB was created to > channel community technical input into the Linux Foundation. That's > not to say it can't provide the reporting and arbitration structure, > but if we're going to do it right we should debate the expansion of its > duties (and powers). When the Code of Conflict was adopted 3 years ago, we already created the central reporting mechanism, so I actually think leaving (ie including) the above paragraph is closer to the status quo. I think it's the expanded powers and duties (or perception thereof) that are causing concern and I think debating those to clarify intent, and adopting changes as needed to ameliorate concerns is worthwhile. I believe that in the vast majority of cases, the TAB will end up performing a mediator role to smooth hurt feelings and remind and encourage improved communication - very similar to what we've done in the past. I really believe that bans will continue to be very few and far between, as they have been historically (I can only think of 3 in the past decade.) -- Tim
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
On Sat, Oct 6, 2018 at 11:37 PM James Bottomley
wrote:
> 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.
>
> Signed-off-by: James Bottomley
Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
On Sat, Oct 6, 2018 at 11:37 PM James Bottomley
wrote:
> 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.
>
> Signed-off-by: James Bottomley
Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
On 10/06/2018 02:37 PM, James Bottomley wrote: 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. Signed-off-by: James Bottomley Acked-by: Guenter Roeck Reasoning: - The TAB was not elected as enforcement agency. - I, as a maintainer, was not consulted when it was decided that I shall be responsible for enforcing the Code of Conduct. Guenter --- 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 -. 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 ===
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
On 10/06/2018 02:37 PM, James Bottomley wrote: 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. Signed-off-by: James Bottomley Acked-by: Guenter Roeck Reasoning: - The TAB was not elected as enforcement agency. - I, as a maintainer, was not consulted when it was decided that I shall be responsible for enforcing the Code of Conduct. Guenter --- 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 -. 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 ===
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
On 10/06/2018 03:37 PM, James Bottomley wrote: > 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. > > Signed-off-by: James Bottomley > --- > 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 > -. 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 > === > > With the assumption that the enforcement details will be added later after community discussion in upcoming releases. Acked-by: Shuah Khan thanks, -- Shuah
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
On 10/06/2018 03:37 PM, James Bottomley wrote: > 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. > > Signed-off-by: James Bottomley > --- > 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 > -. 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 > === > > With the assumption that the enforcement details will be added later after community discussion in upcoming releases. Acked-by: Shuah Khan thanks, -- Shuah
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
On Sat, 2018-10-06 at 21:43 +, tim.b...@sony.com wrote: > > -Original Message- > > From: James Bottomley > > > > 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. > > > > Signed-off-by: James Bottomley > > > > --- > > 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 > > -. 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. > > I think it's OK to leave the above section, as it doesn't speak to > enforcement, but rather is just a set of reporting instructions, > with an assurance of confidentiality. This seems to me not to be > the objectionable part of this section. > (IOW, I would omit this removal from the patch). So I did think about that, but it struck me that with both paragraphs removed, the current CoC is very similar to the status quo: namely every subsystem handles their own issues and that's formalised by the "Our Responsibilities" section. That also makes me think that whether we want a centralised channel of reporting or enforcement and what it should be also ought to be part of the debate. The TAB was created to channel community technical input into the Linux Foundation. That's not to say it can't provide the reporting and arbitration structure, but if we're going to do it right we should debate the expansion of its duties (and powers). I happen to think that the fact that the TAB cannot compel where it cannot persuade is a huge strength of the system because it means there's no power structure to subvert if someone were interested in using it to try to impose their own viewpoint on the community. But that's just my opinion and I did write the TAB charter, so I'm probably biased in this viewpoint. James > If the next part is indeed removed, then maybe the section > needs to be renamed? > -- Tim > > > - > > -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 > > === > > ___ > Ksummit-discuss mailing list > ksummit-disc...@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
On Sat, 2018-10-06 at 21:43 +, tim.b...@sony.com wrote: > > -Original Message- > > From: James Bottomley > > > > 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. > > > > Signed-off-by: James Bottomley > > > > --- > > 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 > > -. 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. > > I think it's OK to leave the above section, as it doesn't speak to > enforcement, but rather is just a set of reporting instructions, > with an assurance of confidentiality. This seems to me not to be > the objectionable part of this section. > (IOW, I would omit this removal from the patch). So I did think about that, but it struck me that with both paragraphs removed, the current CoC is very similar to the status quo: namely every subsystem handles their own issues and that's formalised by the "Our Responsibilities" section. That also makes me think that whether we want a centralised channel of reporting or enforcement and what it should be also ought to be part of the debate. The TAB was created to channel community technical input into the Linux Foundation. That's not to say it can't provide the reporting and arbitration structure, but if we're going to do it right we should debate the expansion of its duties (and powers). I happen to think that the fact that the TAB cannot compel where it cannot persuade is a huge strength of the system because it means there's no power structure to subvert if someone were interested in using it to try to impose their own viewpoint on the community. But that's just my opinion and I did write the TAB charter, so I'm probably biased in this viewpoint. James > If the next part is indeed removed, then maybe the section > needs to be renamed? > -- Tim > > > - > > -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 > > === > > ___ > Ksummit-discuss mailing list > ksummit-disc...@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
RE: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
> -Original Message- > From: James Bottomley > > 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. > > Signed-off-by: James Bottomley > > --- > 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 > -. 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. I think it's OK to leave the above section, as it doesn't speak to enforcement, but rather is just a set of reporting instructions, with an assurance of confidentiality. This seems to me not to be the objectionable part of this section. (IOW, I would omit this removal from the patch). If the next part is indeed removed, then maybe the section needs to be renamed? -- Tim > - > -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 > ===
RE: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
> -Original Message- > From: James Bottomley > > 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. > > Signed-off-by: James Bottomley > > --- > 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 > -. 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. I think it's OK to leave the above section, as it doesn't speak to enforcement, but rather is just a set of reporting instructions, with an assurance of confidentiality. This seems to me not to be the objectionable part of this section. (IOW, I would omit this removal from the patch). If the next part is indeed removed, then maybe the section needs to be renamed? -- Tim > - > -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 > ===
