From: NeilBrown <neil@brown.name> To: Josh Triplett <josh@joshtriplett.org> Cc: Mishi Choudhary <mishi@linux.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, linux-kernel <linux-kernel@vger.kernel.org>, ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document Date: Tue, 23 Oct 2018 07:26:06 +1100 [thread overview] Message-ID: <875zxt919d.fsf@notabene.neil.brown.name> (raw) In-Reply-To: <20181021222608.GA24845@localhost> [-- Attachment #1: Type: text/plain, Size: 6345 bytes --] 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" [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: NeilBrown <neil@brown.name> To: Josh Triplett <josh@joshtriplett.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, linux-kernel <linux-kernel@vger.kernel.org>, Linus Torvalds <torvalds@linux-foundation.org>, ksummit-discuss@lists.linuxfoundation.org, Mishi Choudhary <mishi@linux.com> Subject: Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document Date: Tue, 23 Oct 2018 07:26:06 +1100 [thread overview] Message-ID: <875zxt919d.fsf@notabene.neil.brown.name> (raw) In-Reply-To: <20181021222608.GA24845@localhost> [-- Attachment #1: Type: text/plain, Size: 6345 bytes --] 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" [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2018-10-22 20:26 UTC|newest] Thread overview: 177+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-20 13:49 [Ksummit-discuss] [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document Greg Kroah-Hartman 2018-10-20 13:49 ` Greg Kroah-Hartman 2018-10-20 13:49 ` [Ksummit-discuss] [PATCH 1/7] Code of conduct: Fix wording around maintainers enforcing the code of conduct Greg Kroah-Hartman 2018-10-20 13:49 ` Greg Kroah-Hartman 2018-10-20 13:50 ` [Ksummit-discuss] [PATCH 2/7] Code of Conduct Interpretation: Add document explaining how the Code of Conduct is to be interpreted Greg Kroah-Hartman 2018-10-20 13:50 ` Greg Kroah-Hartman 2018-10-20 13:50 ` [Ksummit-discuss] [PATCH 3/7] Code of Conduct Interpretation: Properly reference the TAB correctly Greg Kroah-Hartman 2018-10-20 13:50 ` Greg Kroah-Hartman 2018-10-20 13:50 ` [Ksummit-discuss] [PATCH 4/7] Code of Conduct: Provide links between the two documents Greg Kroah-Hartman 2018-10-20 13:50 ` Greg Kroah-Hartman 2018-10-20 13:50 ` [Ksummit-discuss] [PATCH 5/7] Code of Conduct Interpretation: Put in the proper URL for the committee Greg Kroah-Hartman 2018-10-20 13:50 ` Greg Kroah-Hartman 2018-10-20 19:01 ` [Ksummit-discuss] " Geert Uytterhoeven 2018-10-20 19:01 ` Geert Uytterhoeven 2018-10-21 7:18 ` [Ksummit-discuss] " Greg KH 2018-10-21 7:18 ` Greg KH 2018-10-20 13:51 ` [Ksummit-discuss] [PATCH 6/7] Code of Conduct: Change the contact email address Greg Kroah-Hartman 2018-10-20 13:51 ` Greg Kroah-Hartman 2018-10-20 18:28 ` [Ksummit-discuss] " Alan Cox 2018-10-20 18:28 ` Alan Cox 2018-10-20 18:45 ` [Ksummit-discuss] " Trond Myklebust 2018-10-20 18:45 ` Trond Myklebust 2018-10-20 19:14 ` jonsmirl 2018-10-20 19:14 ` jonsmirl 2018-10-21 8:27 ` Theodore Y. Ts'o 2018-10-21 8:27 ` Theodore Y. Ts'o 2018-10-21 9:23 ` Greg KH 2018-10-21 9:23 ` Greg KH 2018-10-20 19:24 ` Tim.Bird 2018-10-20 19:24 ` Tim.Bird 2018-10-20 20:07 ` Trond Myklebust 2018-10-20 20:07 ` Trond Myklebust 2018-10-21 0:13 ` Alan Cox 2018-10-21 0:13 ` Alan Cox 2018-10-21 6:19 ` Thomas Gleixner 2018-10-21 6:19 ` Thomas Gleixner 2018-10-20 20:13 ` James Bottomley 2018-10-20 20:13 ` James Bottomley 2018-10-20 13:51 ` [Ksummit-discuss] [PATCH 7/7] MAINTAINERS: Add an entry for the code of conduct Greg Kroah-Hartman 2018-10-20 13:51 ` Greg Kroah-Hartman 2018-10-21 21:20 ` [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document NeilBrown 2018-10-21 21:20 ` NeilBrown 2018-10-21 22:26 ` [Ksummit-discuss] " Josh Triplett 2018-10-21 22:26 ` Josh Triplett 2018-10-21 23:37 ` Theodore Y. Ts'o 2018-10-21 23:37 ` Theodore Y. Ts'o 2018-10-23 1:44 ` NeilBrown 2018-10-22 20:26 ` NeilBrown [this message] 2018-10-22 20:26 ` NeilBrown 2018-10-22 22:46 ` Theodore Y. Ts'o 2018-10-22 22:46 ` Theodore Y. Ts'o 2018-10-23 1:31 ` NeilBrown 2018-10-23 1:31 ` NeilBrown 2018-10-23 6:26 ` Dan Carpenter 2018-10-23 6:40 ` Al Viro 2018-10-23 6:40 ` Al Viro 2018-10-23 6:46 ` Dan Carpenter 2018-10-23 6:46 ` Dan Carpenter 2018-10-23 3:31 ` Al Viro 2018-10-23 3:31 ` Al Viro 2018-10-23 4:25 ` NeilBrown 2018-10-23 4:25 ` NeilBrown 2018-10-23 4:52 ` Al Viro 2018-10-23 4:52 ` Al Viro 2018-10-23 5:28 ` NeilBrown 2018-10-23 5:28 ` NeilBrown 2018-10-23 6:00 ` Al Viro 2018-10-23 6:00 ` Al Viro 2018-10-23 20:45 ` NeilBrown 2018-10-23 20:45 ` NeilBrown 2018-10-23 8:11 ` Theodore Y. Ts'o 2018-10-23 8:11 ` Theodore Y. Ts'o 2018-10-23 14:22 ` Rainer Fiebig 2018-10-23 14:22 ` Rainer Fiebig 2018-10-23 15:43 ` Theodore Y. Ts'o 2018-10-23 15:43 ` Theodore Y. Ts'o 2018-10-23 17:51 ` Rainer Fiebig 2018-10-23 21:14 ` NeilBrown 2018-10-23 21:14 ` NeilBrown 2018-10-24 12:16 ` Josh Triplett 2018-10-24 12:16 ` Josh Triplett 2018-10-25 21:14 ` NeilBrown 2018-10-25 21:14 ` NeilBrown 2018-10-27 1:10 ` Josh Triplett 2018-10-27 1:10 ` Josh Triplett 2018-10-28 21:48 ` NeilBrown 2018-10-28 21:48 ` NeilBrown 2018-11-01 16:45 ` Paul E. McKenney 2018-11-01 16:45 ` Paul E. McKenney 2018-11-01 21:11 ` Josh Triplett 2018-11-01 21:11 ` Josh Triplett 2018-11-02 13:13 ` Paul E. McKenney 2018-11-02 13:13 ` Paul E. McKenney 2018-11-01 21:50 ` NeilBrown 2018-11-02 13:33 ` Paul E. McKenney 2018-11-02 13:33 ` Paul E. McKenney 2018-11-03 8:36 ` NeilBrown 2018-11-03 8:36 ` NeilBrown 2018-11-03 17:37 ` Paul E. McKenney 2018-11-03 17:37 ` Paul E. McKenney 2018-11-03 21:06 ` NeilBrown 2018-11-03 21:06 ` NeilBrown 2018-11-03 22:23 ` Paul E. McKenney 2018-11-03 22:23 ` Paul E. McKenney 2018-11-02 13:52 ` James Bottomley 2018-11-03 9:19 ` Eric S. Raymond 2018-11-04 10:35 ` Geert Uytterhoeven 2018-11-04 10:35 ` Geert Uytterhoeven 2018-10-21 22:33 ` Joe Perches 2018-10-21 22:33 ` Joe Perches 2018-10-21 22:37 ` Randy Dunlap 2018-10-21 22:37 ` Randy Dunlap 2018-10-22 9:09 ` Rainer Fiebig 2018-10-22 9:09 ` Rainer Fiebig 2018-10-22 11:02 ` [Ksummit-discuss] " James Bottomley 2018-10-22 11:02 ` James Bottomley 2018-10-24 8:49 ` Laura Abbott 2018-10-24 8:49 ` Laura Abbott 2018-10-25 7:56 ` The linux devs can rescind their license grant visionsofalice 2018-10-25 8:19 ` [Ksummit-discuss] " Greg Kroah-Hartman 2018-10-25 8:19 ` Greg Kroah-Hartman 2018-10-25 19:39 ` Eric S. Raymond 2018-10-25 20:47 ` [Ksummit-discuss] " Theodore Y. Ts'o 2018-10-25 20:47 ` Theodore Y. Ts'o 2018-10-25 21:41 ` Eric S. Raymond 2018-10-25 22:12 ` [Ksummit-discuss] " NeilBrown 2018-10-25 22:12 ` NeilBrown 2018-10-25 22:38 ` Eric S. Raymond 2018-10-25 22:52 ` [Ksummit-discuss] " NeilBrown 2018-10-25 22:52 ` NeilBrown 2018-11-04 10:47 ` [Ksummit-discuss] " Geert Uytterhoeven 2018-11-04 10:47 ` Geert Uytterhoeven 2018-10-25 23:06 ` Al Viro 2018-10-25 23:06 ` Al Viro 2018-10-26 2:28 ` Eric S. Raymond 2018-10-26 5:49 ` [Ksummit-discuss] " Al Viro 2018-10-26 5:49 ` Al Viro 2018-10-27 6:52 ` visionsofalice 2018-10-27 7:32 ` [Ksummit-discuss] " Al Viro 2018-10-27 7:32 ` Al Viro 2018-10-27 16:18 ` [Ksummit-discuss] " Tim.Bird 2018-10-27 16:18 ` Tim.Bird 2018-10-27 22:09 ` Jiri Kosina 2018-10-27 22:09 ` Jiri Kosina [not found] ` <CAK2MWOtNUTjWy5pTcGco5DNurqNCc=9CfDJ-Ko-K+6HDC55ikg@mail.gmail.com> 2018-10-27 23:07 ` Eric S. Raymond 2018-10-27 23:40 ` Al Viro 2018-10-27 23:40 ` Al Viro 2018-10-28 21:13 ` NeilBrown 2018-10-28 21:13 ` NeilBrown 2018-10-25 23:32 ` Iván Chavero 2018-10-26 13:15 ` Eben Moglen 2018-10-26 15:50 ` Eric S. Raymond 2018-10-26 15:53 ` Eben Moglen 2018-10-26 17:32 ` visionsofalice 2018-10-26 18:31 ` Eben Moglen 2018-10-27 7:12 ` visionsofalice 2018-12-18 18:53 ` The linux devs can rescind their license grant. - Analysis published? visionsofalice 2018-10-26 10:34 ` The linux devs can rescind their license grant visionsofalice 2018-10-29 22:31 ` [Ksummit-discuss] " Bradley M. Kuhn 2018-10-29 22:31 ` Bradley M. Kuhn 2018-12-18 19:17 ` visionsofalice 2018-10-27 5:04 ` The linux devs can rescind their license grant. - Additional restrictive terms visionsofalice 2018-12-18 20:55 ` The CoC regime is a License violation " visionsofalice 2018-12-19 1:17 ` visionsofalice 2018-12-23 16:05 ` visionsofalice 2018-10-25 22:02 ` [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document NeilBrown 2018-10-25 22:02 ` NeilBrown 2018-10-25 8:06 ` [Ksummit-discuss] " Pavel Machek 2018-10-25 8:06 ` Pavel Machek 2018-10-25 11:20 ` Rainer Fiebig 2018-10-25 22:18 ` [Ksummit-discuss] " NeilBrown 2018-10-25 22:18 ` NeilBrown 2018-10-26 8:33 ` Rainer Fiebig 2018-10-26 22:40 ` [Ksummit-discuss] " NeilBrown 2018-10-26 22:40 ` NeilBrown 2018-10-27 11:49 ` Rainer Fiebig 2018-10-21 23:36 ` Eric S. Raymond
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=875zxt919d.fsf@notabene.neil.brown.name \ --to=neil@brown.name \ --cc=gregkh@linuxfoundation.org \ --cc=josh@joshtriplett.org \ --cc=ksummit-discuss@lists.linuxfoundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mishi@linux.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.