lkml.org 
[lkml]   [2018]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectRe: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion
From
Date
On Mon, 2018-10-08 at 13:51 +0000, Tim.Bird@sony.com wrote:
> > -----Original Message-----
> > From: James Bottomley 
> > On Sat, 2018-10-06 at 21:43 +0000, Tim.Bird@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
> > > > <James.Bottomley@HansenPartnership.com>
> > > > ---
> > > >  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
> > > > -<tab@lists.linux-foundation.org>. 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

\
 
 \ /
  Last update: 2018-10-08 16:11    [W:0.145 / U:9.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site