Draft: draft-ietf-git-using-github

Commentary: A good start . Would you like to open another PR adding yourself as an author ? 
 Let me know if what I created ( experiences + author ) needs to be something different . This is a very scary world for me . Ultra light description is next .
Paragraph (version A):
The use of source control improves traceability and visibility of
changes.  Issue tracking can be used to manage open issues and
provide a record of their resolution.  Pull requests allow for better
engagement on technical and edditorial changes, and encourage
contributions from a larger set of contributors.  Using GitHub can
also broaden the community of contributors for a specification.
Paragraph (version B):
The use of source control improves traceability and visibility of
changes.  Issue tracking can be used to manage open issues and
provide a record of their resolution.  Pull requests allow for better
engagement on technical and editorial changes, and encourage
contributions from a larger set of contributors.  Using GitHub can
also broaden the community of contributors for a specification.
Paragraph (version A):
This document is meant as an supplement to existing Working Group
practices.  It provides guidance to Working Group chairs and
participants on how they can best use GitHub within the framework
established RFC 2418 RFC2418.  The small number of rules in this
document are there to ensure common usage patterns between working
groups and to avoid issues that have been encountered in the past.
Paragraph (version A):
A companion document, GH-CONFIG, describes administrative processes
that supports the practices described in this document.
Paragraph (version B):
This document is meant as a supplement to existing Working Group
practices.  It provides guidance to Working Group chairs and
participants on how they can best use GitHub within the framework
established by RFC 2418 RFC2418.  The small number of rules in this
document are there to ensure common usage patterns between working
groups and to avoid issues that have been encountered in the past.
Paragraph (version B):
A companion document, GH-CONFIG, describes administrative processes
that support the practices described in this document.
Paragraph (version A):
Git is not the only version control system available, nor is GitHub
the only possible choice for hosting.  There are other services that
host revision control repositories and provide similar additional
features to GitHub.  For instance, BitBucket [4], or GitLab [5]
provide a similar feature set.  In additional to a hosted service,
software for custom installations exists.
Paragraph (version B):
Git is not the only version control system available, nor is GitHub
the only possible choice for hosting.  There are other services that
host revision control repositories and provide similar additional
features to GitHub.  For instance, BitBucket [4], or GitLab [5]
provide a similar feature set.  In addition to a hosted service,
software for custom installations exists.
Paragraph (version A):
A Working Group Chairs are responsible for determining how to best
accomplish the Charter in an open and transparent fashion.  The
Working Group Chairs are responsible for determining if there is
interest in using GitHub and making a consensus call to determine if
a the proposed policy and use is acceptable.
Paragraph (version A):
Chairs MUST involve Area Directors any decision to use GitHub for
anything more than managing of drafts.
Paragraph (version B):
Working Group Chairs are responsible for determining how to best
accomplish the Charter in an open and transparent fashion.  The
Working Group Chairs are responsible for determining if there is
interest in using GitHub and making a consensus call to determine if
the proposed policy and use is acceptable.
Paragraph (version B):
Chairs MUST involve Area Directors in any decision to use GitHub for
anything more than managing drafts.
Paragraph (version A):
Maintaining multiple documents in the same repository can add
overheads that negatively affect individual documents.  For instance,
issues might require additional markings to identify the document
that they affect.  Also, because editors all have write access to the
repository, managing the set of people with write access to a larger
repository is more difficult.
Paragraph (version B):
Maintaining multiple documents in the same repository can add
overhead that negatively affects individual documents.  For instance,
issues might require additional markings to identify the document
that they affect.  Also, because editors all have write access to the
repository, managing the set of people with write access to a larger
repository is more difficult.
Paragraph (version A):
One common practice is to use these continuous integration services
to build a text or HTML version of a document.  This is then
published to GitHub Pages, which allows users to view a version of
the most recent revision of a document.  Including prominent link to
this version of the document (such as in the README) makes it easier
for new contributors to find a readable copy of the most recent
version of a draft.
Paragraph (version A):
Continuous integration can also validate pull requests and other
changes for errors.  The most basic check is whether the source file
can be transformed successful into a valid Internet-Draft.  For
example, this might include checking that XML source is syntactically
correct.
Paragraph (version A):
For documents that use formal languages a part of specifications,
such as schema or source code, a continuous integration system might
also be used to validate any formal language that the document
contains.  Tests for any source code that the document contains might
be run, or examples might be checked for correctness.
Paragraph (version B):
One common practice is to use these continuous integration services
to build a text or HTML version of a document.  This is then
published to GitHub Pages, which allows users to view a version of
the most recent revision of a document.  Including a prominent link
to this version of the document (such as in the README) makes it
easier for new contributors to find a readable copy of the most
recent version of a draft.
Paragraph (version B):
Continuous integration can also validate pull requests and other
changes for errors.  The most basic check is whether the source file
can be transformed successfully into a valid Internet-Draft.  For
example, this might include checking that XML source is syntactically
correct.
Paragraph (version B):
For a document that use formal languages as part of the
specification, such as schema or source code, a continuous
integration system might also be used to validate any formal language
that the document contains.  Tests for any source code that the
document contains might be run, or examples might be checked for
correctness.
Paragraph (version A):
If a contributor makes a comment that raises what you believe to be a
new issue, create an issue for them.  If the issue has an obvious
solution, consider creating a pull request.  It doesn't matter what
venue the issue was raised in, 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 you believe to be a
new issue, create an issue for them.  If the issue has an obvious
solution, consider creating 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.