Subject: [Ietf-and-github] Closing issues

From: Rob Sayre <[email-masked]>
Date: Fri, 1 Nov 2019 17:00:26 -0700

Hi,

This one happened to me today: an editor unilaterally closed a github issue
I raised.

The specific subject matter isn't so important for this list, but I thought
it was an interesting problem: Who should be able to close issues?

In my case, a WG chair concurred with the closing, but I sincerely doubt
that he weighed in ahead of time.

thanks,
Rob

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 01 Nov 2019 17:06:25 -0700

On Fri, Nov 1, 2019, at 5:00 PM, Rob Sayre wrote:
> Hi,
> 
> This one happened to me today: an editor unilaterally closed a github 
> issue I raised.
> 
> The specific subject matter isn't so important for this list, but I 
> thought it was an interesting problem: Who should be able to close 
> issues?

This will certainly vary across WGs, so the best we can probably do is as the current text in [1] suggests:

   "Chairs MUST provide guidance on who is permitted to close an issue and under what conditions."

Best,
Chris (chair hat on)

[1] https://ietf-gitwg.github.io/using-github/draft-ietf-git-using-github.html#rfc.section.4.1.2

> In my case, a WG chair concurred with the closing, but I sincerely 
> doubt that he weighed in ahead of time.

---

From: Rob Sayre <[email-masked]>
Date: Fri, 1 Nov 2019 17:08:48 -0700

>    "Chairs MUST provide guidance on who is permitted to close an issue and

That seems like a good idea. But should those terms be public?

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Fri, 1 Nov 2019 17:43:10 -0700

> That seems like a good idea. But should those terms be public?

