RE: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

[Tim.Bird]

> -----Original Message-----
> From: James Bottomley
> 
> On Mon, 2018-10-08 at 17:58 +0000, Tim.Bird@xxxxxxxx wrote:
> > > -----Original Message-----
> > > From: James Bottomley
> > >
> > > On Mon, 2018-10-08 at 13:51 +0000, Tim.Bird@xxxxxxxx wrote:
> > > > > -----Original Message-----
> > > > > From: James Bottomley
> > > > > On Sat, 2018-10-06 at 21:43 +0000, Tim.Bird@xxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxx>
> > > > > > > ---
> > > > > > > Â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@xxxxxxxxxxxxxxxxxxxxxxxxxx>. 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 process as opposed to
> > starting over from scratch.
> 
> OK, so you're happy with the current patch as the starting not the
> ending point?

I'm happy with the second hunk as a starting point, but not the first.
I think the first hunk is a regression that is not needed to address the
concerns that I have seen raised so far.  The first hunk seems to me to be
close to what the Code of Conflict already had, and what the
community was already working under.

> > > > 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.
> >
> > I don't understand your point here.ÂÂCan you elaborate?
> 
> Yes: I could foresee an outcome where the kernel community decides to
> vest CoC enforcement in a different body from the TAB, or even in no
> body but an informal maintainers list.  I'm not saying that *will*
> happen, merely that it's an outcome that should not be foreclosed at
> this point.

OK, thanks for the explanation.  I don't have a strong opinion about
the resulting outcome of community consensus.  I think we'll come up
with something that satisfies most people, and it's possible it won't look like
what we have now.  So I'd agree we shouldn't foreclose outcomes.  I hope it
doesn't look like I'm *just* arguing for keeping the TAB in some enforcement
role.  I'm not.  I'm arguing that the current CoC language (in the first
paragraph of the enforcement section) keeps the TAB as the central reporting
mechanism, and that this is less of a change to current policy than removing it.
If people want to argue for a difference in central reporting, or no central
reporting at all, I'm all ears.
(Although, I'm not sure my ears count for anything.  That's up to whoever
accepts such patches, and that's not me.)

Put a completely different way:  I believe the goal of the patch is to remove
parts of the new CoC that people have concerns about, pending a community
discussion about the issues.  My personal opinion is that the first part of
the enforcement clause, listing the TAB as the contact point, and trying to make
an assurance of confidentiality, doesn't have to be part of that removal (now),
because it's not very controversial.
 -- Tim