Subject: [Rfced-future] Request to allow commenting on issues on GitHub

From: Lars Eggert <[email-masked]>
Date: Tue, 25 May 2021 15:45:51 +0300

Hi,

this is a request to allow participants to directly comment on the issues on GitHub, rather than requiring all such comments to be sent by email.

Almost nobody identifies the issues when they send email to the list, making it difficult to track which email(s) discuss which issue(s). Not being able to comment directly on issues also eliminates much of the usefulness of using an issue tracker in the first place.

We can configure GitHub such that comments made on the web site are auto-emailed to the list, so that the discussion is archived. GitHub can also be configured such that replies to such issue emails are reflected back into the issue discussion there.

Thanks,
Lars

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 25 May 2021 13:56:55 +0100

Just so long as material issues, comments, and decisions are seen on the
list, and no one commenting on the list is ever told, "This was already
discussed on github" (OK to say, "This was already discussed on the list").

A
-----Original Message-----
From: Rfced-future <[email-masked]> On Behalf Of Lars Eggert
Sent: 25 May 2021 13:46
To: [email-masked]
Subject: [Rfced-future] Request to allow commenting on issues on GitHub

Hi,

this is a request to allow participants to directly comment on the issues on
GitHub, rather than requiring all such comments to be sent by email.

Almost nobody identifies the issues when they send email to the list, making
it difficult to track which email(s) discuss which issue(s). Not being able
to comment directly on issues also eliminates much of the usefulness of
using an issue tracker in the first place.

We can configure GitHub such that comments made on the web site are
auto-emailed to the list, so that the discussion is archived. GitHub can
also be configured such that replies to such issue emails are reflected back
into the issue discussion there.

Thanks,
Lars

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 25 May 2021 14:00:58 +0100

Oh, FWIW, I looked at the last 100 messages on the list.
Of those, 22 did not contain an issue number in the subject line - all the
rest did.
Of those 22, some were list admin, and some were raising/discussing new
issues.

So, I contest "almost nobody" and suggest that the system may be working
fine.

A

-----Original Message-----
From: Rfced-future <[email-masked]> On Behalf Of Lars Eggert
Sent: 25 May 2021 13:46
To: [email-masked]
Subject: [Rfced-future] Request to allow commenting on issues on GitHub

Hi,

Thanks,
Lars

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 25 May 2021 09:34:00 -0400

What I have seen in other uses of github comment reflection is that it 
is not effective.  One gets an email with a comment saying things like 
"no, that won't work".  Obviously commenting on some other unknown 
comment.  When people email they understand that they need to preserve 
context.  Have their been improvements in the github commenting system 
to make the emails work better?

Put differently, please, no.

Yours,
Joel

---

From: Lars Eggert <[email-masked]>
Date: Tue, 25 May 2021 17:31:49 +0300

Each issue is a mail thread, so if you use a mailer that has threading, you will see the context.

-- 
Sent from a mobile device; please excuse typos.

> On May 25, 2021, at 16:34, Joel M. Halpern <[email-masked]> wrote:
> 
> What I have seen in other uses of github comment reflection is that it is not effective.  One gets an email with a comment saying things like "no, that won't work".  Obviously commenting on some other unknown comment.  When people email they understand that they need to preserve context.  Have their been improvements in the github commenting system to make the emails work better?
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 25 May 2021 10:37:58 -0400

Just having email threading in my reader is not sufficient.
I have email threading.  While useful some of the time, it also causes a 
number of artifacts that make handling my email harder.  And it requires 
that I retain email (since I want to be able to read and review email 
off line) that may get responded to.

Yours,
Joel

---

From: Colin Perkins <[email-masked]>
Date: Tue, 25 May 2021 23:30:05 +0100

Agree this would be helpful. 

There seems little point in having an issue tracker that we can’t use to comment on the issues. 

Colin

> On 25 May 2021, at 13:45, Lars Eggert <[email-masked]> wrote:
> 
> Hi,
> 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 25 May 2021 16:23:59 -0700

I agree with Colin and Lars. I can live with having this on the list, but I
personally find the issue tracker more useful as a venue.

-Ekr

On Tue, May 25, 2021 at 3:30 PM Colin Perkins <[email-masked]> wrote:

> > this is a request to allow participants to directly comment on the
> issues on GitHub, rather than requiring all such comments to be sent by
> email.
> >
> > Almost nobody identifies the issues when they send email to the list,
> making it difficult to track which email(s) discuss which issue(s). Not
> being able to comment directly on issues also eliminates much of the
> usefulness of using an issue tracker in the first place.
> >
> also be configured such that replies to such issue emails are reflected
> back into the issue discussion there.
> >
> > Thanks,
> > Lars
> >
> > --

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 May 2021 11:35:45 +1200

