Subject: [Tsv-art] Tsvart last call review of draft-ietf-git-using-github-04

From: David Black via Datatracker <[email-masked]>
Date: Fri, 28 Feb 2020 17:25:22 -0800

Reviewer: David Black
Review result: Ready with Nits

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

This draft describes best practices for use of GitHub in IETF working groups
and provides some very helpful policy examples.   I did not see any technical
issues related to the Transport Area.   As this document will apply to use of
GitHub by Working Groups in the Transport Area, I have a couple of editorial
comments on the draft's content for the authors to consider: 

[1] The split of Issue Tracker material across Sections 4.1 and 5 seems off.
In particular, Sections 4.1.2 and 4.1.3 on closing and reopening issues are
strongly connected to the Section 5 discussion of WG policies for Issue
Tracker usage and hence ought to be moved into Section 5.   The Section
4.1 discussion on use of labels could likewise benefit from being merged
into the more extensive discussion of WG use of labels in Section  5.4 .

[2] The example WG policies in Section 5 come tantalizingly close to being
well known policies that can be used by reference in a fashion analogous to
the well-known IANA registry management policies in Section 4.1 of
RFC 5226 (https://tools.ietf.org/html/rfc5226#section-4.1).   Doing the
analogous thing with these GitHub policies is likely to be greatly appreciated
by WG Chairs who are new to WG use of GitHub.  However, use of GitHub
may not have matured to the point where this is a sensible thing to do, and
hence I leave the determination of whether this should be done to the
authors' and the IESG's best judgement.