Original text:
Abstract <del> This document describes best practices for Working Groups that use GitHub for their work. </del>  Note to Readers The main purpose of this document is providing guidelines for how Working Groups might integrate the capabilities provided by GitHub <del> into their processes for developing Internet-Drafts. </del>  This document is meant as a supplement to existing Working Group practices.  It provides guidance to Working Group chairs and

Reviewer comments:
I agreed to change from DISCUSS to Abstain if this change was made - email thread for the curious / archives: URL A PR is close enough to integrated for me...
NAME I'm curious why this change is adequate; it's effectively just a rewording. It doesn't address the issue of the group choosing to adopt the policies.
NAME Yes, it is just a rewording -- but (for me at least) it made it enough clearer that this was optional (WGs can choose to use GH, not WGs are expected to use GH) that I was willing to move to Abstain instead. The WG has consensus, and the charter sent us down the "GH FTW!" path - it isn't appropriate for me to block this just because I don't like it / think there is a better way of using RCS tooling / GH. The process was followed, and the document is valuable - I don't like the tone, I don't like the implication, but it now falls into the "Well, that's just, like, your opinion, man..." territory. (There isn't a technical objection, nor do I think it is specifically dangerous to the IETF / IETF stream, so...)
NAME - OK. This is made moot by the other changes that Martin made to the draft, but to be clear, I don't think that's a good line of argumentation. The WG was charted to an explicit scope - that WGs had to opt into the practices it documented. If it were producing a document that exceeded that scope (which is arguably did before the recent change referenced above), saying that the WG "has consensus" to violate its charter is meaningless, and letting that stand is damaging. That's because charters allow people to decide whether or not they're going to follow a WG. If a WG can violate its charter and justify that with "but we had consensus to do so", charters are meaningless, and the check that requiring IETF consensus places upon WGs is seriously diminished. Thank you -- I would even be OK with just changing to Abstract to be: "This document describes best practices for Working Groups that choose to use GitHub for their work." and leave it as BCP. Would that work better for everyone? It would be enough for me to no longer feel that this is saying that WGs using GitHub is a BCP, but rather that if a WG decided to use GitHub, this is the best way to do so (I'm still not sure that this really is the best way, but that's just my opinion, and I'm OK being in the rough) W I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf

Revised text:
Abstract  <ins> This document describes best practices for Working Groups that choose to use GitHub for their work. </ins> Note to Readers The main purpose of this document is providing guidelines for how Working Groups might integrate the capabilities provided by GitHub  <ins> into their processes for developing Internet-Drafts.  The choices of whether to use GitHub and whether to adopt these practices if they do is at the discretion of the Working Group. </ins> This document is meant as a supplement to existing Working Group practices.  It provides guidance to Working Group chairs and