Subject: [Ietf-and-github] Barry Leiba's Discuss on draft-ietf-git-using-github-05: (with DISCUSS and COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Sun, 08 Mar 2020 23:44:47 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-git-using-github-05: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have a really simple thing to discuss before I move to a “yes” ballot:

— Section 4.1.3 —

   Chairs need to assess whether the
   arguments offered represent new information or not.  This can require
  some discussion to determine accurately.  Resolved issues MUST remain
   closed unless there is consensus to reopen an issue.

There seems to be an inconsistency here: WGCs decide whether new information
has been given, so it would seem that it’s the WGCs who decide that an issue
should be reopened.  But then we say there has to be consensus for it.  In
addition to that appearing inconsistent, I’m not clear how one would determine
whether there’s rough consensus to reopen an issue, if doing so were
controversial.

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

Idle question: Would it make sense for this document to formally update 2418?

— Section 1.2 —

   GitHub is freely accessible on the open Internet,
   albeit currently only via IPv4.

Why mention v4 only?  Does such mention have archival value once github
supports v6?

   GitHub provides a simplified and integrated interface to not only
   git, but also provides basic user management, an issue tracker,

This doesn’t really work as written; I suggest this:

NEW
   GitHub provides a simplified and integrated interface to
   git, and also provides basic user management, an issue tracker,
END

   along with other improvements that come from broader
   participation by facilitating those in the community to participate.

Participation/participate feels odd.  Maybe, “along with other improvements
that come from facilitating participation by a broader community.” ?

— Section 1.5 —
Please use the boilerplate directly from 8174: it was debated and worded as it
is intentionally.  (That said, this is not a blocking comment.)

— Section 3 —

   Chairs MUST involve Area Directors in any decision to use GitHub for
   anything more than managing drafts.

I’m not objecting to this, but... why?  If the WGCs may decide to use github
for drafts without involving the ADs, why can’t they also decide to use it for
charter revisions, agendas, and minutes without involving the ADs?

— Section 4.2 —

   Pull requests are the GitHub feature that allow users to request
   changes to a repository.

There’s a number agreement issue here (“feature” and “allow”).  I would fix
this by making it all singular, so the sentence doesn’t sound strange:

NEW
   A pull request is a GitHub feature that allows a user to request
   a change to a repository.
END

— Section 4.2.1 —

   In addition to the features that pull requests share with issues,
   users can also review the changes in a pull request.  This is a
   valuable feature, but it has some issues.

You use “issues” here in two different senses; I suggest reserving the word for
referring to github “issues”, and using a different word for “but it has some
issues.”  Maybe, “but it presents some challenges.”

— Section 5.3.1 —

   Finally, process checkpoints like Working Group Last Call
   (WGLC; Section 7.4 of [RFC2418]) provides additional safeguards

Number agreement: “Finally, process checkpoints, such as Working Group Last
Call (WGLC; Section 7.4 of [RFC2418]), provide additional safeguards”.

— Section 6 —

   During the development of a document, individual revisions of a
   document can be built and formally submitted as an Internet-Draft.

Nit: two indefinite articles feels odd; I would make it, “individual revisions
of the document”.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 10 Mar 2020 16:32:32 +1100

Hi Barry,

Thanks for reviewing.  Your PR is https://github.com/ietf-gitwg/using-github/pull/43

Working group, please take a look at some of these changes; I think that they are consistent with the existing intent, but they are substantive changes.  I've added *** in this email for those who want to see just the proposed new text.

> whether there’s rough consensus to reopen an issue, if doing so were

The lens of fresh perspective is wonderful.  I totally see your concern now.

That said, I think that this is good advice still, because it creates a status quo bias in a good way: resolved issues stay resolved unless the WG reaches consensus that there is a need for a change.  For a contentious issue, it might be that there is no desire to relitigate the subject and then nothing

My original intent here was to advise against relitigation of difficult issues.  It is often the case that Working Groups revisit decisions over time, but using an issue tracker creates an artifact that allows us to say "no, we decided X" and therefore avoid having the same debate over and over.  For reference, that text is:

> Issues that have reached a resolution that has Working Group consensus MUST NOT be reopened unless new information is presented.

The last sentence here is just a (bad) repetition of the introductory sentence of the section.  I want to remove that, but then beef this up a little.

