Re: [OAUTH-WG] Use of Version Control Systems for Draft Editing

Nat Sakimura <sakimura@gmail.com> Thu, 16 May 2013 08:44 UTC

Return-Path: <sakimura@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C4221F907E for <oauth@ietfa.amsl.com>; Thu, 16 May 2013 01:44:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Level:
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WI3f+gF4OPSG for <oauth@ietfa.amsl.com>; Thu, 16 May 2013 01:44:25 -0700 (PDT)
Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8457821F8F38 for <oauth@ietf.org>; Thu, 16 May 2013 01:44:24 -0700 (PDT)
Received: by mail-lb0-f170.google.com with SMTP id t13so102114lbd.1 for <oauth@ietf.org>; Thu, 16 May 2013 01:44:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type; bh=jhjIntGBRF0S4slVs3ZpWoNmV0Vm8l7Iq3V3asDqcwU=; b=0gF2AjTmCoK13V8BmGNfa7HqWAZIfNJ2H6pPyRwV/0taEogMwGX4v490x8NzYGVGaP NK2Z1PCIxF17P/NCIe41+95NRN7JXu3h05C1Bod6BdpxZL8wK4MgDVvg3Bvzt0ZiUBQ3 JRoNu9YA//Fl8rd3LyOS6ouz+XTCwobCz12KxK5y+AWsLvAv2PPUxI0gaOaCyyVCwcGD Swts6BiZ3oAx0CAOJY0QCRDBPyzfsmNm1DYKhIW7dOwIHhv3ZErKWGl9xSvmt6UQLOG3 Md2VB846WVhURLa9e8ejoNLgQBeLxClQNozu+X7bredXq4I2o7m3SD4mf5Lik47pTCLp nlpw==
X-Received: by 10.112.6.135 with SMTP id b7mr19372579lba.104.1368693863394; Thu, 16 May 2013 01:44:23 -0700 (PDT)
References: <trinity-7f0228f0-6e3c-489c-9db2-89dd0a0a7df2-1368432260949@3capp-gmx-bs52> <5190B512.6060903@cs.tcd.ie> <CABzCy2BnRmkMm25=egW6acRkYeGdB60i51ZghmxBG_JSx1hLAw@mail.gmail.com> <265449F1-D674-44CE-957B-204E765B6D15@mitre.org>
From: Nat Sakimura <sakimura@gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <265449F1-D674-44CE-957B-204E765B6D15@mitre.org>
Date: Thu, 16 May 2013 10:44:25 +0200
Message-ID: <-2191260347151674055@unknownmsgid>
To: "Richer, Justin P." <jricher@mitre.org>
Content-Type: multipart/alternative; boundary="14dae947303b88b76404dcd1df18"
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Use of Version Control Systems for Draft Editing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 May 2013 08:44:29 -0000

I am by no means suggesting IETF to use Vim/emacs. That is counter
productive. I was merely pointing out that one has to decide the diff
policy wisely.

I like XMLMind's XML2RFC. Too bad it became commercial product only.

Intelligent diffs would work fine. However, there have been push back to
that since that made it difficult for the users that just look at the web.

In IETF, we should take the rfcdiff, IMHO, so whitespace changes in XML
should not be an issue.

Nat

2013/05/15 22:11、"Richer, Justin P." <jricher@mitre.org> のメッセージ:

 I have already been using an approach like this for all of the drafts that
I edit, most notably the DynReg WG document and both the Introspection and
Chaining individual submissions. I run everything through my GitHub
repository here:

 https://github.com/jricher/oauth-spec/

 I use the issue tracker there to note down things that come up in the WG
conversations on the list, so that when I actually do get to go edit
things, I don't forget anything. Once or twice, I have gotten issues
submitted directly to github, but the actual conversation around any real
changes (beyond typos) always comes back to the list. I do think it would
be worthwhile to connect the mailing list to the notifications of the
tracker for official documents. It would be fairly easy to set up a GitHub
organization that's backed by the mailing list's address for notifications,
and I think other development platforms have similar capabilities.

 However, I completely disagree with ODIF's decision regarding editing
tools. I've made some edits to the OIDF specs myself, and I find the "plain
text editor" rule to be a draconian overreaction that makes creating good
edits tedious, slow, and error-prone. In my personal experience, good tools
like XML Mind's XML2RFC plugin are profoundly useful, and the formatting
artifacts they create are minimal and easily ignored. The diffs that are
tracked in Git are *far* from useless, and if you ask me, if you want to do
a *real* diff on these documents you'd use the rfcdiff anyway, which
ignores the XML formatting changes and focuses on the actual content. It's
not perfect either, but it's far from useless.

  -- Justin



 On May 13, 2013, at 9:08 AM, Nat Sakimura <sakimura@gmail.com>
 wrote:

 I am probably biased since I am the one who introduced ticket driven
version control to OIDF but it proved to be very valuable especially for
transparency purposes. Each changes are linked to the ticket so it is easy
to see why that change was made.

 As to the comments v.s. mailing list relationship is concerned, I think it
is possible to forward all the comments to the list, and in case of IETF,
it should do so.

 One feedback on the experience we had at OIDF is that XML Editing tools
changes all sort of formatting making the diff at bitbucket useless. So, we
had to resort to emacs/vim/ etc.

 my 2c.

 Nat Sakimura




2013/5/13 Stephen Farrell <stephen.farrell@cs.tcd.ie>

>
> Hiya,
>
> On 05/13/2013 09:04 AM, Hannes Tschofenig wrote:
> > Hi all,
> > the OpenID Connect had gained some experience with using version control
> systems
> > for editing specifications (and the use of issue trackers), see
> > http://openid.bitbucket.org/. Based on a recent discussion in the IETF
> (among
> > the working group chairs) I am wondering what your experience is with
> those
> > tools and whether you see value in using these tools for document
> editing in the
> > OAuth working group.
>
>  Sounds like a fine plan if the wg want to try it. Only thing I'd
> note is that it means editors need to be *very* careful to bring
> discussion back to the wg list when that's needed, since you will
> likely get comments in the version control environment that are
> not cc'd to the wg list. (The IETF will be considering generic
> solutions for that, if you're interested get involved with the
> tools team.) In turn, I suspect that means that wg chairs need
> to make sure there's an editor who really gets when a change needs
> to be discussed on the list and when its ok to just fix a typo.
>
> The httpbis wg have some experience doing this btw and have hit
> that specific issue of comments being made on github but not the
> list. There's a recent thread [1] that ends with good advice from
> the wg chair.
>
> And in case someone asks, reasons why we need the wg list cc'd
> include open-ness and to be clear as to what's an IETF
> contribution. There're probably more but these are enough;-)
>
> Cheers,
> S.
>
> [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0334.html
>
>
>
> > Ciao
> > Hannes
> >
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



 --
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
 _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth