Draft: draft-ietf-git-using-github

Commentary: Please pay special attention to and when reviewing this . 
 LGTM with some proposed simplifying text .
Paragraph (version A):
GitHub is a service operated at https://github.com/ [5].  GitHub
provides centralized storage for git repositories.  GitHub is freely
accessible on the open Internet, albeit currently only via IPv4.
Paragraph (version A):
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.
Paragraph (version A):
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
issues, along with other improvements that come from broader
participation by facilitating those in the community to participate.
Paragraph (version B):
GitHub is a service operated at https://github.com/ [5].  GitHub
provides centralized storage for git repositories.  GitHub is freely
accessible on the open Internet.
Paragraph (version B):
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.
Paragraph (version B):
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
issues, along with other improvements that come from facilitating
participation by a broader community.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
Chairs MUST involve Area Directors in any decision to use GitHub for
anything more than managing drafts.
Paragraph (version B):
Chairs SHOULD involve Area Directors in any decision to use GitHub,
especially where substantive discussion of issues is permitted as
described in mode-discuss.
Paragraph (version A):
For long-running work items, new contributors often raise issues that
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.
Paragraph (version A):
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.
Paragraph (version B):
For long-running work items, new contributors often raise issues that
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
In addition to the features that pull requests share with issues,
users can also review the changes in a pull request.  This is a
valuable feature, but it has some issues.
Paragraph (version B):
In addition to the features that pull requests share with issues,
users can also review the changes in a pull request.  This is a
valuable feature, but presents some challenges.
Paragraph (version A):
Changes made by editors under this process do not completely lack
oversight.  GitHub and git provide tools for ensuring that changes
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
(WGLC; Section 7.4 of RFC2418) provides additional safeguards against
abuse.
Paragraph (version B):
Changes made by editors under this process do not completely lack
oversight.  GitHub and git provide tools for ensuring that changes
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
(WGLC; Section 7.4 of RFC2418) provide additional safeguards against
abuse.
Paragraph (version A):
During the development of a document, individual revisions of a
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
as Internet-Drafts are not expected to address all open issues or
merge outstanding pull requests.
Paragraph (version B):
During the development of a document, individual revisions of the
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
as Internet-Drafts are not expected to address all open issues or
merge outstanding pull requests.