Note: This ballot was opened for revision 00-00 and is now closed.
Ballot question: "Is this charter ready for external review?"
I share Spencer's questions
(I had some comments during Internal Review that I haven't seen replies to, but this is close enough to send out the way it is) Many IETF working groups use external code repository services, primarily GitHub, in managing their work. Individual working groups, while continuing to operate within IETF guidelines for working group activity, have developed their own policies and practices for how they use these services. These policies and practices cover aspects such as: managing discussion between working group mailing lists and GitHub issues and pull requests; how text contributions are expected to be made; labeling and naming conventions; maintaining readable draft snapshots; using tooling and automation; and others. <Spencer> I don't know whether best practices for Note Well awareness are implicitly covered here, but I remember that's often a subject that comes up when a working group starts to use Github. The examples given aren't exhaustive, so perhaps they're sufficient, but it comes up so often it might be worth mentioning explicitly. </Spencer> The GitHub Integration and Tooling (GIT) working group will select a set of such practices and document policies that support those practices. The policies will each detail how work is conducted by working groups that opt to follow the work practice. The goal is to provide both process and tooling support for working groups that choose to adopt the documented practices. <Spencer> I don't actually know how stable the way Github works has been in recent years, or how stable it's expected to be. Is the goal for this working group one-and-done, or are we talking about an ongoing process as the way Github works, and the way IETF working groups work, evolves? </Spencer> The documents will not alter the Internet Standards Process (BCP 9), they will describe how to work within it. Whether working groups choose to use GitHub to support their work will remain entirely at their discretion. The working group may also discuss tooling requirements in support of GitHub use. Decisions about implementing specific tooling needs will be undertaken in consultation with the IETF Tools Team and other interested contributors. <Spencer> It should surprise no one that I don't actually know who makes those decisions, which hasn't mattered for my time on the IESG up to this point, but I thought I should ask now if this is the way people expect the chartered working group to interact with the IETF Tools Team. One might read this as saying the working group plus the IETF Tools Team (and other interested contributors) are the decision makers. If that's correct, awesome. </Spencer>
If possible, I would like to see some mention in the charter regarding mirroring of the github repositories on the IETF side.
Two minor questions: 1) I'm not sure of all or any of the documents this group will produce should be BCP given that BCP9 will not be changed. If the group ends up to rather documenting what done today than giving recommendations that might be informational only. However, that's not really an issue I guess. If you want to be on the save side you could say in the milestone s/as BCP/as BCP or informational/ 2) Is any discussion about operating an own git service in scope for this group? If not, would it make sense to explicitly exclude it in the charter?
"The documents will not alter the Internet Standards Process (BCP 9), they will describe how to work within it." is a comma splice.
I am fine with this, but it seems to leave open the question about whether these policies would be binding if you chose to use Github -- though obviously non-binding if you chose to use Bitbucket or something. I'm sure the answer is "no", but maybe we should make that clear?
Hello, The GitHub Integration and Tooling (GIT) working group will select a set of such practices and document policies that support those practices. The policies will each detail how work is conducted by working groups that opt to follow the work practice. The goal is to provide both process and tooling support for working groups that choose to adopt the documented practices. This paragraph first states that policies will be documented but ends up saying practices will be documented.