*********
> For long-running work items, new contributors often raise issues that have already been resolved. Determining whether an issue requires re-evaluation might require some discussion in the Working Group. Where there was rough
consensus regarding the resolution of a contentious issue, there could be a temptation to restart a debate.
>
> Chairs are empowered to exercise discretion in determining whether to reopen issues.  For more difficult matters, the chairs MAY insist that the Working Group reach consensus on whether new an issue should be reopened.  Note however that any product of this process still needs to have the support of rough consensus in the Working Group, which could justify reopening issues.

The crux of this is that we do empower chairs to guide debate and dictate process (see Section 6.1 of BCP 25).  The advice about consensus to reopen remains, but at a lesser strength (it's advice).  And then there is a reminder that failure to address a real problem can lead to failure of the overall process; if you fail to address a problem, maybe WGLC fails.

> Idle question: Would it make sense for this document to formally update 2418?

The current plan is to add this to BCP 25; there should be a note to the editor to that effect.  I think that is the right way to do this.  Nothing in here *changes* 2418.  But it does add to it.

> Why mention v4 only?  Does such mention have archival value once github

Because people apparently love that subject.  I will remove the albeit.

> is intentionally.  (That said, this is not a blocking comment.)

Hah, I thought that I had managed to remove that variant from all of my drafts :)  And no one else complained...

> charter revisions, agendas, and minutes without involving the ADs?

You know, I think that is how it has always been.  I think that if we're going to the trouble of publishing an RFC on this topic, it's probably OK to soften it.  I'm going to propose two changes: SHOULD, and limiting this to the most extreme modes:

************
> Chairs SHOULD involve Area Directors in any decision to use GitHub, especially where substantive discussion of issues is permitted as described in {{mode-discuss}}.

Where that reference is to the section entitled "Issue Discussion Mode".

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 10 Mar 2020 07:21:38 -0400

+1 on the new changes, particularly the changing of MUST to SHOULD on use
of GitHub, along
with the extra guidance.

tim

On Tue, Mar 10, 2020 at 1:33 AM Martin Thomson <[email-masked]> wrote:

