Re: Fix made to https://chairs.ietf.org/en/documents/document-shepherding

Mahesh Jethanandani <mjethanandani@gmail.com> Tue, 05 November 2024 11:00 UTC

Return-Path: <mjethanandani@gmail.com>
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFDF8C1E7233 for <wgchairs@ietfa.amsl.com>; Tue, 5 Nov 2024 03:00:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xh-GqEhRalhX for <wgchairs@ietfa.amsl.com>; Tue, 5 Nov 2024 03:00:18 -0800 (PST)
Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08EAC1CAE6C for <wgchairs@ietf.org>; Tue, 5 Nov 2024 03:00:18 -0800 (PST)
Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-6ea85f7f445so25030707b3.0 for <wgchairs@ietf.org>; Tue, 05 Nov 2024 03:00:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730804417; x=1731409217; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=JyUAKEQCrwj++qmur96kbXB9IRgRsqmJka/bdFzn31M=; b=cDalL+5y9zEc/fYh3kfiqK2AYgFYTw1OXHA4p2yQMURJJnvyMMqOLBKAJVNEndhPjy i8P40bhL55WkQTM8224bO/zEBbQojZIRP8tuk7IBwS4Q/lWqWNwwN+tMO25NB6xlmr68 M5Ufv7f8vQZmPWxZaCvYJVs3vYv+zO+CtwlY4UKcn3zraZV1PUJ+X+UN0j3B4mXrZtgu wMzikm2Iqwt1RdiKRtgs+xFK2iCmfozhSbsfTUgtsp/KGthSaDJ3jwIgXW0q+th4ep47 CWYxXTLb5MGwsqeXqL/bg4HKmUqGDcgBw7R1DDzpQi9d/KzFwh+ye+4Y9ZvPOO1brQIk MTUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730804417; x=1731409217; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=JyUAKEQCrwj++qmur96kbXB9IRgRsqmJka/bdFzn31M=; b=LGXHD26pHDtGGCybQqXIIuAoA0Nkh45BJHe5eWbTydf/Nxb43OZ9GjVeFR3w6r6KI4 YasdnC57AtmfTxzK+6r+qNwMuU0ip8qoirrgY8CYwuuR6qTT5ZlJUjyPJHA33vHAsp3v 9jzZaIr8drsCGXNxlKYkV4e7EyjRKm+2Y8793GQGkECw19OOOWB8TTT3HPU7r/LqF55P ENgeFqcgksTz8O83wn/D3NXpAF9txUPIfD7Ip9yaKttsiAmE5FI1C0c5K55nKbJqIAQj UmTGrLWSJRPBiX3IUjimRKBTMUSIdkWZsahgGW/jR2UvC/Va5pXkund8czcj7HzgSkwz eiSA==
X-Forwarded-Encrypted: i=1; AJvYcCVZZkVrNBZ7gCN5FVd01+E2r1MiXU/X7lQWwXglU9um/+UBOhKlkMlfRxLmmWpbmjKKctztxak7kA==@ietf.org
X-Gm-Message-State: AOJu0YxLZI31h6w2G4rGvT2WP+z2ukrgkDGKs4bsBwa52D7qu0FHXY5j IpBlXBzLvaypRraPr1l0UaQy+ECYIdvKwCaNKGpAsM3tFpPGMW5k
X-Google-Smtp-Source: AGHT+IEZhqK6CozgkdMInI8ebkGAQ7oPFRFuSgzCV4LC34y3qVIpQ8B6/6ix48RMNqiNewuLvcpevg==
X-Received: by 2002:a05:690c:c94:b0:6ea:9d16:929a with SMTP id 00721157ae682-6ea9d172301mr68963477b3.4.1730804417292; Tue, 05 Nov 2024 03:00:17 -0800 (PST)
Received: from smtpclient.apple ([2001:67c:370:128:d167:5655:223a:4b21]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6d354187739sm58493356d6.132.2024.11.05.03.00.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Nov 2024 03:00:16 -0800 (PST)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <2A4E8113-5F7F-4F5D-9B08-24BF663C4373@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7D3E0240-C2B4-46C4-8C28-3FB3FC96F0AA"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\))
Subject: Re: Fix made to https://chairs.ietf.org/en/documents/document-shepherding
Date: Tue, 05 Nov 2024 11:00:14 +0000
In-Reply-To: <206dbf3e-cd28-4cb9-81e5-143dd3c05649@labn.net>
To: Lou Berger <lberger@labn.net>
References: <8fe0e301-38fe-4fb9-93fd-1eda4043ac73@labn.net> <7e7610fc-7ec3-4689-80a3-4baf2f165dad@labn.net> <Zyjm-4YsyAmGBeTZ@faui48e.informatik.uni-erlangen.de> <206dbf3e-cd28-4cb9-81e5-143dd3c05649@labn.net>
X-Mailer: Apple Mail (2.3654.120.0.1.15)
Message-ID-Hash: SPWODXXPSP3ZZWZN6QLJUWU6FDEP6LJJ
X-Message-ID-Hash: SPWODXXPSP3ZZWZN6QLJUWU6FDEP6LJJ
X-MailFrom: mjethanandani@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-wgchairs.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Toerless Eckert <tte@cs.fau.de>, Working Group Chairs <wgchairs@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
List-Id: Working Group Chairs <wgchairs.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/wgchairs/DPizTV4TTg0KN7YLQ5BGE3cb_fc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wgchairs>
List-Help: <mailto:wgchairs-request@ietf.org?subject=help>
List-Owner: <mailto:wgchairs-owner@ietf.org>
List-Post: <mailto:wgchairs@ietf.org>
List-Subscribe: <mailto:wgchairs-join@ietf.org>
List-Unsubscribe: <mailto:wgchairs-leave@ietf.org>

Hi Lou,

I am not sure what problem we are trying to solve here. Has there been a case of conflict that you have observed?

It is hard as it is to find good shepherds. Trying to limit who can be a shepherd would severely limit the ability of chairs to find good shepherds. My understand is that the chairs and the WG always have the ability to override a shepherd view of the document if they do not agree with it. Aren’t these views public for anyone to comment on?

And where does this stop? Should a chair not shepherd a document if one of the authors is from the same company? Should they be recusing themselves from providing comments on documents?

Cheers.

> On Nov 5, 2024, at 10:16 AM, Lou Berger <lberger@labn.net> wrote:
> 
> Hi Toreless,
> 
> Thanks for both good comments.  based on both comments, does anyone object to the following (I can do the wiki update once we close on the discussion):
> 
>      Per https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-on-document-shepherds-20101011/,
>     the IESG encourages the working group chair to select an
>     active working group participant that has strong understanding of
>     the document content, is familiar with the document history, and
>     is familiar with the IETF standards process. The Document Shepherd
>     of a working group document should not be an author or editor of
>     the document.
> 
>     Some working groups also avoid appointing Shepherds who are
>     affiliated with an author or editor of the document. Affiliation
>     should be evaluated on a case-by-case basis, e.g., individuals in
>     different divisions of a large company  may be considered to have
>     sufficient independence to permit a  Shepherd and a author from
>     the same company on the same document.
> 
> Thanks,
> 
> Lou
> 
> On 11/4/2024 10:23 AM, Toerless Eckert wrote:
> > On Mon, Nov 04, 2024 at 03:10:22PM +0000, Lou Berger wrote:
> >> In some of my working groups we recuse a co-chair from the Shepherd  role
> >> when that chair is from the same company as any author or editor (but not
> >> contributor). My questions are:
> >> 1) Do others follow this same practice in their groups?
> >>
> >> 2) I think the same policy should be applied to non-Chair Shepherds, do you
> >> agree or disagree?
> >
> > In general, that type of "independence" is a good weighing factor in deciding
> > on a Shepherd, but its really only weighing IMHO.
> >
> > We had a case, where the Shepherd was from the same company as some co-authors,
> > but came from a quite different department and had a good amount of more experience
> > primarily with IETF processes, but also likely some technology. When discussing
> > this, we chairs also felt that being from the same company allowed him to spend more time
> > on the review than might have been possible for other reviewers. And indeed that
> > was used excessivel to improve the text quality. And us chairs
> > also felt that there wher no technical conflict points in the WG and there where/are
> > enough other independent reviews that it was not necessary to select a shepherd
> > more on independence than those other beneficial technical criteria.
> >
> > Maybe in general: These type of decisions will have to be quite different based on the
> > degree of differences of opinion about a draft in the WG. If the overwhelming
> > feeling is that the WG wants this to be as good as possible and there are no
> > specific affiliation based conflicts, then it's a lot less important to
> > weigh independence higher than other factors.
> >
> > Cheers
> >     Toerless
> >
> >> Thanks,
> >>
> >> Lou
> >>
> >>
> >> On 11/4/2024 9:46 AM, Lou Berger wrote:
> >>> Hi,
> >>>
> >>> I'm not sure who is the authoritative owner/source to the "IETF Chairs
> >>> Resources" but there was an error on
> >>> https://chairs.ietf.org/en/documents/document-shepherding - that I just
> >>> fixed.  The text now say:
> >>>
> >>>     It is encouraged for a Shepherd to not be a Chair of the working
> >>>     group.  The Shepherd should have strong understanding of the
> >>>     document content, is familiar with the document history, and is
> >>>     familiar with the IETF standards process. The Document Shepherd of
> >>>     a working group document should not be an author or editor of the
> >>>     document.
> >>>
> >>> Which is based on the IESG statement (https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-on-document-shepherds-20101011/)
> >>>
> >>>     In fact, the IESG encourages the working group chair to select an
> >>>     active working group participant that has strong understanding of
> >>>     the document content, is familiar with the document history, and
> >>>     is familiar with the IETF standards process. The Document Shepherd
> >>>     of a working group document should not be an author or editor of
> >>>     the document.
> >>>
> >>> The page previously said:
> >>>
> >>>     It is considered generally preferable for a Shepherd to not be a
> >>>     Chair of the working group,
> >>>      or from the same organization/company as the Chair.
> >>>
> >>> I figured others may be interested in this change, or maybe even want to
> >>> disagree with it.
> >>>
> >>> Lou
> >>>
> >>>
> >
> 


Mahesh Jethanandani
mjethanandani@gmail.com