Hi David, Thanks for the review (and apologies for having it slip the net until now). On Sat, Feb 29, 2020, at 12:25, David Black via Datatracker wrote: > [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 . This is a hard one. The advice in Section 4 is intended to be generic, whereas Section 5 is intended to narrow this to the point of being specific. That naturally produces duplication, but I'm not seeing anything in Section 4.1 that is not universally applicable. > [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. The 8126 categories have become more precise over time in a way that has allowed us to use labels, but the need there is more acute. To me, the titles of Section 5.1 and 5.2 might be used with a fair degree of confidence in their meaning, but Section 5.3 is still a more nebulous. My sense is that these will ultimately be the labels that end up being used, but their definitions are still quite loose. Letting this tighten up as we get more experience seems like a good thing to work toward, but less from the need for a formalism and more from the perspective of making work practices more widely accessible. If we need to formally identify these things (say, in a charter), then that should work without saying "use Mode X from Section 5.Y of RFC ZZZZ". However, now we haven't formalized work modes to that extent so far. I am not certain if doing that would be a good idea. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
