RPC Wiki

• RPC forked the author's repo and edited the markdown file using PRs per section (38 total PRs).
• Each author query was included as an issue (15 total) - some later became PRs (see next point below).
• An issue was created for each document-wide/global edit to later be incorporated as a PR.
• The (single) author and ISE were invited as a collaborators.
• References were manually handled in XML after other PRs/Issues etc. resolved and markdown--> XML used.

This eleventh experiment is an Independent Stream document (one author, 28 pages, not in a cluster). The ISE sent mail (9/13/2023) requesting that this document be a GitHub experiment, as would be a good candidate to work out ISE processes. The author agreed prior to the document entering the queue.

• Database page
• ARO page
• GitHub repo for the I-D

In this experiment, the RPC forked the repo. Both pull requests and issue tracking were used.

• AUTH48 repo for RFC 9518
• forked Mark's repo so it was public to start (i.e., forked repos cannot be set to private)
• Contains:
  • rfc9518.xml
  • README.md
  • CONTRIBUTING.md
  • note-well.md

• draft-nottingham-avoiding-internet-centralization/issues
• Initial number of issuses: 15
• Issue labels:
  • rfced

• AUTH48 started 2023 Dec 6 and ended 2023 Dec 18. This document was published 2023 Dec 18.

• Using Issues to mention global edits and then PRs to implement them once authors agree.
• We experimented with the header and boilerplate material for Independent Stream documents in markdown (See header of the markdown file at https://github.com/rfc-editor/draft-nottingham-avoiding-internet-centralization/blob/rpc-main/draft-nottingham-avoiding-internet-centralization.md).

Author feedback: The author indicated that communication was clear and easy to follow, the issues were appropriately sized, and the labels for issues were helpful. He also noted that using GitHub was advantageous because “[i]t was easier to review changes and understand the state of the draft.” He also indicated that he “would love to end up with a pull request back to [his] repo only with the changes to the draft (not the README). But that's just a nice-to-have.”

The ISE indicated that the process could be improved:
“I was a little confused as to what and when to approve stuff.”
“It wasn't easy to follow because I probably wasn't correctly subscribed to issues.”
He indicated that the issues were appropriately sized and that the labels were useful. Overall, he didn't find the process more efficient than the current mail-based system, though he would like to experiment again after discussion with the RPC. He also noted that “this was a matter of getting used to it. I don't want to be too harsh on github because I think some of it really is my own incompetence.”