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

[Martin Thomson <[e-mail]>]

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.

On Mon, Mar 9, 2020, at 17:44, Barry Leiba via Datatracker wrote:
>    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.

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
> supports v6?

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

> Please use the boilerplate directly from 8174: it was debated and worded as it
> 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...

>    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?

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