[Ietf-and-github] Mirja Kühlewind's No Objection on draft-ietf-git-using-github-05: (with COMMENT)

[Mirja Kühlewind via Datatracker <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-git-using-github-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-git-using-github/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this well-written and helpful document. I have a couple of issue
below that touch on the use of normative language and relation to RFC2418 (as
well as maybe RFC2026). I guess those could qualify as discuss but I leave them
as comments for now trusting in the editors and AD to address them
appropriately.

One general comment:
I don't really understand the relationship between this document and
draft-ietf-git-github-wg-configuration. There is a lot of direct overlap
especially in section 2 but also in other sections. I understand that this
document is BCP and such more appropriate to specify practices normatively but
I don't really see why draft-ietf-git-github-wg-configuration is still needed
then. The only part that is left to draft-ietf-git-github-wg-configuration are
ideas about how things could be integrated in the datatracker and with the
secretariat. As I say in my discuss ballot for that draft, it is not clear to
my why we need an RFC for that at this point of time. If no decision is made
yet, this could have also just be integrated e.g. into the appendix on this
draft (or even partially in the security considerations section).

Other comments/questions:

1) Sec 3.2
"...or they might create repositories for individual documents on request."
I made a similar comment in my ballot for
draft-ietf-git-github-wg-configuration. I think creating repos for individuals
document is maybe not always the best option. I assume the intention here to
not out-rule any cases where this might be okay (e.g. if a document is expectd
to be adopted soon), however, I would rather prefer to see a recommendation to
usually not do that as there can be many individual drafts in the groups and it
can provide a wrong signal if repos are created for some and not others.

2) Sec 4.1.3:
"   Issues that have reached a resolution that has Working Group
   consensus MUST NOT be reopened unless new information is presented."
I do understand the intention here as it is important to make process, however,
inline with the rest of the document and the general idea that practises can
vary from group to group, I think this really should be a SHOULD NOT only.

Also further
"Resolved issues MUST remain
   closed unless there is consensus to reopen an issue."
I find this actually a bit strange because it should also then say something
like "Resolved issues MUST only be closed with wg consensus"... I guess the
word "resolved" is important here but why would you re-open an issue at all if
it is resolved? I guess the case is that the wg figures that the issue is not
resolved yet. Is the recommendation here for a wg participant to open a new
issue if he/she thinks an issue is not fully resolved yet (rather than just
re-open)? If so, you should say that.

3) Sec 4.2:
"   Editors SHOULD make pull requests for all substantial changes rather
   than committing directly to the "master" branch of the repository."
I think this does not align well with how we work today (without GitHub). E.g.
if a group decides to use GitHub to better track changes and maybe easily
integrate editorial comments, but decide to have all discussion on the mailing
list (and not use github issues), I think it would be fully okay for the
editors just commit directly based on the consensus on the mailing list. So I
think the important part is that substantial comments should only be committed
with wg consensus and therefore it is a good practice to have pull requests
first to declare consensus based on the concrete proposed edits. However, if a
different way to declare consensus is used that's fine as well. In short, I
think the SHOULD is to string here for the general case.

4) Sec 5.3 (mostly editorial):
"It is possible to use
   different processes for different documents in the Working Group.

   Working Group chairs SHOULD confirm that the Working Group has
   consensus to adopt any process.  In particular, the introduction of a
   more tightly-controlled process can have the effect of privileging
   positions already captured in documents, which might disadvantage
   alternative viewpoints."
This text seems to apply more general to all content in section 5 and should
maybe be moved out of section 5.3. Similarly I'm not sure if section 5.3.1 and
5.3.2 should actually be subsection of 5.3. The question of which issue to
track seem rather orthogonal to the question who resolves the issue (I agree
that this discussion does not make sense when no issue are tracked like in sec
5.1 but it could make sense for the mode in section 5.2)

5) Sec 5.3.1:
"The risk is that
   design changes might not always reflect the consensus of the Working
   Group."
