Re: RANT: posting IDs more often -- more is better -- why are we so shy?
John C Klensin <john-ietf@jck.com> Fri, 03 March 2017 14:23 UTC
Return-Path: <john-ietf@jck.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 18C59129583 for <ietf@ietfa.amsl.com>; Fri, 3 Mar 2017 06:23:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
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 i3ebWRlPds6Q for <ietf@ietfa.amsl.com>; Fri, 3 Mar 2017 06:23:20 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266A7129547 for <ietf@ietf.org>; Fri, 3 Mar 2017 06:23:19 -0800 (PST)
Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1cjo73-000FWt-VD for ietf@ietf.org; Fri, 03 Mar 2017 09:23:17 -0500
Date: Fri, 03 Mar 2017 09:23:10 -0500
From: John C Klensin <john-ietf@jck.com>
To: "ietf@ietf.org Disgust" <ietf@ietf.org>
Subject: Re: RANT: posting IDs more often -- more is better -- why are we so shy?
Message-ID: <ED57F388B27F7F5D5EC87B3A@PSB>
In-Reply-To: <434ad124-e46c-fab9-9859-78ac34621096@gmx.de>
References: <14476.1488384266@obiwan.sandelman.ca> <CAHw9_iKuZrxD=51QadPPnuofUdAeaHPQ4JvONz5Bno3HTAi71A@mail.gmail.com> <434ad124-e46c-fab9-9859-78ac34621096@gmx.de>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.70
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/FXSEChdNi0yjVixWvtizo7mCxtU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 03 Mar 2017 14:23:21 -0000
An observation on part of this thread, stimulated by some recent experiences... As people think about what should go where and how rapidly, it is easy to forget two things about working group documents. First, the people we call authors are supposed to be reflecting WG decisions and preferences, not their own, and are accountable to WG chairs in the latter's capacity as interpreters of WG consensus. Situations and preferences differ as do WG styles of operation, but, for some situations, that responsibility may justify semi-private "did I get this right?" checking and/or wanting a draft to reflect all of the conclusions from a given WG meeting or email thread rather than having those changes posted incrementally and without context. Second, we often end up with co-authors (or co-editors) on a given document and do so for a wide variety of different reasons. For example, when a document is a revision of an earlier RFC, authors of the previous version may be listed as authors on the new one as a courtesy even if they are not actively participating editing the revision or even in the WG (whether that is appropriate is another discussion). However, there are also cases in which two or more author-editors are active at the same time, passing the virtual pen back and forth or otherwise collaborating in a fairly dynamic way. For those cases, "are these changes ok with you?" and "did I miss anything important?" checks are appropriate and often result in document improvements and saved WG time. Either of those situations can justify a delay of some days in getting an I-D posted -- longer than pushing micro-changes to github or equivalent. They also provide further justification for a snapshot-based model. I would suggest that, if delays for these reasons are weeks (or longer) rather then days, the WG may have a management problem, but that, too, is a almost entirely a separate issue. john
- RANT: posting IDs more often -- more is better --… Michael Richardson
- Re: RANT: posting IDs more often -- more is bette… Kathleen Moriarty
- Re: RANT: posting IDs more often -- more is bette… Patrick McManus
- Re: RANT: posting IDs more often -- more is bette… Brian E Carpenter
- Re: RANT: posting IDs more often -- more is bette… ned+ietf
- Re: RANT: posting IDs more often -- more is bette… John C Klensin
- Re: RANT: posting IDs more often -- more is bette… Patrick McManus
- Re: RANT: posting IDs more often -- more is bette… Joe Touch
- Re: RANT: posting IDs more often -- more is bette… Michael Richardson
- Re: RANT: posting IDs more often -- more is bette… Carsten Bormann
- Re: RANT: posting IDs more often -- more is bette… Michael Richardson
- Re: RANT: posting IDs more often -- more is bette… Joe Touch
- Re: RANT: posting IDs more often -- more is bette… Warren Kumari
- Re: RANT: posting IDs more often -- more is bette… tom p.
- Re: RANT: posting IDs more often -- more is bette… Julian Reschke
- Re: RANT: posting IDs more often -- more is bette… John C Klensin
- Re: RANT: posting IDs more often -- more is bette… Michael Richardson
- Re: RANT: posting IDs more often -- more is bette… Eric Rescorla
- Re: RANT: posting IDs more often -- more is bette… Eric Rescorla
- Re: RANT: posting IDs more often -- more is bette… Brian E Carpenter
- Re: RANT: posting IDs more often -- more is bette… Eric Rescorla
- Re: RANT: posting IDs more often -- more is bette… Brian E Carpenter