Draft: draft-ietf-git-using-github

Commentary: This change collects some editorial fixes identified during my shepherd review . 
 Thanks !
Paragraph (version A):
Version control systems are a critical component of software
engineering and are quite useful also for document editing.
Paragraph (version B):
Version control systems are a critical component of software
engineering and are also quite useful for document editing.
Paragraph (version A):
Comments in a review other than a summary are attached to specific
lines of the proposed change.  Such comments can be hard or
impossible to find if changes are subsequently made to the pull
request.  This is problematic for contributors who don't track
discussion closely.
Paragraph (version B):
Comments in a review other than a summary are attached to specific
lines of the proposed change.  Such comments can be hard or
impossible to find if changes are subsequently made to the pull
request.  This is problematic for contributors who do not track
discussion closely.
Paragraph (version A):
Editors SHOULD create a new Internet-Draft submission two weeks prior
to every session, which includes IETF meetings, other in-person
meetings, and telephone or video conferences (see Section 7.1 of
RFC2418).  Though discussion could use the current version of a
document from version control, participants in a session can't be
expected to monitor changes to documents in real-time; a published
Internet-Draft ensures that there is a common, stable state that is
known to all participants.
Paragraph (version B):
Editors SHOULD create a new Internet-Draft submission two weeks prior
to every session, which includes IETF meetings, other in-person
meetings, and telephone or video conferences (see Section 7.1 of
RFC2418).  Though discussion could use the current version of a
document from version control, participants in a session cannot be
expected to monitor changes to documents in real-time; a published
Internet-Draft ensures that there is a common, stable state that is
known to all participants.
Paragraph (version A):
Using GitHub means that it is more likely that a contribution is made
by users who aren't very familiar with the work.  Pull requests from
new contributors can contain errors or omissions.  Duplicate issues
are commonplace.  Proposed changes might have grammatical errors or
they might diverge from existing style.  If a change is generally
sound, rather than rejecting the pull request or requesting changes,
editors could instead accept the change and then make any necessary
corrections.
Paragraph (version B):
Using GitHub means that it is more likely that a contribution is made
by users who are not very familiar with the work.  Pull requests from
new contributors can contain errors or omissions.  Duplicate issues
are commonplace.  Proposed changes might have grammatical errors or
they might diverge from existing style.  If a change is generally
sound, rather than rejecting the pull request or requesting changes,
editors could instead accept the change and then make any necessary
corrections.
Paragraph (version A):
If a contributor makes a comment that raises what a new issue,
editors can create an issue or - if there is an obvious solution - a
pull request.  It doesn't matter what venue the issue was raised in
(e.g., email, issue discussion, a pull request review); capturing
issues quickly ensures that problems become visible and can be
tracked.
Paragraph (version B):
If a contributor makes a comment that raises what a new issue,
editors can create an issue or - if there is an obvious solution - a
pull request.  It does not matter what venue the issue was raised in
(e.g., email, issue discussion, a pull request review); capturing
issues quickly ensures that problems become visible and can be
tracked.