Draft: draft-ietf-git-using-github

Commentary: Two changes , two issues , but really this is the one idea . The previous draft said that features not used could be disabled . This is bad advice because that might be denying editors access to tools that would make their task easier . The new advice says that editors can use features that the working group does n't rely on . It also says that chairs should consult editors to ensure that policies are n't adversely affecting them . 
 Most of the operating modes assume that editors are given considerable latitude in how repositories are managed . This is good up until the point that the Working Group starts to formally rely on things that are in the respository . The document sort of prevaricates about this point , including strong admonitions that suggest rules be formalized for every aspect of usage . Instead , I think that it would be better if the document said - up - front - that editors are to be given control unless the Working Group starts to formally depend on a particular function ( like issue opening / closing , labels , pull requests , whatever ... ) . At that point , it is the chair 's responsibility to identify what the WG depends on and to clearly articulate the policies around that usage . 
 Section 3.1 talks about turning off GitHub features not being used by the WG , but it does n't say how to do that in the UI . I ask this because I can not see a way to prevent issues or PRs just by wandering through the GUI . 
 This is n't something that I 'd want to publish . The way that features are configured is too tightly coupled to UX decisions that GitHub might remake and any point . In fact , I might prefer not to include the offending text at all . Disabling features can be a useful way to slim down the options presented to users ( which can help new users ) , but it can also be fairly hostile to new contributors . For instance , if the working group disables issues because they are n't using them , it sounds reasonable , but new contributors might then be dissuaded from opening a genuine issue . Working groups might be better served by informally letting contributors know how to best provide their input . 
 I 'm happy with either the current text plus " At the time this is written , to turn of y " or removing the suggestion .
Paragraph (version A):
Once a document is published in a repository on GitHub, many features
like pull requests, issue tracking or the wiki can be individually
disabled.  If specific features are not used by the Working Group in
the development of the document, disabling those features avoids
creating confusion in the wider community about what can be used.
Paragraph (version B):
The set of GitHub features (features) that the Working Group relies
upon need to be clearly documented in policies.  This document
provides some guidance on potential policies and how those might be
applied.
Paragraph (version B):
Features that the Working Group does not rely upon SHOULD be made
available to document editors.  Editors are then able to use these
features for their own purposes.  For example, though the Working
Group might not formally use issues to track items that require
further discussion in order to reach consensus, keeping the issue
tracker available to editors can be valuable.
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 to ensure that policies are effective and not
unjustifiably constraining progress.