Original text:
merge outstanding pull requests. Editors SHOULD create a new Internet-Draft submission two weeks prior <del> 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. </del>  Revisions used to generate documents that are submitted as Internet- Drafts SHOULD be tagged in repositories to provide a record of 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 <del> of the document.  Chairs are reminded that assessing consensus based on GitHub content alone cannot be assumed to reach all interested participants. </del>  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 <del> 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. </del>  <del> 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). </del>  The use of issues and labels has proven to be effective in managing contentious issues.  Explicitly labeling closed issues to explicitly

Reviewer comments:
This has two commits: Unpack "session" a little more to make it clear that this isn't just IETF meetings. Explain that participation on GitHub isn't the only possible input, and the effect that this has on assessing WG consensus.

Revised text:
merge outstanding pull requests. Editors SHOULD create a new Internet-Draft submission two weeks prior  <ins> 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. </ins> Revisions used to generate documents that are submitted as Internet- Drafts SHOULD be tagged in repositories to provide a record of 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  <ins> 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. 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. </ins> 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  <ins> ensures a higher quality document. </ins>  <ins> 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). </ins> The use of issues and labels has proven to be effective in managing contentious issues.  Explicitly labeling closed issues to explicitly