Suspected witch keeps me up all night with a stream of ritual incantations

As I brought up on one such example, miss-isslington seems to be rather noisy on backport PRs. It posted no less than 17 comments (@-ing both me and the committer, which AFAIK will re-subscribe both of us even if we unsubscribe) over a three hour period, all but one or two were just either stating the status check had succeeded or that they were still in progress, and thus not really necessary/actionable.

Adding a few other events times @-ing two people (me, the author, and @storchaka , the committer) and a team auto-requested for review, times three backport PRs, one for each bugfix branch, adds up to potentially several hundred notifications. That seems likely to consume a non-trivial amount of contributor and core dev attention—a commodity in perpetually short supply.

Can the bot instead just make one comment initially when the status check passes or fails, and then only comment once on an actionable state change? This might also help with the API ratelimit issues mentioned previously, if they are still a problem.

It seems there are several open issues and at least one PR on the bot’s repo, but it doesn’t look like there was much discussion or activity on them over there, and I wanted to bring it up here to cast a wider net for feedback as to the impacts of this on others and what the desired solution is. Thanks!

5 Likes

Miss Islington is indeed a bit noisy. I think we can just completely remove the “Status check has failed/succeeded” comments; for my workflow at least, they’re not useful.

4 Likes

We discussed this briefly on Discord, and it seems to me that:

I think the notifications are useful in two situations:

  • while waiting for all the mandatory checks to pass, in case the author wants to merge the backport manually and be notified when they are done
    • in this case a single message when they all passed is enough
    • the message could be skipped if the PR is going to be automerged
  • when one or more optional checks fails after the merge
    • in this case the message should be posted only in case of failure
    • it should link to the failed check

This is an example of optional check that failed after the merge: [3.10] gh-80856: doc: reveal doctest directives (GH-92318) by miss-islington · Pull Request #92494 · python/cpython · GitHub (note that it doesn’t say which check failed, but I was able to figure it out from the issue).