Select a document with the following characteristics:

• has a GitHub repo with the following features used: issue tracking, PRs
• XML source
• 25 pages or less
• not part of a cluster
• not time sensitive
• willing authors and AD

The RPC will fork the author's document repo.

The RPC will create PRs for copy edits and questions with suggested text.

The RPC will add open questions as issues.

The RPC and author will work in this fork during AUTH48.

The RPC will make formatting edits only after the author has approved copy edits.

Comments related to draft-ietf-acme-subdomains:

* From Richard Barnes <rlb@ipv.sx>: 
I am all for using GitHub for AUTH48, but we should do it properly, 
with all text changes being made by the RPC making pull requests 
against the document repo [1].

[1] https://github.com/upros/acme-subdomains

* From Owen Friel <ofriel@cisco.com>:
I just got wind of the current RPC github process, where RPC creates 
a new repo that they control and makes their changes there, and then 
the document authors/editors (with their own repo where the original 
document lives) have to create PRs against the RPC repo to revert any 
changes that RPC make.

This is a github anti-pattern, and I have never heard of anyone using 
github like this for any purpose anywhere. Why can the RPC not submit 
PRs against the document's original repo?

If trialing github for AUTH48 means we have to follow that crazy process, 
then I am not in favor of that at all.

* From Michael Richardson <mcr@sandelman.ca>:
I don't want a github process :-) 

I want a *GIT* process, that starts from our existing repos. I think that 
RPC should run it on their own gitlab.

At the end of the day, if the authors are using github, they can take the git
repo back from the RPC and merge it, or not.

Return to the GitHub AUTH48 experiments overview