jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-git-using-github

Commentary: Based on Francesca 's review feedback expand those with whom chairs are encouraged to consult periodically .
Paragraph (version A):
Working Group policies need to be set with the goal of improving
transparency, participation, and ultimately the quality of the
consensus behind documents.  At times, it might be appropriate to
impose some limitations on what document editors are able to do in
order to serve these goals.  Chairs SHOULD periodically consult with
document editors to ensure that policies are effective.
Paragraph (version B):
Working Group policies need to be set with the goal of improving
transparency, participation, and ultimately the quality of the
consensus behind documents.  At times, it might be appropriate to
impose some limitations on what document editors are able to do in
order to serve these goals.  Chairs SHOULD periodically consult with
document editors and the Working Group to ensure that policies are
effective.
Draft: draft-ietf-git-using-github

Commentary: Based on feedback from Suresh in AD review
Paragraph (version B):
Additionally, clear reporting about the changes that were included in
each revision of an Internet-Draft helps ensure that contributors can
follow activity.  This might be achieved by requesting that editors
provide a change log that captures substantive changes to the
document in each revision.
Draft: draft-ietf-git-using-github

Commentary: Do n't use 2119 language , just point at 2418
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 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 B):
Section 7.1 of RFC2418 recommends that editors 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.  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.
Draft: draft-ietf-git-using-github

Commentary: This is the way we 've been treating this , so let 's acknowledge that . 
 As I noted on the list , I do n't think this is correct . I proposed alternate text . 
 Still LGTM . :-)
Paragraph (version A):
A choice to use GitHub is similar to the formation of a design team
(see Section 6.5 of RFC2418) provided that the work uses a public
repository.  That is, the output of any activity using GitHub needs
to be taken to the Working Group mailing list and subject to
approval, rejection, or modification by the Working Group as with any
other input.
Paragraph (version B):
Work done in GitHub has no special status.  The output of any
activity using GitHub needs to be taken to the Working Group and is
subject to approval, rejection, or modification by the Working Group
as with any other input.
Draft: draft-ietf-git-using-github

Commentary: This consolidates text about notices in the " communicating policies " section , which seems most appropriate . 
 Thanks !
Paragraph (version A):
GitHub prominently links to the CONTRIBUTING file on certain pages.
This file SHOULD be used in preference to the README for information
that new contributors need.  A link to the CONTRIBUTING file from the
README is advised.
Paragraph (version A):
In addition to Working Group policies, notices on repositories MUST
include citations for BCPs 78 and 79 (COPYRIGHT, IPR) and other IETF
contribution policies.  A copy or reference to the IETF Note Well [6]
is ideal.
Paragraph (version B):
GitHub prominently links to the CONTRIBUTING file on certain pages.
This file SHOULD be used in preference to the README for information
that new contributors need.  The README SHOULD contain a link to the
CONTRIBUTING file.
Paragraph (version B):
In addition to Working Group policies, notices on repositories MUST
include citations for the IETF Note Well [6].
Paragraph (version A):
A document editor can still use GitHub independently for documents
that they edit, even if the Working Group does not expressly choose
to use GitHub.  Any such public repository MUST follow the guidelines
in BCPs 78 and 79 (COPYRIGHT, IPR) and bear notices to that effect.
This recognizes that editors have traditionally chosen their own
methods for managing the documents they edit but preserves the need
for contributors to understand their obligations with respect to IETF
processes.
Paragraph (version B):
A document editor can still use GitHub independently for documents
that they edit, even if the Working Group does not expressly choose
to use GitHub.  Any such public repository MUST follow the IETF Note
Well and bear notices; see notices.  This recognizes that editors
have traditionally chosen their own methods for managing the
documents they edit but preserves the need for contributors to
understand their obligations with respect to IETF processes.
Draft: draft-ietf-git-using-github

Commentary: For , but not all of it . 
 Some working groups use GitHub to manage changes to charters or other working group materials , like agendas and presentations for sessions . I 'd suggest that no great amount of detail is needed because these are n't the primary focus of the document , but it probably should include at least a passing mention of these uses and acknowledge that they are permitted . 
 Discussed in Singapore ; MT to add text . 
 Closed in . 
 How this fits into existing processes is something that needs more thorough investigation if we 're publishing an RFC on this . 
 Discussed in Singapore ; no objections , merged , and closing .
Paragraph (version A):
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):
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.  This document aims to establish
norms that reduce the variation in usage patterns between different
Working Groups and to avoid issues that have been encountered in the
past.
Paragraph (version B):
This document only aims to address use of GitHub in developing
documents.  Working Groups could choose to use the tool to aid in
managing their charter or session materials such as agendas, minutes,
and presentations.  Though the advice here might apply more broadly,
using GitHub to manage other material is out of scope for this
document.
Draft: draft-ietf-git-using-github

Commentary: But the working group does n't depend on those in any way .
Paragraph (version A):
In the version of this mode with the least interaction with GitHub,
only the document repository is created and that is used by editors.
Editors might manage issues for their own benefit, or they might
choose to just use the respository to manage document revisions.
Paragraph (version B):
In the version of this mode with the least interaction with GitHub, a
repository is created for the purposes of document management by
editors.  Editors might maintain issues and pull requests for their
own benefit, but these have no formal standing in the Working Group
process.
Draft: draft-ietf-git-using-github

Commentary: Section 4.2 says " Editors SHOULD make pull requests for all substantial changes rather than committing directly to the " master " branch of the repository . " Adding a short explanation will help make this more likely to happen .
Paragraph (version A):
Editors SHOULD make pull requests for all substantial changes rather
than committing directly to the "master" branch of the repository.
Pull requests that address substantive issues SHOULD mention the
issue they address in the opening comment.
Paragraph (version B):
Editors SHOULD make pull requests for all substantial changes rather
than committing directly to the "master" branch of the repository.  A
pull request creates an artifact that records the reasons for changes
and provides other contributors with an opportunity to review the
change.  Pull requests that address substantive issues SHOULD mention
the issue they address in the opening comment.