Change:
Please pay special attention to b872e53 and e74ba45 when reviewing this.
LGTM with some proposed simplifying text.

Discussion:
GitHub is a service operated at https://github.com/ [5].  GitHub provides centralized storage for git repositories.  GitHub is freely <del> accessible on the open Internet, albeit currently only via IPv4. </del> <ins> accessible on the open Internet. </ins> <del> GitHub provides a simplified and integrated interface to not only git, but also provides basic user management, an issue tracker, associated wikis, project hosting, and other features. </del> <ins> GitHub provides a simplified and integrated interface to git, and also provides basic user management, an issue tracker, associated wikis, project hosting, and other features. </ins> There are a large number of projects at GitHub and a very large community of contributors.  One way in which some IETF Working Groups have benefited is through increased numbers of reviews and associated <del> issues, along with other improvements that come from broader participation by facilitating those in the community to participate. </del> <ins> issues, along with other improvements that come from facilitating participation by a broader community. </ins> 1.3.

1.5. <del> The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are used in this document.  It's not shouting; when they are capitalized, they have the special meaning defined in BCP 14 RFC2119 RFC8174. </del> <ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 2.

interest in using GitHub and making a consensus call to determine if the proposed policy and use is acceptable. <del> Chairs MUST involve Area Directors in any decision to use GitHub for anything more than managing drafts. </del> <ins> Chairs SHOULD involve Area Directors in any decision to use GitHub, especially where substantive discussion of issues is permitted as described in mode-discuss. </ins> 3.1.

consensus MUST NOT be reopened unless new information is presented. For long-running work items, new contributors often raise issues that <del> have already been resolved.  Chairs need to assess whether the arguments offered represent new information or not.  This can require some discussion to determine accurately.  Resolved issues MUST remain closed unless there is consensus to reopen an issue. </del> <ins> have already been resolved.  Moreover, there could be temptation to reopen contentious issues resolved with rough consensus.  Determining whether arguments presented in favor of reopening an issue represents new information might require some discussion in the Working Group. Chairs are empowered to exercise discretion in determining whether to reopen issues.  For more difficult matters, the chairs MAY insist that the Working Group reach consensus on whether an issue should be reopened.  Note however that any product of this process still needs to have the support of rough consensus in the Working Group, which could justify reopening issues. </ins> 4.2. <del> Pull requests are the GitHub feature that allow users to request changes to a repository.  A user does not need to have write access to a repository to create a pull request.  A user can create a "fork", or copy, of any public repository.  The user has write access to their own fork, allowing them to make local changes.  A pull request asks the owner of a repository to merge a specific set of changes from a fork (or any branch) into their copy. </del> <ins> A pull request is a GitHub feature that allows a user to request a change to a repository.  A user does not need to have write access to a repository to create a pull request.  A user can create a "fork", or copy, of any public repository.  The user has write access to their own fork, allowing them to make local changes.  A pull request asks the owner of a repository to merge a specific set of changes from a fork (or any branch) into their copy. </ins> Editors SHOULD make pull requests for all substantial changes rather than committing directly to the "master" branch of the repository.

In addition to the features that pull requests share with issues, users can also review the changes in a pull request.  This is a <del> valuable feature, but it has some issues. </del> <ins> valuable feature, but presents some challenges. </ins> Comments in a review other than a summary are attached to specific lines of the proposed change.  Such comments can be hard or

are tracked and can be audited.  Within the usual Working Group process it is expected that Internet-Drafts will receive regular review.  Finally, process checkpoints like Working Group Last Call <del> (WGLC; Section 7.4 of RFC2418) provides additional safeguards against </del> <ins> (WGLC; Section 7.4 of RFC2418) provide additional safeguards against </ins> abuse. Working Groups are advised against allowing editors this degree of

6. <del> During the development of a document, individual revisions of a </del> <ins> During the development of a document, individual revisions of the </ins> document can be built and formally submitted as an Internet-Draft. This creates a stable snapshot and makes the content of the in- progress document available to a wider audience.  Documents submitted