Joel is correct. Mixing these two modes really doesn't work well, because collectively we have such a wide variety of mail user agents.

Regards
   Brian C

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 26 May 2021 09:13:04 +0900

> off line) that may get responded to.

What Joel said, very much indeed!

I also use threading, but for me at least, that still means that I have 
to move up and down through the thread to get the context, I won't just 
'see' the context. Also, I read virtually all of my mail in my inbox, 
but then filter it into topic folders. That means that threading gets me 
some immediate context some times, but for more context, I would have to 
start digging.

My guess is that github isn't too interested in producing useful emails; 
like every site, they want traffic to their site, and the emails they 
produce do that job. Github's setup also creates a culture where it's 
okay to have a comment consisting of (half of) a sentence, and another 
comment a few minutes later. And the fact that it's impossible to write 
a comment explaining e.g. why an issue gets closed and close the issue 
at the same time also contributes to the missing context problem.

There are issue trackers that are much better at creating reasonable 
emails with context. That also seems to help users provide context in 
their comments. Github could learn quite a bit from such systems.

Regards,   Martin.

P.S.: Email often comes with too much context, because people are too 
lazy to remove stuff, but too much is still better than not enough.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 25 May 2021 17:19:59 -0700

On Tue, May 25, 2021 at 5:13 PM Martin J. Dürst <[email-masked]>
wrote:. Github's setup also creates a culture where it's

> at the same time also contributes to the missing context problem.

This is not correct. If you type something into the comment box, "Close"
becomes "Close with comment", which does what you are asking for.

-Ekr

---

From: Michael StJohns <[email-masked]>
Date: Tue, 25 May 2021 22:09:48 -0400

> Put differently, please, no. 

What Joel said....

Mike

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 25 May 2021 19:55:47 -0700

I find it strange that as we near accomplishing a document and lots of
conclusions that we're revisiting how to communicate within the working
group over a decision that was previously made.

[Oh wait, I must be new here]

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 26 May 2021 15:25:08 +1000

From the perspective someone who's set up and maintained GitHub-based flows in multiple groups, a few responses and comments:

> GitHub, rather than requiring all such comments to be sent by email.

I support this.

> using an issue tracker in the first place.

Yes. The issue tracker is delivering very little value because of this disconnect.

> into the issue discussion there.

-1. In my experience, this creates what people perceive as noise on the mailing list. I think it's better to just summarise GitHub discussion on the list when necessary, or failing that, to direct GitHub e-mails to a second list.

> discussed on github" (OK to say, "This was already discussed on the list").

In a well-run group, this should never happen; if I saw it happen, I would immediately call it out as inappropriate. For a group like this, I think it'd be appropriate for *all* decisions to be made on-list.

The appropriate thing to say is that there has been some discussion on GitHub, but that doesn't imply a decision was made there. The folks who aren't on GitHub should be caught up, by one of the following mechanisms:

a) They can follow the links to the issues to read them on the site, responding as necessary on-list
b) The status of discussion on GitHub can be summarised on-list and then discussed there

Note that neither of these requires someone to have a GitHub account; (a) requires someone to read a Web page on a site that they don't have an account on (which IMO is a reasonable thing to ask).

IME having discussion of an issue both on-list and on-tracker is manageable in most circumstances; in both directions, a summary can be recorded to periodically sync the discussions if necessary. Exceptionally, you can state that an issue's discussion has been moved to the mailing list for a period of time (e.g., with a GitHub label).

Wes said:

> I find it strange that as we near accomplishing a document and lots of conclusions that we're revisiting how to communicate within the working group over a decision that was previously made.

I think this has come up because we're coming to a stage where we're likely to discuss a number of finely-grained issues about the text. IME that's been shown to be *much*  more efficient in an issue tracker that's integrated into the source repository, as on GitHub.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 May 2021 12:00:18 +0200

Hi,

On 26.05.21 07:25, Mark Nottingham wrote:
> I think this has come up because we're coming to a stage where we're likely to discuss a number of finely-grained issues about the text.

I think Mark's right about this aspect.

EKR wrote:

> I agree with Colin and Lars. I can live with having this on the list, 
> but I personally find the issue tracker more useful as a venue.

Me too,  BUT...

In *this* group there are those who do and those who don't.  My larger 
concern is that those who do and those who don't properly develop ideas 
*together*, even if they're starting from very different points of view.

Also, let's not kid ourselves: this is a hard problem.  I think some of 
this falls on the chairs, so that we can keep everyone in sync, but 
we're just two people, and we will miss stuff.

Eliot

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 26 May 2021 14:47:50 +0000

Let's not relitigate the GIT working group.

If we're going to use git, the WG has to come to consensus on that. (Perhaps we already did and a snoozed through that thread.)