GitHub Integration and Tooling
charter-ietf-git-01

I share Spencer's questions

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?

(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.