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

Benjamin Kaduk kaduk at mit.edu
Sat Feb 23 14:21:21 PST 2019


On Fri, Feb 22, 2019 at 09:57:58AM -0800, Heather Flanagan wrote:
> 
> 
> > On Feb 22, 2019, at 7:52 AM, Ted Lemon <mellon at fugue.com> wrote:
> > 
> > On Feb 21, 2019, at 8:10 PM, Eric Rescorla <ekr at rtfm.com <mailto:ekr at rtfm.com>> wrote:
> >> On the one hand, it was quite painful.
> > 
> > You’re the second person to say this, so I assume it’s true, but it’s also surprising.   It would be helpful if (perhaps this has already been done) there could be a writeup of what about the process of using github was painful.   We aren’t constrained to either choosing to use github or do nothing to improve the process, and your point about auth48 changes resonates for me too.   If we understood why Github didn’t make things better, or what things about Github made things enough worse that the things Github made better weren’t enough, that would be helpful.
> > 
> > _
> 
> 
> 
> 
> ekr has posted his impressions of the GitHub experiment with the RFC Editor, which I’ve seen and is useful feedback. From the point of view of the editors, however, the experience of what worked and what didn’t was somewhat different. We posted our feedback to the IESG and the tls-chairs list.

I was also paying close attention to that experiment, and from what I saw
it definitely seemed like the high-volume stream of github notifications
was somewhere near overwhelming for the RPC staff that were on the
receiving end.  The internal discussions amongst authors, chairs, and AD
were all going into that email stream, and it became hard to tell when an
issue was resolved, and what the resolution was (at least some of the
time).

So I'm not terribly gung-ho about bringing the copyeditors directly into a
github workflow unless they have other reasons to be working with git
and/or pull requests, since the added burden doesn't give them particularly
great benefits in return.

That said, github can still provide great value during AUTH48 to the
authors/chairs/ADs that are used to it, for their internal discussions.  I
think we just saw that for draft-ietf-acme-acme (I saw the emails go by but
didn't get to actually look at the pull requests), but it seemed to be
preserving the benefits of the github workflow without drowning the
copyeditors in notifications.

> One other point - we need to continue this conversation about how to improve AUTH48 for the authors. In much the same way that when I first started, the majority of input I received was that the format was the biggest pain point that needed attention, what I’m hearing now is that AUTH48 is the next big area to target. While I'm not ready to revive the experiment given where things stand with the format work (more on that in the next few weeks) this is definitely something that I’m hearing as both urgent and important.

Thank you for hearing this and reporting back.

-Ben


More information about the rfc-interest mailing list