Subject: [Jsonpath] I have an idea

From: Greg Dennis <[email-masked]>
Date: Thu, 4 Mar 2021 20:02:58 +0000 (UTC)

I'm still not sure why we're so stuck on using the email list for discussing specific changes to the specification, the source for which is stored on GitHub.  Carsten has said that GitHub is archival, so it's an "approved" medium to have discussions.  Moreover, GitHub issues have been specifically designed for the purpose of discussing the content of the repository, in our case, the specification document.
Emails lose context.  The only thing linking one email to another is the subject line, and then the sent date.  Multiple threads can spin off, and one quickly loses context.
But GitHub issues maintain that context in an easy-to-navigate interface.  Moreover, they support Markdown formatting which allows more expression than plain-text emails.  (Yes, we can have HTML emails, but no one's using them.)
So... to my idea.
<idea>
I propose that we use GitHub to orchestrate email discussion.  It's actually quite simple:
1. Create a GitHub account for [email-masked]. Subscribe that account to the ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath repository and configure the account to receive email updates on everything.
Now have email archives on literally everything that you could want: issues, PRs, build statuses, etc.  Additionally, people replying to those emails (assuming they use "reply all" to include the GitHub sender) would end up on the source issue.
For example, I create an issue.  GitHub sends an email to [email-masked], which we all get.  Carsten wants to make a comment, so he replies to the email (just like he's always done), keeping the GitHub sender in the recipients list.  Carsten's response is recorded on the GitHub issue for people who want to track it there.  GitHub further sends and update to [email-masked], which we all get.
Additionally, the Slack integration that I've set up posts to the workspace's #github channel.  I've been notified (as if the emails weren't enough) that there's been activity in GitHub, so I can go check it out.  (It actually has links and a preview of the content as well.)  I respond directly on GitHub, and it sends an update to [email-masked]... which we all get.
</idea>
I know that you're all probably tired of hearing me expound the benefits of working in not-email.  I understand the need to have this discourse archived in case it needs to be referenced later.
There are tools that have been explicitly designed for maintaining threads of specific topics for the purpose of enacting change to a specific domain.  GitHub is one of those, and I suggest we use it to its full capacity.
Emails were not designed for this.  GitHub was.  Let's use it.
Greg
P.S. If you have an idea that is a bit rough around the edges, and you want to knock the corners off before proposing your well-rounded proposal in an issue, email is good for that.

---

From: Glyn Normington <[email-masked]>
Date: Thu, 4 Mar 2021 21:07:47 +0000

While I endorse using GitHub issues for particular, focussed discussions, I
wonder whether subscribing this mailing list to all GitHub activity would
be counterproductive, particularly for those of us who prefer to subscribe
to GitHub activity directly.

Another option would be to create a separate [email-masked]
mailing list which could be used to subscribe to GitHub. This would give us
archival and would not force participation onto subscribers to this list.
Just a thought...

On Thu, 4 Mar 2021, 20:03 Greg Dennis, <gregsdennis=
[email-masked]> wrote:

> I'm still not sure why we're so stuck on using the email list for
> discussing specific changes to the specification, the source for which is
> stored on GitHub.  Carsten has said that GitHub is archival, so it's an
> "approved" medium to have discussions.  Moreover, GitHub issues have been
> specifically designed for the purpose of discussing the content of the
> repository, in our case, the specification document.
>
> Emails lose context.  The only thing linking one email to another is the
> subject line, and then the sent date.  Multiple threads can spin off, and
> one quickly loses context.
>
> But GitHub issues maintain that context in an easy-to-navigate interface.
> Moreover, they support Markdown formatting which allows more expression
> than plain-text emails.  (Yes, we can have HTML emails, but no one's using
> them.)
>
> So... to my idea.
>
> <idea>
>
> 1. Create a GitHub account for [email-masked].
> 2. Subscribe that account to
> the ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath repository and configure
> the account to receive email updates on everything.
>
> Now have email archives on literally everything that you could want:
> issues, PRs, build statuses, etc.  Additionally, people replying to those
> emails (assuming they use "reply all" to include the GitHub sender) would
> end up on the source issue.
>
> For example, I create an issue.  GitHub sends an email to
> [email-masked], which we all get.  Carsten wants to make a comment, so
> he replies to the email (just like he's always done), keeping the GitHub
> sender in the recipients list.  Carsten's response is recorded on the
> GitHub issue for people who want to track it there.  GitHub further sends
> and update to [email-masked], which we all get.
>
> Additionally, the Slack integration that I've set up posts to the
> workspace's #github channel.  I've been notified (as if the emails weren't
> enough) that there's been activity in GitHub, so I can go check it out.
> (It actually has links and a preview of the content as well.)  I respond
> directly on GitHub, and it sends an update to [email-masked]... which
> we all get.
>
> </idea>
>
> I know that you're all probably tired of hearing me expound the benefits
> of working in not-email.  I understand the need to have this discourse
> archived in case it needs to be referenced later.
>
> There are tools that have been explicitly designed for maintaining threads
> of specific topics for the purpose of enacting change to a specific
> domain.  GitHub is one of those, and I suggest we use it to its full
> capacity.
>
> P.S. If you have an idea that is a bit rough around the edges, and you
> want to knock the corners off before proposing your well-rounded proposal
> in an issue, email is good for that.
>
> --
> Jsonpath mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jsonpath
>

---

From: Glyn Normington <[email-masked]>
Date: Thu, 4 Mar 2021 21:14:09 +0000

I should add that one of the advantages of GitHub issues is the ability to
*unsubscribe* from issues which are (no longer) of interest. This would be
trickier in a mailing list subscribed to all GitHub issues - another reason
for a separate list.

On Thu, 4 Mar 2021, 21:07 Glyn Normington, <[email-masked]>
wrote:

> While I endorse using GitHub issues for particular, focussed discussions,
> I wonder whether subscribing this mailing list to all GitHub activity would
>> But GitHub issues maintain that context in an easy-to-navigate
>> interface.  Moreover, they support Markdown formatting which allows more
>> expression than plain-text emails.  (Yes, we can have HTML emails, but no
>> one's using them.)
>>
>> So... to my idea.
>>
>> <idea>
>>
>> [email-masked], which we all get.  Carsten wants to make a comment,
>> so he replies to the email (just like he's always done), keeping the GitHub
>> There are tools that have been explicitly designed for maintaining
>> threads of specific topics for the purpose of enacting change to a specific

---

From: Glyn Normington <[email-masked]>
Date: Thu, 4 Mar 2021 21:15:49 +0000

Whoops: I meant "... *unsubscribe* from issues which are not (any longer)
of interest".

On Thu, 4 Mar 2021, 21:14 Glyn Normington, <[email-masked]>
wrote:

>>> directly on GitHub, and it sends an update to [email-masked]...
>>> which we all get.
>>>
>>> </idea>
>>>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 4 Mar 2021 22:31:52 +0100

Please check RFC8874, specifically

https://www.rfc-editor.org/rfc/rfc8874.html#name-monitoring-activity

I’m neutral to a jsonpath-issues list — I’m already watching the repo.
Getting the automatic summary in place is a no-brainer, though.
(The repo should be converted to Martin Thomson’s template so we get among others the benefit of some archiving of issues as well.)

Grüße, Carsten

> On 2021-03-04, at 22:07, Glyn Normington <[email-masked]> wrote:
> 
> While I endorse using GitHub issues for particular, focussed discussions, I wonder whether subscribing this mailing list to all GitHub activity would be counterproductive, particularly for those of us who prefer to subscribe to GitHub activity directly.
> 
> Another option would be to create a separate [email-masked] mailing list which could be used to subscribe to GitHub. This would give us archival and would not force participation onto subscribers to this list. Just a thought...
> 
> On Thu, 4 Mar 2021, 20:03 Greg Dennis, <gregsdennis=[email-masked]> wrote:
> 2. Subscribe that account to the ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath repository and configure the account to receive email updates on everything.
>