Draft: draft-ietf-git-using-github

Commentary: This has two commits : " session " a little more to make it clear that this is n't just IETF meetings . that participation on GitHub is n't the only possible input , and the effect that this has on assessing WG consensus .
Paragraph (version A):
Editors SHOULD create a new Internet-Draft submission two weeks prior
to every session (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 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 A):
Monitoring activity on GitHub can require a greater time commitment
than following a mailing list.  This is because there is an increased
volume of activity to follow.  Participants who wish to limit this
time commitment might follow GitHub activity selectively, either by
following only specific issues or by occasionally reviewing the state
of the document.  Chairs are reminded that assessing consensus based
on GitHub content alone cannot be assumed to reach all interested
participants.
Paragraph (version A):
A Working Group chair MUST consult the Working Group mailing list for
any issue that is potentially contentious.  Relying on input provided
through GitHub alone might result in gaining input from a narrower
set of participants.  This includes important milestones like Working
Group Last-Call, where review from the widest possible audience
ensures a higher quality document.  Managing input from multiple
sources in assessing consensus is similar to what is needed when
balancing mailing list discussion versus in-person meeting
discussion.
Paragraph (version A):
It is expected that technical decisions will be made based on
discussion and interaction on GitHub.  This is especially the case
during early stages of development of a document.  Any decisions are
ultimately confirmed through review, and ultimately, through Working
Group Last Call (see Section 7.4 of RFC2418).
Paragraph (version B):
Monitoring activity on GitHub can require a greater time commitment
than following a mailing list.  This is because there is an increased
volume of activity to follow.  Participants who wish to limit this
time commitment might follow GitHub activity selectively, either by
following only specific issues or by occasionally reviewing the state
of the document.  Other participants might not use GitHub at all.
Chairs are reminded that assessing consensus based on GitHub content
alone cannot be assumed to reach all interested participants.
Paragraph (version B):
Chairs MUST consider input from all discussion venues when assessing
consensus including GitHub, mailing lists, and in-person meetings.
Each venue has different selection biases that might need to be
considered.
Paragraph (version B):
A Working Group chair MUST consult the Working Group mailing list for
any issue that is potentially contentious.  Relying on input provided
through GitHub alone might result in gaining input from a narrower
set of participants.  This includes important milestones like Working
Group Last-Call, where review from the widest possible audience
ensures a higher quality document.
Paragraph (version B):
If permitted, GitHub will be used for technical discussion and
decisions, especially during early stages of development of a
document.  Any decisions are ultimately confirmed through review, and
ultimately, through Working Group Last Call (see Section 7.4 of
RFC2418).