Effective discourse in the IETF

Ted Lemon <mellon@fugue.com> Wed, 03 July 2019 14:42 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A6212024B for <ietf@ietfa.amsl.com>; Wed, 3 Jul 2019 07:42:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcYLUQR_usBN for <ietf@ietfa.amsl.com>; Wed, 3 Jul 2019 07:42:39 -0700 (PDT)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13CDC12032A for <ietf@ietf.org>; Wed, 3 Jul 2019 07:42:23 -0700 (PDT)
Received: by mail-qt1-x82a.google.com with SMTP id z4so96240qtc.3 for <ietf@ietf.org>; Wed, 03 Jul 2019 07:42:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=f0bSFkZzGPxeHXOILPkwZY5FiX2m5xdRRdv2fvrl03E=; b=pyhhMxrJSsVyA4ym02sP2AekbtQGtd1HmLoz+tAwXw/YMW/an5dI1lkJKMVvZIpUZ9 kN8BE6OXRNJkfd+RfRqEhhTWli0lfzyuSsTjwL4FsZ2TKrZvocatMzus0DPF15lnTP/0 AHKF24vGk2plGRPLb5NP6ap4KAjTUqWMi7wALHkoREiYjnJUY+YXJs9GqUyXjtDLbkip cXP4YC3vNz/5H02wN4PVsj2KsnGWVZwTUSmtR4lRQYjn/CNoJSw/n94j9PVNUxztR8BE 9nnhotEYiVTE2rU0zqZcnaJxyRjElFsBGaIDXquqmzJir4W4hW2bAG3JV9FB0y5r7QpB vdOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=f0bSFkZzGPxeHXOILPkwZY5FiX2m5xdRRdv2fvrl03E=; b=cAjD8aOT+an8LKXNbNcbdRoG0x/Vz+Go0aYcS9WHUn6+2TUclfXu5KChXjOVEKa3E9 S3nPEDflr+EGcwGWf6+snicXicDnnkwiYGyuZvaIerUaMV02Na726YHpBDhnm9Hytx1c w6xDd0OX7il8V/JaVtjm+3r+lshhxn3g4MpVrvLdrG4ZDv7oJ1e6reUBN5yUM93UC2Pi rPafkdNXRkAagqwFnTgDXXZY75ri7gezTczXMJfEjkKXSz8ajfzz7U1LT1+BY+98ezfo UEnIipA+i2EYqleHsqCfkv1MvKq1Z/V/lbJ9PM0xeH8G5oxmJrl47ODSMgIYIKJyNHGT /nYg==
X-Gm-Message-State: APjAAAV4krCYfmMqAHjfL1pxxJEgGzOPA8PRSIldUuI1FEHS5lQAvAXh Na53WHTFdMEnnmkRbYVt+9CstQ==
X-Google-Smtp-Source: APXvYqxST/qOZdYA63WuRQIgmuaATeWG1knhSGN7HB+V3gG29w2+QcBa/9NQ2JKiIYppnozp+dcbvQ==
X-Received: by 2002:ac8:1a9d:: with SMTP id x29mr31478035qtj.128.1562164941781; Wed, 03 Jul 2019 07:42:21 -0700 (PDT)
Received: from ?IPv6:2001:470:c1a2:1:a062:1585:ff05:9bdc? ([2001:470:c1a2:1:a062:1585:ff05:9bdc]) by smtp.gmail.com with ESMTPSA id f20sm925576qkh.15.2019.07.03.07.42.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2019 07:42:21 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <F86FDC5A-AF66-492E-A1FC-678486C26065@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_40C6D994-A7B4-4BD6-A1A2-F2AE815E92A3"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Effective discourse in the IETF
Date: Wed, 03 Jul 2019 10:42:18 -0400
In-Reply-To: <20190703141309.GX49950@hanna.meerval.net>
Cc: Marc Petit-Huguenin <petithug@acm.org>, John Leslie <john@jlc.net>, ietf@ietf.org
To: Job Snijders <job@ntt.net>
References: <20190628214503.GC30882@kduck.mit.edu> <7e5167bf-8167-bf81-981f-662d6da6f1ab@comcast.net> <20190628232206.GC10013@kduck.mit.edu> <e7bf71c3-7842-8699-1f56-36ffa823da99@comcast.net> <20190701223914.GK13810@kduck.mit.edu> <bad99f11-0d66-4aba-72ef-b4b648470753@comcast.net> <34A581FE-BCFA-4FDD-A626-372E036BD79A@cooperw.in> <20190703125524.GB98598@verdi> <c24b3857-fa3e-46a9-f55b-dd160250f290@acm.org> <2807ff5a-7fd3-65cc-5574-ae05df6c622c@acm.org> <20190703141309.GX49950@hanna.meerval.net>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/BeCZkcjreo7u4Bnwlv78ai_1NuQ>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2019 14:42:43 -0000

> When person A consents to receiving communication in a specific style
> from person B, it doesn't mean that person C, D and E who observe the
> communication agreed to person's B conduct towards person A. Perhaps
> Crocker's Rules have value in private communication between consenting
> adults, but not in a public forum. We can't know how conduct in context
> of Crocker's affects person C, D, and E or even discourages them from
> participating. We have to be careful when making assumptions.

I don’t entirely disagree with you, Job.  And yet at the same time there is an essential problem here, and it doesn’t do to paper it over.

Here is the problem: the IETF has long had a culture that is consistent with what I guess we can call Crocker’s rule.   That is, we tend not to engage in self-censorship.  This creates a certain set of problems—people don’t always receive the honest criticism they hear generously, and part of the reason they don’t is that it’s often expressed in ways that are rather harsh.

And yet, I think it’s indisputably true (but please, feel free to dispute the point!) that despite the shortcomings of this method as it applies to inclusiveness, it does work.   And it is responsible for our past successes.

If the IETF completely goes away from this model of discourse, I think we will fade into obscurity.  At the same time, I think the point has been made in the past, and you made it just now, that harsh public criticism discourages participation from those who do not handle harsh criticism well.   This is a real problem, and we shouldn’t minimize it.

So the question is, is it possible for us to do better?   Can we do what worked for us in the past, but differently enough that we successfully include speakers who would be silenced by harsh public criticism?  Is there a way to practice Crocker’s rule that doesn’t discourage participation?

I think that if participants want to never hear a critical word, that is the wrong heuristic.  We simply can’t succeed if we don’t allow for criticism, and it can’t be okay for someone to reject or “not hear” criticism.

I would suggest that people who are interested in this topic pick up a copy of the book “Thanks For The Feedback”: https://www.penguinrandomhouse.com/books/313485/thanks-for-the-feedback-by-douglas-stone-and-sheila-heen/9780143127130/

Another excellent book to read on the same topic is “The Art of Possibility”: https://www.goodreads.com/book/show/85697.The_Art_of_Possibility

The essential point that Marc expressed in Crocker’s rule is that it is a practice.  I think there’s a tendency to think that people can just show up to the IETF and participate without doing a practice: that the IETF should be a safe space for anybody, no matter how they receive criticism, to float about and try to do things.

The IETF can’t function that way.   We have to practice.  This is not a social club.  This doesn’t mean that we should be unkind to each other: we should definitely do our best to be kind.  But being kind isn’t always being nice, and being nice can’t be the standard of discourse that the IETF follows if we wish to continue to do good work.