Draft: draft-ietf-git-github-wg-configuration

Commentary: See 
 I 'm good with all the changes except the one I commented on .
Mailing list commentary: I ’ ve picked this document up as responsible AD , because is an author on the document . There ’s one item in my review that I ’d like to have addressed before this goes out for last call ; the rest do n’t need to block last call , but they should be easy to address . Blocking comment : — Section 2.4 — When a working group is closed , the team with administrative access would be removed and the owner list would be returned to its initial composition . What “ initial composition ” ? The Secretariat and the ADs at the time the organization was created ? That does n’t make sense . The Secretariat and current ADs at the time of closing ? That ’s not “ initial ” . Or do you have something else in mind ? The rest : — Abstract — Just a note here that the second paragraph should be removed before publication . I ’ ve put this in as an RFC Editor Note . — Section 1 — proposals in this document , the functional requirements would need to be discussed with the IETF Tools Team , and the IETF Secretariat who would need to support various pieces of what is proposed herein . Nit : the comma after “ Tools Team ” is misplaced , and should be after “ Secretariat ” instead . — Section 2 — For example , see and for working examples of automation that is in use in some working groups . Two things here : 1 . Nit : “ For example … for working examples ” is redundant ; I suggest starting the sentence with “ See ” . 2 . I ’ m not sure that these URLs will stand the test of time , remaining valid in an archival document . On the other hand , having them here as examples is certainly useful . Perhaps we could archive them on an page , or perhaps the RFC Editor could do so on an rfc- page ? In this document the question of whether processes should be manual or automated is deliberately left ambiguous “ Ambiguous ” is  the right word — it carries a connotation of confusion . I suggest “ unspecified ” . And there needs to be a comma after that word , whichever we choose . — Section 2.2 — be able to run steps 3 and 4 from Section 2.1 so that the rest of the activities in this section such as personnel work the same for the organizations that were created on their own . I find this awkward ; I think it needs commas and a minor edit : NEW be able to run steps 3 and 4 from Section 2.1 so that the rest of the activities in this section , such as personnel changes , work the same way as for organizations that were created as specified herein . END — Section 2.5 — o Creating a new repository for an individual draft that is at the discretion of the WG chair ; What does “ an individual draft that is at the discretion of the WG chair ” mean ? — Section 4 — An attacker who can change the contents of Internet Drafts , particularly late in a working group 's process , can possibly cause unnoticed changes in protocols that are eventually adopted . Indeed , and so should we propose any mitigations ? Using a github instance that ’s maintained and secured under ? At the very least we ’ll need to rely on careful review during the publication process , including verifying what changes were made at each step and flagging questionable changes . The text here should probably say something more .
Paragraph (version A):
The document is meant to spur discussion in the IETF community.  If
there proves to be rough consensus in the community in support of the
proposals in this document, the functional requirements would need to
be discussed with the IETF Tools Team, and the IETF Secretariat who
would need to support various pieces of what is proposed herein.
Paragraph (version B):
The document is meant to spur discussion in the IETF community.  If
there proves to be rough consensus in the community in support of the
proposals in this document, the functional requirements would need to
be discussed with the IETF Tools Team and the IETF Secretariat, who
would need to support various pieces of what is proposed herein.
Paragraph (version A):
This section specifies a proposal for an administrative process and
conventions to support the creation and management of GitHub
organizations for working groups and single-document repositories in
a uniform way.  The steps could be done manually by the IETF
Secretariat or they could be automated.  For example, see
<https://github.com/richsalz/ietf-gh-scripts> and
<https://github.com/martinthomson/i-d-template> for working examples
of automation that is in use in some working groups.
Paragraph (version A):
In this document the question of whether processes should be manual
or automated is deliberately left ambiguous since the first question
that should be asked is whether this is functionality the community
would want to have supported at all.
Paragraph (version B):
This section specifies a proposal for an administrative process and
conventions to support the creation and management of GitHub
organizations for working groups and single-document repositories in
a uniform way.  The steps could be done manually by the IETF
Secretariat or they could be automated.  See
<https://github.com/richsalz/ietf-gh-scripts> and
<https://github.com/martinthomson/i-d-template> for working examples
of automation that is in use in some working groups.
Paragraph (version B):
In this document the question of whether processes should be manual
or automated is deliberately left unspecified, since the first
question that should be asked is whether this is functionality the
community would want to have supported at all.
Paragraph (version A):
If a working group already has an organization, it would be useful to
be able to make it have the same management as one would get with
going through the steps in creation.  That is, it would be good to be
able to run steps 3 and 4 from creation so that the rest of the
activities in this section such as personnel work the same for the
organizations that were created on their own.
Paragraph (version B):
If a working group already has an organization, it would be useful to
be able to make it have the same management as one would get with
going through the steps in creation.  That is, it would be good to be
able to run steps 3 and 4 from creation so that the rest of the
activities in this section, such as personnel changes, work the same
way as for organizations that were created as specified herein.
Paragraph (version A):
When a working group is closed, the team with administrative access
would be removed and the owner list would be returned to its initial
composition.  The organization summary and the repositories within
the organization would be updated to indicate that they are no longer
under development.
Paragraph (version B):
When a working group is closed, the team with administrative access
would be removed and the owner list would be returned to the
Secretariat and current ADs at the time of closing.  The organization
summary and the repositories within the organization would be updated
to indicate that they are no longer under development.