SAA Do's and Don'ts

Michael StJohns <mstjohns@comcast.net> Mon, 02 September 2019 20:11 UTC

Return-Path: <mstjohns@comcast.net>
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 475C812008D for <ietf@ietfa.amsl.com>; Mon, 2 Sep 2019 13:11:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 PLdB7SIvqMCM for <ietf@ietfa.amsl.com>; Mon, 2 Sep 2019 13:11:57 -0700 (PDT)
Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E56812003E for <ietf@ietf.org>; Mon, 2 Sep 2019 13:11:57 -0700 (PDT)
Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-03v.sys.comcast.net with ESMTP id 4sSVio7SODwlx4sg8iSnnJ; Mon, 02 Sep 2019 20:11:56 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1567455116; bh=uRbrJlch1IwSmAKwWGWavb2yf8PjQBeLNuCTtkWLx04=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=AAmBp5oUn+SIAn8Yv3VSGyJCx7T3FKzxRK85SAr3Q0kMnRtkZq7TEhzk8B8pwF7nl tALL0WymVgjGst4oqFmLFoVx3gCq49WT1Ic2iRilF5RucnuhXqJZ3sApofGHu0biJa qzkTkrimsvoHG9MlNXWSRpp9TD9/DsW22dQkSCLT6JfWkxxAHWgPPGv2f2/u4968GJ Kfy5PxAjdyrUMxmPrOfl89JIB1sQrjHH+DnWSjfD9fe5hq0kpFomR7Sk5bqqdmxaK1 upqlAQ6BRLXB3ftHfvNrfQASovHPswuBD5VHPw8l2qK46YSqpmuYTlPAt1UVpUCl4s Jx648myWkqByw==
Received: from [IPv6:2601:152:4400:437c:208d:2fda:9bb0:ed54] ([IPv6:2601:152:4400:437c:208d:2fda:9bb0:ed54]) by resomta-po-15v.sys.comcast.net with ESMTPSA id 4sg7icgbDtQ9t4sg8iV0U8; Mon, 02 Sep 2019 20:11:56 +0000
X-Xfinity-VMeta: sc=-100;st=legit
Subject: SAA Do's and Don'ts
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: ietf@ietf.org, Adam Roach <adam@nostrum.com>
References: <964a7d97-f146-4d2e-aa3e-d39fc08f6f76@Mikes-IPhone> <20190901195210.GA27269@kduck.mit.edu>
From: Michael StJohns <mstjohns@comcast.net>
Message-ID: <f4a03464-9c9d-9ee5-088a-586e2bb326b1@comcast.net>
Date: Mon, 02 Sep 2019 16:11:55 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <20190901195210.GA27269@kduck.mit.edu>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/pKBtsdVwLY3k8dkml3Wy3oANAJU>
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: Mon, 02 Sep 2019 20:11:59 -0000

Hi Ben - inline

On 9/1/2019 3:52 PM, Benjamin Kaduk wrote:
> Hi Mike,
>
> I'd like to follow up on that more -- my recollection is that I was
> explicitly not attempting to advocate a particular position, and was rather
> trying to foster effective communication in a stressful environment that
> was prone to a breakdown of communication.  I'd like to better understand
> how and why I failed to do so, so that I can do better in the future.

There were a number messages that were of concern to me,

(private to me)  6/28 9:44PM Re: RSE Independence -

(public) 7/1 6:43PM  Re: RFC Series Editor Resignation

(public) 8/1 8:05PM Re: RFC Series Editor (RSE) Statement of Work


While none of these were completely over the line into advocacy, they 
were jarring.   E.g. "How dare he tell me not to talk and then asks a 
question on the same topic" type jarring.   I think if you're acting as 
the SAA on a topic, you need to limit your interactions to that.  I 
understand you've been placed in a difficult spot in that you're still 
an SAA long after you joined the IESG, but you have to serve all your 
masters as best you can.


I came up with a number of do's and don'ts for the SAA during this 
process.  I may eventually write and ID, but here's what I had by the 
end of this.

1) Do:  Avoid acting as an SAA on a topic in which you might have even 
the smallest perception of conflict of interest; err on the recusal side.

