dontcallmedom / github-notify-ml Goto Github PK

I submitted this issue today: w3c/webauthn#700
webauthn WG has notify-ml config'd to fwd such issue submissions to the mailing list as individual messages. no email msg for the latter issue has appeared on the list even though I have submitted a subsequent issue w3c/webauthn#701, which has appeared on the list (and I've waited a couple hours before submitting this).

when initially submitted, the opening parag of w3c/webauthn#700 was like so:

CredMan](https://w3c.github.io/webappsec-credential-management/) PR w3c/webappsec-credential-management#114 "Remove the blanket restriction against nested usage" adds the sameOriginWithAncestors parameter to the internal methods ....

note the missing "[" (left square bracket) in front of "CredMan](..." in the first line.

that is the only reason I can think of that this issue was not successfully forwarded to the mailing list.

Note: i have since added the missing "[" (left square bracket) to w3c/webauthn#700

The current code seems to generate noncompliant From: headers for users whose names contain special characters like [], for example:

https://lists.w3.org/Archives/Public/public-svg-issues/2018Aug/0179.html
https://lists.w3.org/Archives/Public/public-geolocation/2019Mar/0030.html

As of yesterday W3C's mail hubs will reject such noncompliant messages, so it would be good to fix this. I think I have a working patch; will submit a PR in a few minutes.

Had some huge threads in a PR the other day (admittedly, that's not the right place for it, but things happen...).

Would be great to have those documented somehow. Especially given there are APIs for this.

Thanks for the script, first of all!

Having configured it for the Second Screen WG we see an issue with the notifications for pull request, in this example, the source of the mail (with "Received" headers removed):

Date: Thu, 12 Feb 2015 08:32:36 +0000
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Anssi Kostiainen via GitHub <[email protected]>
To: <[email protected]>
Message-ID: <[email protected]>
X-W3C-Hub-Spam-Status: No, score=-2.2
X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1, AWL=-1.203, T_RP_MATCHES_RCVD=-0.01,
 URIBL_BLOCKED=0.001
X-W3C-Scan-Sig: lisa.w3.org 1YLpCO-0007cn-JT
 7645b565d1324b751b375bcba99614bd
X-caa-id: 4f3ae2fc6f
X-Original-To: [email protected]
Subject: [presentation-api] Pull Request: Use the custom W3C Document
 License defined  in the Charter
Archived-At:
 <http://www.w3.org/mid/[email protected]>
Resent-From: <[email protected]>
X-Mailing-List: <[email protected]> archive/latest/195
X-Loop: [email protected]
Resent-Sender: <[email protected]>
Precedence: list
List-Id: <public-secondscreen.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:[email protected]>
List-Unsubscribe:
 <mailto:[email protected]?subject=unsubscribe>
Return-Path:
 public-secondscreen-request+bounce-dominik.rottsches=intel.com@listhub.w3.org
X-MS-Exchange-Organization-AVStamp-Mailbox: NAI;57084253;0;novirus
X-MS-Exchange-Organization-AuthSource: ORSMSX104.amr.corp.intel.com
X-MS-Exchange-Organization-AuthAs: Anonymous
MIME-Version: 1.0
X-Evolution-Source: 1391783486.6368.4@drottsch-MOBL1

anssiko has just submitted a new pull request for=20
https://github.com/w3c/presentation-api:

=3Dse the custom W3C Document License defined in the Charter =3D=0A=
The group's Charter defines a custom Document License [1] the=20
documents produced by this group should use. To that end, I updated=20
the Editor's Draft as well as the FPWD snapshot in staging=20
accordingly.

@tidoust Pubrules checker naturally does not understand this custom=20
Document License, so this needs to be checked manually.

[1] http://www.w3.org/2014/secondscreen/charter.html#doclicense

See https://github.com/w3c/presentation-api/pull/54

The subject of the PR is:
Use the custom W3C Document License defined in the Charter

However, when receiving the mail, it's mangled to:
=3Dse the custom W3C Document License defined in the Charter =3D=0A=

Sometimes repos receive spam/abusive issues filed, which get manually deleted by the repo maintainer... for issues that have been get deleted, could they be filtered out of a the summary?

Recent example (see "ok" + the other obvious one):

We've been happily using this script (thanks for making it btw!) for weekly repo synopses for the IETF LAKE WG with the emails being sent from a gmail a/c. That's broken recently as gmail seemingly no longer accepts username/pwd authentication, at least as we've set it up. The error we're seeing is:

smtplib.SMTPAuthenticationError: (535, b'5.7.8 Username and Password not accepted. Learn more at\n5.7.8  https://support.google.com/mail/?p=BadCredentials 4-20020a1c1904000000b00xxxstuffxxx.14 - gsmtp')

Following that link (and a bit of searching) seems to imply that using oauth2 might work, so I'm wondering if anyone's done that already or plans to do it soonish?

Right now, eventFilter appears to only include events that include the listed label. It'd be great if it could be inverted, to be able to filter out a label.

Use case is to exclude issues, etc. with the label editorial.

It would be helpful to track all the repos associated with a Group so that when new repos are created they automatically get added into the notifier without an extra maintenance task.

I use threading in my email client to group emails together. Threading does not work with comments on a pull request though.

It may be due to the fact that the email subject is different for the pull request and for the comment on the pull request. When someone issues a pull request, the email subject is along the lines of "Pull Request: [PR title]". However, when someone makes a comment on the pull request, the subject becomes "Re: [PR title]" (thus losing the "Pull Request" prefix).

A concrete example:

• Pull request and comment on GitHub: w3c/presentation-api#96
• Threaded view in the archives: https://lists.w3.org/Archives/Public/public-secondscreen/2015May/thread.html (PR and comment are not linked together but should be)

I do not really know what would be the most appropriate resolution here, either adjust the subject or add the right email header in the email generated by the comment to enable threading.

It may be related to #4 but it seemed different enough to create a separate issue.

Do the right thing...

As mentioned in private email, i find the short line lengths irksome, as they break the patterns that are useful when skimming the text. I'd prefer no line length restrictions.

Adding this comment here in case someone else has a good idea how to do that.

Dom answered the following to my original request:

I am wrapping lines in my code (probably at 80 characters); although I
know different mail clients manage line wrapping differently, my
impression is that the most portable approach is to wrap it at the
sending side. I for one (using Thunderbird) suffer from some email
messages with impossibly long lines that require scrolling.

But if there are well-documented mechanisms that gives us the best of
the two worlds, I'm happy to take a look.

As suggested by Bjoern:
http://lists.w3.org/Archives/Public/public-media-capture/2014Dec/0028.html

In addition to subscribing to a digest of updates from a repository, It would be really nice if we could further filter by label. This would be particularly useful for the really big repositories such as web-platform-tests. E.g. for web-platform-tests, I would set up a digest for the SVG WG for things that have the label 'svg' or 'wg-svg'.

GitHub introduced a pull request review mechanism that groups inline review comments together and allows a reviewer to approve or request changes to the PR with a review summary comment.

Issue #20 discusses inline comments. The comment I'm most interested here is the review summary along with the decision to approve/reject the review. The tool currently seems to miss it, so I suppose this review summary comment does not get reported in an issue_comment.created event.

I'm not sure what event gets triggered in that case, perhaps pull_request_review_comment?

For an example of a pull request with a review summary comment, see: w3c/presentation-api#351

See e.g. http://lists.w3.org/Archives/Public/public-media-capture/2014Dec/0021

One difficulty is the ambiguity of what github comments are: they can be in response to the top level issue, or to an existing comment in the issue, or to a pull request, …

Looking at https://lists.w3.org/Archives/Public/public-web-nfc/2015Mar/thread.html, it appears that sequences of activity on a single pull request produce a separate thread for each action. e.g. [web-nfc] new commits pushed by kenchris Kenneth Rohde Christiansen via GitHub (Monday, 16 March) should be a reply to [web-nfc] Pull Request: Fix This Charter URL Anssi Kostiainen via GitHub (Monday, 16 March)

Similarly, Re: [mediacapture-main] Edit to address issues #73 and #96, i.e. remove file as source for MediaStream(Track)s should be a reply to [mediacapture-main] Pull Request: Edit to address issues #73 and #96, i.e. remove file as source for MediaStream(Track)s. To get those two to thread in gmail, you'll probably need to make their subjects more similar, not just add the In-Reply-To: header.

def getRepoData(repo, token):
    url = "https://api.github.com/repos/%s" % repo
    headers = {}
    ...

Shouldn't url be "https://api.github.com/%s/repos" ?

This notification (which this announcement led me to trace back to this repository) says:

cwilso has just transferred the repository WICG/first-party-sets to WICG

which doesn't make a whole lot of sense, since it seems to say that the repository was transferred from WICG/first-party-sets to WICG. It would probably be nice to say where it was transferred from, e.g.:

cwilso has just transferred the repository krgovind/first-party-sets to WICG/first-party-sets

or maybe it was actually (since I'm not sure which location was more recent!):

cwilso has just transferred the repository mikewest/first-party-sets to WICG/first-party-sets

... but if you don't know where it came from, it would be better if the notification said something more like:

cwilso has just transferred the repository first-party-sets to WICG/first-party-sets

so that it doesn't sound like it was transferred from WICG to WICG.

IIRC this feature was discussed earlier, but I couldn't find an existing issue so I opened a new one. Source for the request: https://lists.w3.org/Archives/Public/public-device-apis/2016Feb/0030.html

Implementation considerations: each message has a unique Message-ID to correlate replies with GH issues, but I believe some email clients do not retain this information in replies. To workaround this could try to encode the information in From, or include the ID in the message body.

I've noticed a couple of times recently that new issues have not found their way into email notifications.

Here's an example from today's notifications. w3c/i18n-issues#2

It should have been listed at https://lists.w3.org/Archives/Public/public-i18n-cjk/2018AprJun/0007.html with the others.

The rule is:

"[email protected]": {
   	"digest:daily": [ 
            { 
            "topic": "cjklreq repos",
            "repos": ["w3c/clreq","w3c/jlreq","w3c/klreq"]
            },
            { 
            "topic": "W3C specs (CJK)",
            "repos": ["w3c/csswg-drafts", "w3c/html", "w3c/ttml2", "w3c/i18n-issues"],
            "eventFilter": {"label": ["i18n-clreq", "i18n-jlreq", "i18n-klreq"]}
            }
            ]
},

The only difference i can see between this issue and the others that got through is that it has two labels, rather than one. No idea whether that is significant.

However, this was notified via another rule to https://lists.w3.org/Archives/Public/www-international/2018AprJun/0033.html. Interestingly, no labels are shown next to the link in that notification.

Seems odd, since the labels were set at around the same time as the issue was created.

This is, obviously, a significant problem when it comes to tracking new comments. Any idea where the problem originates?

We've started to experiment with using GitHub Discussions in an IETF WG, and some have asked for a summary of discussions to show up in the activity summary.

Discussions don't appear to be listed in GitHub event types, but apparently there is GraphQL support.

It would be good to have the possibility to track changes of labels that can follow a certain pattern. If a group is identifying states using a set of labels, having changes of label on one issue within that label group would help figure out the state of the issue and make reports more meaningful. (like [ "triaged", "assigned", "pending feedback", "pending formal decision" ] )

The cedilla in my first name seems to be bogging the tool. The generated From: field, as seen from the mailing-list server is:

From: =?utf-8?q?Fran=C3=A7ois_Daoust_via_GitHub_=3Csysbot+gh=40w3=2Eorg=3E?=

The readable string generated should probably be normalized somehow. Incriminated line:
https://github.com/dontcallmedom/github-notify-ml/blob/master/index.py#L165

I'd like to be able to send to a mailing list a single digest for the following combination:

1. all of the changes to the issues in the w3c/sealreq repo, whether or not they have labels

2. issues in the csswg-drafts, html, and other repos that have the label i18n-sealreq

(sealreq is just an example)

Currently i have to set up two notifications and users receive two emails per day.

i18n recently had a situation where the WG who's spec had been reviewed thought they needed sign-off for all the issues labelled with i18n, however we were simply tracking half of those. So we'd like to use separate i18n-comment and i18n-tracking labels on the same issue list, and have notifications sent to the same mailing list when those labels are applied to an issue and when the issue is closed.

Please could you enable that. Tx.

It would help for weekly planning and reporting to have the information on Monday morning. It would also make it useful for by week summaries of activity.

Events filtered by label "i18n", "i18n-comment", "i18n-tracking",
"HR:i18n-comment", "HR:i18n-tracking", "i18n-review"
Issues

It would be helpful to have a couple of lines of space above "Issues"

It would be nice to bold the repo names, so that they stand out more, but i don't know how we'd do that. On the other hand, i made a copy with an extra line before each repo name, and it helps readability. It also helps you see the blocks related to issues closed and new comments as part of the same repo.

this note is appearing in some auto-gen'd email sent to public-webauthn@ from github/w3c/webauthn repo:

**NOTE:** This service been marked for deprecation: 
https://developer.github.com/changes/2018-04-25-github-services-deprecation/

      Functionality will be removed from GitHub.com on January 31st, 2019.

it is not clear whether the above msg pertains to github-notify-ml or to travis-ci, or both, or something else (?)

We (the QUIC WG) noticed that the digest contained far fewer issue discussions / closures than we anticipated last week (after an exceptionally active editors' meeting).

Is there any known issue / limitation that would explain that?

If not, I'm happy to dig into it, just thought I'd ask first.

Digest days are required to be lowercase in the MLS json:

 if target.has_key("digest:%s" % period.lower()):

... but uppercase when calling sendDigest (e.g., from the command line or a cron job):

days = ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday"]
    if period in days:

This is Confusing.

Are pull request comments covered by issue_comment.created -- ie are PR comments forwarded to the mailing list if the latter event is selected ? Or, might we need yet another template established for pull_comment.created in order to do so? I am guessing the latter is the case, based on what is being sent to the public-webauthn@ list via github.com/w3c/webauthn/.

thx

(which formats to use? .ini, .json, .yaml?)

Initial comment:
webtiming/timingobject#15 (comment)

On the mailing-list:
https://lists.w3.org/Archives/Public/public-webtiming/2015Aug/0027.html

The "From" header is "None via GitHub". It should rather be "Snarkdoof via GitHub". I haven't investigated. On top of my head, two possible reasons why this happened:

1. Snarkdoof does not have a full name: https://github.com/Snarkdoof
2. The comment was left via email reply.

For groups with many specs/repos, setting up repository individually is a pain; providing a Web UI that lets hook this in batch would be nice.

Some potential starting points for a pure-JS approach:
https://github.com/prose/gatekeeper
https://github.com/philschatz/octokit.js/

On 27 Sep i added w3c/webauth to three of our i18n notification digests, and i am only now realising that we have had no digests since then for any of those. I believe this is because the repo name should have been w3c/webauthn.

Can we put in place a mechanism to alert users if a repo is incorrectly spelled, or disappears for some other reason (eg. moved or deleted, etc.)?