I might add: the ethical considerations here are interesting. I have an
open, if uninteresting, security bug filed on all browser vendors at the
moment (I'm not trying to make money: any bounty will be donated).
WebKit/Apple are primarily at fault, as far as I can tell, but I await a
response.

I don't think that situation signals a problem in itself, as I doubt IETF
participants are reading those security bugs. But I do think it means that
public WG GitHub terms would increase confidence in the IETF.

thanks,
Rob

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 2 Nov 2019 00:59:30 +0000

+1

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 2 Nov 2019 01:02:20 +0000

> But I do think it means that public WG GitHub terms would increase confidence in the IETF.

I don’t see what github transparency is any different from the already-existing mailing list transparency.

---

From: Rob Sayre <[email-masked]>
Date: Fri, 1 Nov 2019 18:09:01 -0700

On Fri, Nov 1, 2019 at 6:02 PM Salz, Rich <[email-masked]> wrote:

>
>
> *>* But I do think it means that public WG GitHub terms would increase
> confidence in the IETF.
>
>
> I don’t see what github transparency is any different from the
> already-existing mailing list transparency.
>

Hello,

I'm sorry if I was unclear. As far as I know, there are a lot of procedures
around declaring consensus on mailing lists in the IETF.

My concern is that topics can be deemed appropriate for GitHub, and
diverted from a WG mailing list. That might
inappropriately suppress discussion if those issues can then be closed
based on non-public terms in GitHub.

thanks,
Rob

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 2 Nov 2019 01:15:15 +0000

*   My concern is that topics can be deemed appropriate for GitHub, and diverted from a WG mailing list. That might inappropriately suppress discussion if those issues can then be closed based on non-public terms in GitHub.

Yes, that is a concern that *this* working group is definitely trying to discuss and address.

---

From: Rob Sayre <[email-masked]>
Date: Fri, 1 Nov 2019 18:26:42 -0700

On Fri, Nov 1, 2019 at 6:15 PM Salz, Rich <[email-masked]> wrote:

>
>    - My concern is that topics can be deemed appropriate for GitHub, and
> Yes, that is a concern that **this** working group is definitely trying
> to discuss and address.
>

Yes, that's why I joined this WG to post my initial message.

If I really wanted to disagree on a procedural point in a specific WG, I
would just fork them and write my own draft.

thanks,
Rob

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 1 Nov 2019 21:41:44 -0400

Looking at the draft, I think something that would address the issue Rob 
is raising is that the first paragraph of 4.1.2 (about closing issues) 
get an extra sentence.  Along the lines of:
     As noted in section 2.2, this guidance MUST be communicated to and 
agreed by the working groups.

One can argue that this is implicit in the document.  It seems like it 
could help clarity and can't hurt.

Yours,
Joel

On 11/1/2019 9:26 PM, Rob Sayre wrote:
> 
> 
> On Fri, Nov 1, 2019 at 6:15 PM Salz, Rich <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>       * My concern is that topics can be deemed appropriate for GitHub,
>         and diverted from a WG mailing list. That might
>         inappropriately suppress discussion if those issues can then be
>         closed based on non-public terms in GitHub.____
> 
> 
>     Yes, that is a concern that **this** working group is definitely
>     trying to discuss and address.
> 
> 
> _______________________________________________
> Ietf-and-github mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-and-github
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 2 Nov 2019 15:22:14 +1300

> agreed by the working groups.

Agreed.
 
> could help clarity and can't hurt.

It's already clear in the document that normal IETF process rules
apply, i.e. RFC2418 etc. That certainly implies quite a lot, including
of course that contested decisions are appealable.

Common sense says that editorial issues could be closed by whoever fixes
them, but substantive decisions seem like WG consensus calls. The text says
"Restrictions on closing issues are generally not advisable until a
document has reached a certain degree of maturity."

I'm not sure what that means. Doesn't the fact that a document has been
adopted by the WG mean that it has indeed reached a certain level of
maturity and that future decisions are WG decisions, not author decisions?

Regards
   Brian

---

From: Rob Sayre <[email-masked]>
Date: Fri, 1 Nov 2019 19:42:13 -0700

> of course that contested decisions are appealable.

That is interesting. Has anything ever been overturned on appeal?

It would be good to record such an occurrence in future documents.

thanks,
Rob

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 2 Nov 2019 17:51:49 +1300

> That is interesting. Has anything ever been overturned on appeal?

For GitHub usage, I have no idea. In general:
https://tools.ietf.org/html/rfc2026#section-6.5
https://www.ietf.org/standards/process/appeals/
Appeals can be dealt with between the appellant, the WG Chairs, and the AD,
without invoking the formal process, and those go uncounted.

Regards
   Brian

On 02-Nov-19 15:42, Rob Sayre wrote:
> On Fri, Nov 1, 2019 at 7:22 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Rob Sayre <[email-masked]>
Date: Fri, 1 Nov 2019 22:07:54 -0700

> without invoking the formal process, and those go uncounted.

Right,

I was wondering if anything had ever been overturned on appeal using this
process.

thanks,
Rob

> [email-masked] <mailto:[email-masked]>> wrote:
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 3 Nov 2019 08:28:06 +1300

On 02-Nov-19 18:07, Rob Sayre wrote:
> 
> 
> On Fri, Nov 1, 2019 at 9:51 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I was wondering if anything had ever been overturned on appeal using this process.

Well, I've never done an analysis, but I'd say most of the formal appeals ended up with a compromise decision rather than a complete overturn, even for the ones that were further appealed to the IAB. But for appeals settled at the AD level, we have no idea because there's nowhere that they are logged.

That doesn't mean the appeal mechanism is an empty threat, though. I think it keeps everybody on their toes. Because of cases like the one you brought up, it needs to be 100% clear that decisions taken via GitHub are appealable, IMHO.

Regards
    Brian

>     > On Fri, Nov 1, 2019 at 7:22 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     > Looking at the draft, I think something that would address the issue Rob
>     >     > is raising is that the first paragraph of 4.1.2 (about closing issues)
>     >     > get an extra sentence.  Along the lines of:
>     >     >      As noted in section 2.2, this guidance MUST be communicated to and
>     >     > agreed by the working groups.
>     >
>     >     Agreed.
>     >
>     >     > One can argue that this is implicit in the document.  It seems like it
>     >     > could help clarity and can't hurt.
>     >

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 04 Nov 2019 15:04:30 +1100

> and under what conditions."

I wanted to point out that this is the critical text, however most repositories don't operate under IETF Working Group processes.  Unless the Working Group formally assumes control over a repository, the owner of the repository can do as they please with it.

There is also advice in that document that advises chairs to give editors considerable latitude in how they manage document repositories.  It's only in the case where the issues in a repository serve as a formal record of the state of Working Group process that you need a formal process around the closing of issues.

Opened https://github.com/ietf-gitwg/using-github/issues/27 to look at making the on-ramp a little more ramp-like.  I think that people starting the process probably won't want to concern themselves with formalizing every aspect of the way that tool works.  But once they start depending on some feature, that is when strict rules need to be in place.

---

From: Mike Bishop <[email-masked]>
Date: Tue, 5 Nov 2019 16:45:31 +0000

The process we've used in QUIC has been that in the early stages post-adoption, the changes in a draft reflect the editors' proposals on the issues; there are consensus calls on *document versions*, to ensure that any point where there is not consensus on what's in the document has an issue filed.  As the draft gets more stable, consensus calls are on a per-issue basis before text is put into the drafts.  The latter is considerably slower, and can be challenging for a document where there's a large volume of change at a rapid pace.

-----Original Message-----
From: Ietf-and-github <[email-masked]> On Behalf Of Brian E Carpenter
Sent: Friday, November 1, 2019 10:22 PM
To: Joel M. Halpern <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ietf-and-github] Closing issues

On 02-Nov-19 14:41, Joel M. Halpern wrote:
> Looking at the draft, I think something that would address the issue 
> Rob is raising is that the first paragraph of 4.1.2 (about closing 
> issues) get an extra sentence.  Along the lines of:
>      As noted in section 2.2, this guidance MUST be communicated to 
> and agreed by the working groups.

Agreed.
 
> could help clarity and can't hurt.

It's already clear in the document that normal IETF process rules apply, i.e. RFC2418 etc. That certainly implies quite a lot, including of course that contested decisions are appealable.

Common sense says that editorial issues could be closed by whoever fixes them, but substantive decisions seem like WG consensus calls. The text says "Restrictions on closing issues are generally not advisable until a document has reached a certain degree of maturity."

I'm not sure what that means. Doesn't the fact that a document has been adopted by the WG mean that it has indeed reached a certain level of maturity and that future decisions are WG decisions, not author decisions?

Regards
   Brian

>> If I really wanted to disagree on a procedural point in a specific 
>> WG, I would just fork them and write my own draft.
>>
>> thanks,
>> Rob
>>