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 <mt@lowentropy.net> 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.
>
> 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".
>
> _______________________________________________
> Ietf-and-github mailing list
> Ietf-and-github@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-and-github
>