I know that happens, even without GitHub, but should ideally not be the case.
However, I think the root cause is rather that changes were incorrectly not
identified by the editors as requiring consensus. Maybe this can be reworded
accordingly to not give the impression that it is okay to implement design
changes in a working group without consensus. Actually this is a broader
problem (independent of GitHub) because some editors, especially when they also
have been the authors of the individual draft, often implement design changes
first in a new version and then ask the working group for consensus. As I said
that's a different issue but it could be good to mention that GitHub and the
use of PRs can actually help to not use this practice but always each consensus
first.

6) Sec 5.3.1:
"... it is likely appropriate to move
   to a more tightly controlled process."
Maybe add something like "e.g. potentially during or after after working group
last call". I think in many groups (that do not use GitHub) it is very common
practice that editors have full control about the document. I mean I guess
that's their role. I think GitHub really can help to make the process more
transparent but it should not be a requirement. Especially shorter documents
that had have good consensus form the beginning, there might necessarily be a
need to every change that process. (I would say QUIC is rather the other
extreme.)

7) Sec 5.3.2:
"   Chairs might choose to manage the process of deciding which issues
   are substantive.  For instance, chairs might reserve the ability to
   use the "design" label to new issues (see Section 5.4.1) and to close
   issues marked as "design".  Chairs should always allow document
   editors to identify and address editorial issues as they see fit."
I guess you could also use normative language here: "MAY choose to" and "Chairs
SHOULD always allow"

8) Sec 5.3.2:
"   As documents mature further, explicit confirmation of technical
   decisions with the Working Group mailing list becomes more important."
Not sure I agree here. I know what you mean but explicit confirmation on the
mailing list is always important. Maybe there is a way to rephrase that (or
just remove that sentence...?)

9) Sec 5.3.2:
"   Gaining Working Group consensus about the resolution of issues can be
   done in the abstract, with editors being permitted to capture the
   outcome of discussions as they see fit."
I'm actually not sure what you mean here. Can you clarify?

10) Sec 5.3.2:
"   WGLC SHOULD be proposed as pull requests, and MUST be discussed on
   the mailing list, and MUST have chairs explicitly confirm consensus."
I agree with the "MUST be discussed on the mailing list" (as this is inline
with RFC2418 e.g. 3.2 but therefore doesn't necessarily need to be normative in
this doc) but find the other two SHOULD and MUST too strict. I don't think this
is aligned with the process we have today in groups and we should not use this
document to make the process more strict than it is. Especially I'm not sure
what "chairs MUST explicitly confirm consensus" really means and it seems to be
a requirement independent of GitHub and therefore eventually would even update
RFC2481.

11) Sec 5.4.4:
It might be too late for this kind of input, however, as I review the document
I'll note it here anyway. In taps we also have a "discuss" label to mark issue
that has been discussed but need further discussion e.g. at an (interim)
meeting. For this, one could even create a milestone to indicate at which
meeting more discussion should take place (or when e.g. a document is
text-ready until when text should be provided). We/the editors also did this
for a while in taps.

12) Section 6 seems to encourage revision only in preparation for meetings. I'm
not sure if that is inline with our usual working practice. I mean yes in
reality we see the draft submission deadline as forcing function for updates
and there want to keep it but we also do encourage to rev documents more often
and work continuously, e.g. when a mayor change was implemented or a mayor
issue resolved. And yes this works probably better for smaller documents but
the section seems a bit contradicting to this practice. I mean the reason that
we see many updates just at the draft deadline is because editors assign time
to make updates to resolve issue to match the deadline. If editors make
continuous changes we should encourage to update more often. Maybe it could
rather say something like: "Revisions SHOULD be submitted as I-Ds when a
signification issue has been resolved. Editors MAY bundle multiple changes in
one revision if updates are done in timely close coherence and SHOULD update at
least two weeks before any meeting." However, some of this advise is actually
not GitHub specific and might again just touch our general guidelines and as
such update RFC2026 and RFC2418...

13) sec 7:
"   Chairs MUST consider input from all discussion venues when assessing
   consensus including GitHub, mailing lists, interim meetings, and IETF
   meetings."
This seems like an update to RFC2481 again... as maybe also some other notes in
this section.