[rfc-i] feedback note, was: [IAB] draft-iab-xml2rfc-03, "1.3.3 Elements and Attributes Deprecated from v2"

julian.reschke at greenbytes.de (Julian Reschke) Wed, 16 March 2016 18:45 UTC

From: julian.reschke at greenbytes.de (Julian Reschke)
Date: Wed, 16 Mar 2016 19:45:42 +0100
Subject: [rfc-i] feedback note, was: [IAB] draft-iab-xml2rfc-03, "1.3.3 Elements and Attributes Deprecated from v2"
In-Reply-To: <56E998AE.2060407@alum.mit.edu>
References: <56E85AA1.2060002@gmx.de> <01B2F0F9-1664-43D9-B95A-883AC38B973F@cisco.com> <E218CD5C-DDF6-4826-A983-EA2E305EDFF0@vpnc.org> <56E90FF5.2010003@gmx.de> <C0F3698C-42E2-4BDB-B8C2-1C590130F152@vpnc.org> <56E992D4.1070303@gmx.de> <56E998AE.2060407@alum.mit.edu>
Message-ID: <56E9A9D6.4060100@greenbytes.de>

On 2016-03-16 18:32, Paul Kyzivat wrote:
> On 3/16/16 1:07 PM, Julian Reschke wrote:
>
>> That said, I believe every Internet-Draft should have an editorial note
>> saying how feedback should be provided, and where the editor's copy
>> resides... (and yes, most authors don't, and I really have no idea
>> why...)
>
> The point about feedback makes sense to me, but why is the location of
> the editor's copy relevant? IMO the transition from version -nn to -nn+1
> can be viewed as an atomic action that occurs at the time version -nn+1
> is submitted.

Right. Pointing to an editor's copy / repo / issue tracker makes sense 
in case the editor wants to provide that information. For instance, it 
can be useful to check whether a certain issue is already known, in 
which case it wouldn't need to be reported again.

> I realize that there is an evolving practice of keeping the editor's
> copy on github and allowing multiple editors to contribute to it there,
> thus creating interim versions between -nn and -nn+1. *If* that is so,
> does it really need to be *public* if it is only for communication
> between the multiple listed authors/editors of the document?

It depends, for instance on the intervals in which drafts are submitted.

> I find it somewhat disconcerting when a reference to the github version
> is made public. It feels like it is then serving as an alternative
> process to publishing new versions. But it then requires different
> techniques to figure out what is going on, and to comment on changes.
> Such comments are not tracked in the same way and don't get the same
> level of public scrutiny.
>
> *If* such a technique is to become mainstream then a documented set of
> tools, procedures, and policies should be created around it.

Again, it depends. My intent wasn't to encourage doing work like that; 
it was just about pointing to it when it is the case (such as for the 
draft being discussed).

Whether a working group allows feedback/discussion on places other than 
the WG's mailing list is a separate topic (currently being experimented 
with in at least one WG).

Best regards, Julian