Change:
changes from a fork (or any branch) into their copy. Editors SHOULD make pull requests for all substantial changes rather <del> than committing directly to the "master" branch of the repository.  A pull request creates an artifact that records the reasons for changes and provides other contributors with an opportunity to review the change.  Pull requests that address substantive issues SHOULD mention the issue they address in the opening comment. </del> <ins> than committing directly to the "master" branch of the repository. See mature-documents for discussion on what constitutes a substantial change.  A pull request creates an artifact that records the reasons for changes and provides other contributors with an opportunity to review the change.  Pull requests that address substantive issues SHOULD mention the issue they address in the opening comment. </ins> This document assumes that there is a unified effort on a document, all concentrated on a git "master" branch.  More

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