2) Don't: Condemn in public without first trying to de-escalate an issue 
in private.

3) Do: Take people at their word.  Pay attention to what the community says.

4) Don't: Act on your own initiative.  Wait for a complaint to be made 
and act on it.  Complaints need to be public.  In other words, being 
outraged on the behalf of someone who isn't actually bothered by a 
comment directed at them does nothing but reduce the authority of the 
SAA.  In other words, don't substitute your opinion(s) for community 
consensus.

5) Don't: Confuse "unprofessional language" with "telling truth to 
power".  In other words, if the comment you have a concern with is 
directed to one or more of the leadership, consider first:  Is it true 
or is there a reasonable interpretation of the facts which could make it 
true?   Does the comment implicate behavior of the leadership that may 
be counter to their duty to the community? Does the comment seek 
information that has not been forthcoming? Does the comment attribute 
behavior to the leadership collectively or individually that is 
supported by the public facts?  Could the leadership resolve the comment 
by being forthcoming with the facts as they know them?  Have they 
declined to do so?   To be more blunt:   Lying, being disingenuous, 
deflecting, distracting, ignoring are unprofessional; calling out lying, 
disingenuousness, deflection, distraction, and ignoring when there is 
substantial indication of one of these is not only not unprofessional, 
but required in a consensus based community for the community to 
continue to operate.

6) Don't: Engage in an argument with the originator of the comment.  If 
they've been warned AND you have community (and not just I*) support, PR 
them as appropriate.

7) Do:  Be fair and impartial.  If both sides of a discussion have 
stepped over the line, use exactly the same process with each of them to 
resolve the issue.

8) Related to 1:  Don't be a member of the I* and the SAA simultaneously.

9) Don't: Act as the mailing list policy police.  If consensus has 
arisen that it's time to take the discussion elsewhere, or that a topic 
is off-topic for a list and that's abused time and again by one or two 
people then feel free to make a private comment to them to move.


>
> My default assumption would be that it's best to have that follow-up
> offlist, but I am not going to attempt to impose my preference on you.


If you send me a public message, you're mostly going to get a public 
response.


Later, Mike

>
> Thanks,

>
> Ben
>
> On Sat, Aug 31, 2019 at 09:15:00PM -0400, Michael wrote:
>> Ben - specifically in the discussion that prompted Alissa to threaten to PR me.
>>
>> Mikr
>>
>> Sent from XFINITY Connect Mobile App
>>
>> ------ Original Message ------
>>
>> From: Adam Roach
>> To: Michael StJohns, ietf@ietf.org
>> Sent: August 31, 2019 at 9:06 PM
>> Subject: Re: Sergeant-at-Armss and New proposal/New SOW comment period
>>
>> On 8/31/19 4:42 PM, Michael StJohns wrote: > Adam - Hyperbole at this point is not helpful. Specifically "no > supervision" does not come even close to what we've been asking... I'm sorry if that came across as hyperbole. I'm honestly trying to probe at what the community thinks RFC 3005 provides for. If there's some legitimate authority granted (by what language?) to someone (whom?) to provide such shepherding, I'm curious about what people think that looks like. The language that Bob cites, on its face, implies that it does not exist. I was simply trying to clarify that such was the point he was making. The rest of your points are reasonable, and as long as no one else is objecting to the possibility of having this conversation on IETF territory [1] -- rather than a venue hosted by the RFC Editor -- then I'm happy to drop attempts to redirect the conversation. We've heard jurisdictional complaints in the past, and I'm simply trying to avoid them this time around. I have one questio
>> n for you: > The SAA should not participate in a conversation that it expects to > have oversight on. Listening is fine, advocacy for one side or > another is pretty much disqualifying in acting as the SAA for that > topic as SAA decisions could be seen to be tainted by bias. I understand the principle you're laying out. Your phrasing implies that you've seen instances of this happening, which I would find out of character for either Matthew or Benjamin. Have you seen this happening? Or are you just trying to ward off future issues? /a ____ [1] Its impacts on the IRTF and ISE notwithstanding