Message-ID: <875zxt919d.fsf@notabene.neil.brown.name>
Date:   Tue, 23 Oct 2018 07:26:06 +1100
From:   NeilBrown <neil@...wn.name>
To:     Josh Triplett <josh@...htriplett.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        ksummit-discuss@...ts.linuxfoundation.org,
        Mishi Choudhary <mishi@...ux.com>
Subject: Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document

On Sun, Oct 21 2018, Josh Triplett wrote:

> On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
>> I call on you, Greg:
>>  - to abandon this divisive attempt to impose a "Code of Conduct"
>>  - to revert 8a104f8b5867c68
>>  - to return to your core competence of building a great team around
>>    a great kernel
>> 
>>  #Isupportreversion
>> 
>> I call on the community to consider what *does* need to be said, about
>> conduct, to people outside the community and who have recently joined.
>> What is the document that you would have liked to have read as you were
>> starting out?  It is all too long ago for me to remember clearly, and so
>> much has changed.
>
> The document I would have liked to have read when starting out is
> currently checked into the source tree in
> Documentation/process/code-of-conduct.rst .

I'm curious - what would you have gained by reading that document?

>
> What is your actual concern? Why does it matter so much to you to push
> back against this code of conduct? What does it say that you so
> fundamentally object to?

Thank you for asking.  The discipline of focusing on an answer to this
question (rather than being distracted by all the different things that
are wrong here) has helped me to clarify my thoughts very nicely.

The current document is upside down.

The whole point of any document like this is to curtail, bypass, or
redirect the power of the powerful (and thanks to Dave[1] for the "power"
frame).  We already have plenty of process documents which attempt to give
power to the weak by explaining how they can be heard.  While those
documents might have room for improvement in this process, this document
is quite different - it aims to take power away.

The power that the current document describes is the power of having a
platform on which to speak - through a wiki, through comments, through
code etc.  It talks about maintainers curtailing that power when it is
misused.

I argue that regular "participants" in the kernel community have
virtually no power.  The only "platforms" for speech are lkml (and other
lists) and bugzilla.  lkml is a cacophony (even Mozart would sound
terrible if we played all his works at once!) and bugzilla is a ghost
town.  Neither provide a platform where any central control is needed.
Every subscriber already filters content themselves, whether by
unsubscribing, just skimming subject lines, or with more automated
assistance (and that is not something the community can control, whether
it wants to or not).

The only strength that participants have is the value of their
contribution, and this is only turned into power when they are listened
to.

On the other end of the spectrum, Linus has all the power.  Patches are
the currency of the realm and all power (popularity, voice, voting
rights) flow from them.  Linus ultimately controls patches and has
ultimate power (almost - see below)

In between are maintainers - they received power from Linus through
lines of trust, and sometimes pass it on through other lines of trust -
to sub-maintainers and valued contributors.   They also (noblesse oblige)
give some power to the poor who they don't know - accepting bug
reports, giving advice, reviewing patches.

Given the power structure, the document we should be modeling our
thoughts on is the Magna Carte, where the British barons demanded that
the King's power be curtailed.
We don't need a document where the maintainers tell the participants how
they must behave, but we might need one where the maintainers tell Linus
how to behave.

As I said, the current document is upside down.

I would hope that Linus would provide Magna Carte himself, but maybe he
isn't up to it.  In which case, our job is to draft a document for Linus
to agree to abide by.  He might want to then make changes, and that is
*perfect* *fine*.  It is *his* statement to the community on how *he*
will use the power he has - after all, it is ultimately the whole
community (well beyond developers) who give Linus the power he has by
valuing the product he produces (just as farmers ultimately give power
to the king by putting food on his table to feed him and his soldiers).

Once Linus has adopted such a document, we can look to other
maintainers to follow suite.  They might choose to use the same
document, or to write something completely different.  In either case,
it puts their stance clearly on the table.  People who find the need to
work with them can have clear expectations, and can decide on the best
approach, and whether it is worth the effort at all.

In parallel with these promises (willingly adopted, not imposed), we
need clear processes for people to follow if they cannot work with a
maintainer, either because the promise doesn't make them feel safe
enough, or because the maintainer violates their own promise.
This isn't about enforcement and repercussions and punishment exactly.
This is about economics - keeping the patches moving.

If, for example, Linus or Andrew said "if you cannot work with any given
maintainer, I will consider your patch directly, but you need to point
to where you tried, and why you failed - or to where the promise is
inadequate".

Currently if a maintainer is rude to you, there is no where else that
you can go and *that* is why it hurts.  It isn't the abuse so much as
the powerlessness associated with it.  If you can (metaphorically) say
to that maintainer "I don't care about your toilet mouth, you've just
given me the right to take my petition to caesar" - then the emotional
response will be quite different to pain.

If Linus is not true to his new-found sensitivity, we might need someone
(Greg?) to be a co-maintainer, able to accept patches when Linus has a
relapse.  It might be good form to create this channel anyway, but I
doubt it would be needed in practice.

So there you have it. The "Code" is upside down.
We need documents which:
  - curtail the power of the strong, starting with Linus
  - are adopted willingly by individuals, not imposed on the community.
  - provide alternate routes for patch-flow, so that no-one has ultimate
    power.

Thanks,
NeilBrown
#Iobject #Iforgive #Iapologize #Isupportreversion

[1] just a random "Dave"

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)

Powered by blists - more mailing lists