[rfc-i] [Ietf-and-github] RFC Editor & Github

Heather Flanagan rse at rfc-editor.org
Fri Feb 22 12:53:39 PST 2019

> On Feb 22, 2019, at 12:28 PM, Carsten Bormann <cabo at tzi.org> wrote:
> On Feb 22, 2019, at 18:56, Bret Jordan <jordan.ietf at gmail.com> wrote:
>> For other SDOs that I work with, that use Git, I can attest to this and doing editorial work via Git can just be a show stopper for many.
> <CS snob hat>
> Maybe that’s not a bug, but a feature.
> </CS snob hat>
> More seriously speaking, we need to be more inclusive than that.
> (Please also note that using RFCXML as our primary submit format is a much taller “you have to be this tall to ride” than requiring Git would be.)

While a bit of an apples-to-oranges comparison, the point is accurate. We (the RFC Editor and the community) are depending on community authoring tools and the id2xml tool to make this easier.

> It is almost always a bad idea to force tools on someone.
> (It is, however, often beneficial for both parties when the more experienced one exerts heavy nudging.)
> I would expect that a process that would have the RPC use Git would still provide a “manual” interface like the one that we use now.  Participating in the Git-based process as an author would be an option that is more natural to take for the repeat author than required of everybody.  As Ekr noted, exposing editing steps in individual commits can be highly useful — both to the authors and to chairs/shepherds/ADs/WG members watching the process.  (This would be a model where the RPC “owns” the document during AUTH48 and the authors are the reviewers and occasional PR submitters.)

Keep in mind that the more interfaces that the RPC has to maintain, the more challenging our work becomes, and the more costly in terms of time and resources to do it. It raises the level of training required to bring on new editorial staff, something that is already a known challenge given the tools and editing style the community requires. It potentially requires jumping from one style to another depending on the preference of one author to the next. 

All that said, this isn’t a “no” but it is a “costs need to be considered.” Is the community ready to pay in time/money to develop tools, and/or pay in time/money to keep the rate of publication what it is today (or allow for slower, require faster, and so on)?

> (I’m using “author” here to distinguish that role from the “editor” at the RPC side; we have the strange habit of calling authors “editors” in the IETF, which I’m not trying to bring up for discussion here.)

(Also not opening up the discussion, but in case it helps: You could refer to the RPC editors as copyeditors. It’s more accurate than the generic editor term.)


More information about the rfc-interest mailing list