> Hi Barry,
>
> Thanks for reviewing.  Your PR is
> https://github.com/ietf-gitwg/using-github/pull/43
>
> Working group, please take a look at some of these changes; I think that
> they are consistent with the existing intent, but they are substantive
> changes.  I've added *** in this email for those who want to see just the
> proposed new text.
>
> That said, I think that this is good advice still, because it creates a
> status quo bias in a good way: resolved issues stay resolved unless the WG
> reaches consensus that there is a need for a change.  For a contentious
> issue, it might be that there is no desire to relitigate the subject and
> then nothing
>
> My original intent here was to advise against relitigation of difficult
> issues.  It is often the case that Working Groups revisit decisions over
> time, but using an issue tracker creates an artifact that allows us to say
> "no, we decided X" and therefore avoid having the same debate over and
> over.  For reference, that text is:
>
> > Issues that have reached a resolution that has Working Group consensus
> MUST NOT be reopened unless new information is presented.
>
> The last sentence here is just a (bad) repetition of the introductory
> sentence of the section.  I want to remove that, but then beef this up a
> little.
>
> *********
> > For long-running work items, new contributors often raise issues that
> have already been resolved. Determining whether an issue requires
> re-evaluation might require some discussion in the Working Group. Where
> there was rough
> > Chairs are empowered to exercise discretion in determining whether to
> reopen issues.  For more difficult matters, the chairs MAY insist that the
> Working Group reach consensus on whether new an issue should be reopened.
> Note however that any product of this process still needs to have the
> support of rough consensus in the Working Group, which could justify
> reopening issues.
>
> The crux of this is that we do empower chairs to guide debate and dictate
> process (see Section 6.1 of BCP 25).  The advice about consensus to reopen
> remains, but at a lesser strength (it's advice).  And then there is a
> reminder that failure to address a real problem can lead to failure of the
> overall process; if you fail to address a problem, maybe WGLC fails.
>
> The current plan is to add this to BCP 25; there should be a note to the
> editor to that effect.  I think that is the right way to do this.  Nothing
> in here *changes* 2418.  But it does add to it.
>
> You know, I think that is how it has always been.  I think that if we're
> going to the trouble of publishing an RFC on this topic, it's probably OK
> to soften it.  I'm going to propose two changes: SHOULD, and limiting this
> to the most extreme modes:
>
> ************
> > Chairs SHOULD involve Area Directors in any decision to use GitHub,
> especially where substantive discussion of issues is permitted as described
> in {{mode-discuss}}.
>
> _______________________________________________
> Ietf-and-github mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-and-github
>

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 10 Mar 2020 11:24:17 +0000

+1, good changes

________________________________
From: Ietf-and-github <[email-masked]> on behalf of Tim Wicinski <[email-masked]>
Sent: Tuesday, March 10, 2020 7:21:38 AM
To: Martin Thomson <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; The IESG <[email-masked]>; Barry Leiba <[email-masked]>; Christopher Wood <[email-masked]>
Subject: Re: [Ietf-and-github] Barry Leiba's Discuss on draft-ietf-git-using-github-05: (with DISCUSS and COMMENT)

  +1 on the new changes, particularly the changing of MUST to SHOULD on use of GitHub, along
with the extra guidance.

tim

On Tue, Mar 10, 2020 at 1:33 AM Martin Thomson <[email-masked]<mailto:mt@lowentropy..net>> wrote:
Hi Barry,

*********
> Chairs are empowered to exercise discretion in determining whether to reopen issues.  For more difficult matters, the chairs MAY insist that the Working Group reach consensus on whether new an issu…

The crux of this is that we do empower chairs to guide debate and dictate process (see Section 6.1 of BCP 25).  The advice about consensus to reopen remains, but at a lesser strength (it's advice).  And then there is a reminder that failure to address a real problem can lead to failure of the overall process; if you fail to address a problem, maybe WGLC fails..

> Why mention v4 only?  Does such mention have archival value once github

Because people apparently love that subject.  I will remove the albeit..

************

_______________________________________________
Ietf-and-github mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ietf-and-github

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 10 Mar 2020 12:20:17 +0000

>    Thanks for reviewing.  Your PR is https://github.com/ietf-gitwg/using-github/pull/43
  
I read the PR and it's fine.  My only take-away is "what, again with the IPv4 thing?" but if that's the price of clearing a DISCUSS oh well.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 10 Mar 2020 13:22:51 +0100

> I read the PR and it's fine.  My only take-away is "what, again with the IPv4 thing?" but if that's the price of clearing a DISCUSS oh well.

There was a list of protocols people use at IETF.  Some of them were 
IPv6 enabled.  A few are IPv4 only, and critical (BCP?) now(?).

If one made this INFORMATIONAL then there would be less worry?

Alex

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 10 Mar 2020 12:35:42 +0000

I don't understand the point you are trying to make.
  
>    If one made this INFORMATIONAL then there would be less worry?
  
No.  That defeats the whole purpose. Many IETFers use github including some very "important" working groups.  It is very much worthwhile having best practices so that more effective collaboration is possible.  Even something as simple as naming your project ietf-wg-XXXX helps.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 10 Mar 2020 09:00:55 -0400

> My only take-away is "what, again with the IPv4 thing?" but if that's the price of clearing a DISCUSS oh well.

There's no DISCUSS on the IPv4 thing.  My non-blocking (very
non-blocking) comment was "why mention v4 at all?", and Érik
abstained, not DISCUSSed.

b

---

From: Barry Leiba <[email-masked]>
Date: Tue, 10 Mar 2020 09:01:53 -0400

Thanks for the response, Martin.  All good, and I'm going to go shift
the ballot to YES, knowing that the right thing is happening.

b

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 10 Mar 2020 13:02:35 +0000

>    There's no DISCUSS on the IPv4 thing.

My mistake; thanks for the correction.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 10 Mar 2020 14:40:09 +0100

> I don't understand the point you are trying to make.

I wish the following: github on IPv6, draft on BCP.

I do not wish the following: github on IPv4-only and draft on BCP.

> No.  That defeats the whole purpose. Many IETFers use github
> including some very "important" working groups.  It is very much
> worthwhile having best practices so that more effective collaboration
> is possible.  Even something as simple as naming your project
> ietf-wg-XXXX helps.

I agree.

Alex