Change:
Widespread use of git reduces the exposure to a system failure because the primary repository is replicated in multiple locations. This includes hosted web pages; the content of web pages is <del> maintained as a branch in the main repository.  Maintaining a mirror of a repository that is hosted on GitHub is relatively simple and might be considered as a way to provide a backup for the primary repository. </del> <ins> maintained as a branch in the main repository.  As specified in GH- CONFIG, maintaining a mirror of a repository hosted on GitHub provides IETF-hosted backups for WG repositories. </ins> However, other information maintained on GitHub is more vulnerable to loss.  This includes issues and discussion on those issues,

Discussion:
See URL cc NAME I have reviewed draft-ietf-git-using-github-03 in preparation for IETF last call. The document is almost ready for LC. I have just a couple of substantive questions and suggestions to be answered before initiating the LC. I’ve also included some nits that should be resolved together with any last call comments. === Substantive comments === == General == Should there be some words in this document about how research groups might draw inspiration from this document, but that specific guidance for research groups is out of scope? == Section 2.1 == draft-ietf-git-github-wg-configuration settled on the naming convention ietf-wg- so this document needs to be updated to align with that. == Section 4.2 == Do you want to say a few words about who determines what constitutes a "substantial" change (or add a forward reference to Section 5 and provide some uniform statement about it there)? For example, might some WGs determine that anything non-editorial is substantial (also discussed in 5.3.2)? Whose call would that be? == Section 4.3 == Should we see if the secretariat can setup server infrastructure to support github-notify-ml for WGs that want it, and have a process whereby WGs can request support for it? This would imply changes to draft-ietf-git-github-wg-configuration rather than to this document, but I figured I would ask while I'm reviewing this. == Section 10 == I'd like to suggest: OLD Maintaining a mirror of a repository that is hosted on GitHub is relatively simple and might be considered as a way to provide a backup for the primary repository. NEW Maintaining a mirror of a repository that is hosted on GitHub is relatively simple and is specified in [GH-CONFIG] to provide IETF-hosted backups for WG repositories. == Nits == Section 1: Perhaps you should add a citation to URL on first use of Github. Section 1.1: Same comment as above, adding a citation for Git might be useful for completeness/posterity.

Section 1.4: s/does require/requires/ Section 3: s/accomplish the Charter/accomplish the charter objectives/ Section 3.1: s/Working Group Chairs that decide/Working Group Chairs who decide/ Section 3.4: You might want to clarify what you mean by text-based (some people might interpret it as documents being submitted in binary or something ... better to be clear) Section 4.1.2: "Restrictions on closing issues are generally not advisable until a document has reached a certain degree of maturity." This is a little vague. Perhaps you mean "Restrictions on who can close an issue"? Section 4.2: s/how they manage changes./how they manage changes amongst themselves./ Section 6: s/MAY request the creation of an Internet-Draft at any time/MAY request a revision of an Internet-Draft being managed on Github at any time/ Section 7: s/GitHub, mailing lists, and in-person meetings/GitHub, mailing lists, interim meetings, and IETF meetings/ Section 7: s/explicitly identify/identify/ Section 8: s/For a document that use/For a document that uses/ Section 9: s/that raises what a new issue/that raises a new issue/ Thanks, Alissa