diff for duplicates of <1516830342.3073.50.camel@HansenPartnership.com> diff --git a/a/1.txt b/N1/1.txt index 48d2522..1fbdbc5 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -7,19 +7,19 @@ On Wed, 2018-01-24 at 19:26 +0000, Bart Van Assche wrote: > > the review process (I know, if we increase reviews as I propose in > > 1. we'll increase conflict on the lists on the basis of this > > observation), so I've been thinking about ways to de-escalate -> > it. The principle issue is that a review which doesn't just say +> > it.A A The principle issue is that a review which doesn't just say > > the patch is fine (or fine except for nitpicks) can be taken as -> > criticism and criticism is often processed personally. The way you +> > criticism and criticism is often processed personally.A A The way you > > phrase criticism can have a great bearing on the amount of personal -> > insult taken by the other party. Corny as it sounds, the 0day bot +> > insult taken by the other party. A Corny as it sounds, the 0day bot > > response "Hi Z, I love your patch! Perhaps something to improve:" > > is specifically targetted at this problem and seems actually to -> > work. I think we could all benefit from discussing how to give and +> > work.A A I think we could all benefit from discussing how to give and > > receive criticism in the form of patch reviews responsibly, > > especially as not everyone's native language in English and certain > > common linguistic phrasings in other languages can come off as rude > > when directly translated to English (Russian springs immediately to -> > mind for some reason here). Also Note, I think fixing the review +> > mind for some reason here).A A Also Note, I think fixing the review > > problem would solve most of the issues, so I'm not proposing > > anything more formal like the code of conflict stuff in the main > > kernel. @@ -34,37 +34,37 @@ On Wed, 2018-01-24 at 19:26 +0000, Bart Van Assche wrote: > same or another session: > * We all want a concensus about the code and the algorithms in the > Linux -> kernel. However, some contributors are not interested in trying to +> A kernel. However, some contributors are not interested in trying to > strive -> towards a concensus. If some contributors e.g. receive a request to +> A towards a concensus. If some contributors e.g. receive a request to > rework -> their patches, if they don't like that request and if the reviewer +> A their patches, if they don't like that request and if the reviewer > is -> working for the same employer sometimes they try to use the +> A working for the same employer sometimes they try to use the > corporate -> hierarchy to make the reviewer shut up. I think this is behavior +> A hierarchy to make the reviewer shut up. I think this is behavior > that works -> against the long-term interests of the Linux kernel. +> A against the long-term interests of the Linux kernel. Trying to intimidate people into doing what you want is a well known -social tool. The particular problem here is that it's the corporate -power structure that's used to effect the intimidation. That's pretty +social tool. A The particular problem here is that it's the corporate +power structure that's used to effect the intimidation. A That's pretty much outside of our control (unless we work for the same company), so there's not much we can do to stop it except say you shouldn't try to -intimidate reviewers. I suppose one practical policy could be +intimidate reviewers. A I suppose one practical policy could be demanding reviews from independent (meaning outside the corporate power structure) people. > * Some other contributors are not interested in achieving a consensus > and do -> not attempt to address reviewer feedback but instead keep arguing +> A not attempt to address reviewer feedback but instead keep arguing > or do what -> they can to insult the reviewer. +> A they can to insult the reviewer. Well, I think this fits neatly in the giving and receiving and receiving criticism bucket. The first rule of interacting with others is "never attribute to malice something which could possibly be -accidental". In the end it's up to the maintainer to arbitrate based +accidental". A In the end it's up to the maintainer to arbitrate based on their opinion of the merits of the review. James diff --git a/a/content_digest b/N1/content_digest index 28295a8..1d2f84a 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -19,19 +19,19 @@ "> > the review process (I know, if we increase reviews as I propose in\n" "> > 1. we'll increase conflict on the lists on the basis of this\n" "> > observation), so I've been thinking about ways to de-escalate\n" - "> > it.\302\240\302\240The principle issue is that a review which doesn't just say\n" + "> > it.A A The principle issue is that a review which doesn't just say\n" "> > the patch is fine (or fine except for nitpicks) can be taken as\n" - "> > criticism and criticism is often processed personally.\302\240\302\240The way you\n" + "> > criticism and criticism is often processed personally.A A The way you\n" "> > phrase criticism can have a great bearing on the amount of personal\n" - "> > insult taken by the other party. \302\240Corny as it sounds, the 0day bot\n" + "> > insult taken by the other party. A Corny as it sounds, the 0day bot\n" "> > response \"Hi Z, I love your patch! Perhaps something to improve:\"\n" "> > is specifically targetted at this problem and seems actually to\n" - "> > work.\302\240\302\240I think we could all benefit from discussing how to give and\n" + "> > work.A A I think we could all benefit from discussing how to give and\n" "> > receive criticism in the form of patch reviews responsibly,\n" "> > especially as not everyone's native language in English and certain\n" "> > common linguistic phrasings in other languages can come off as rude\n" "> > when directly translated to English (Russian springs immediately to\n" - "> > mind for some reason here).\302\240\302\240Also Note, I think fixing the review\n" + "> > mind for some reason here).A A Also Note, I think fixing the review\n" "> > problem would solve most of the issues, so I'm not proposing\n" "> > anything more formal like the code of conflict stuff in the main\n" "> > kernel.\n" @@ -46,37 +46,37 @@ "> same or another session:\n" "> * We all want a concensus about the code and the algorithms in the\n" "> Linux\n" - "> \302\240 kernel. However, some contributors are not interested in trying to\n" + "> A kernel. However, some contributors are not interested in trying to\n" "> strive\n" - "> \302\240 towards a concensus. If some contributors e.g. receive a request to\n" + "> A towards a concensus. If some contributors e.g. receive a request to\n" "> rework\n" - "> \302\240 their patches, if they don't like that request and if the reviewer\n" + "> A their patches, if they don't like that request and if the reviewer\n" "> is\n" - "> \302\240 working for the same employer sometimes they try to use the\n" + "> A working for the same employer sometimes they try to use the\n" "> corporate\n" - "> \302\240 hierarchy to make the reviewer shut up. I think this is behavior\n" + "> A hierarchy to make the reviewer shut up. I think this is behavior\n" "> that works\n" - "> \302\240 against the long-term interests of the Linux kernel.\n" + "> A against the long-term interests of the Linux kernel.\n" "\n" "Trying to intimidate people into doing what you want is a well known\n" - "social tool. \302\240The particular problem here is that it's the corporate\n" - "power structure that's used to effect the intimidation. \302\240That's pretty\n" + "social tool. A The particular problem here is that it's the corporate\n" + "power structure that's used to effect the intimidation. A That's pretty\n" "much outside of our control (unless we work for the same company), so\n" "there's not much we can do to stop it except say you shouldn't try to\n" - "intimidate reviewers. \302\240I suppose one practical policy could be\n" + "intimidate reviewers. A I suppose one practical policy could be\n" "demanding reviews from independent (meaning outside the corporate power\n" "structure) people.\n" "\n" "> * Some other contributors are not interested in achieving a consensus\n" "> and do\n" - "> \302\240 not attempt to address reviewer feedback but instead keep arguing\n" + "> A not attempt to address reviewer feedback but instead keep arguing\n" "> or do what\n" - "> \302\240 they can to insult the reviewer.\n" + "> A they can to insult the reviewer.\n" "\n" "Well, I think this fits neatly in the giving and receiving and\n" "receiving criticism bucket. The first rule of interacting with others\n" "is \"never attribute to malice something which could possibly be\n" - "accidental\". \302\240In the end it's up to the maintainer to arbitrate based\n" + "accidental\". A In the end it's up to the maintainer to arbitrate based\n" "on their opinion of the merits of the review.\n" "\n" "James\n" @@ -87,4 +87,4 @@ "see: http://www.linux-mm.org/ .\n" "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -4c80a596a991edcaa03a71171f82ae018ad0a8d1aa44d52feaa29b8e4c8ed95e +4adc8ecef205b2cf98becb4ee0396068e61d81de0ac9212994d9b28f22ef3a7b
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.