For me, I think the assignee for a PR should be someone who will merge it (or make sure that it will get merged). For example, in the above mentioned PR, it makes sense that I am considered a reviewer (which is implicitly flagged by GitHub), but I would not fit the role of assignee since it ought to be someone who has the write permission that will click “merge” in the end. It then makes sense for @pocmatos’s tool to notify the assignee.

I like your idea - which sounds like it might be the purpose of the assignee to PRs.

In this case, you are the reviewer and I can be the assignee for the merge once it gathers enough reviews.

I took the bait and looked this up. As I initially expected different projects with different workflows use this differently or don’t use it at all but I like this answer: https://stackoverflow.com/a/41174022/290516

Which seems to hint at the same thing you do.

I will go ahead and keep that in mind as I write a process proposal.

if people want some triage to do, https://github.com/racket/racket/issues/3457 has a bunch of good candidates

@samth I hope the sci item can be crossed off. I made a commit 2 days ago to fix the problem. I notice the log file above is 4 days old, but I don’t know where to look for a newer log file.

On the subject of general triage, what I usually do is periodically (every week or so) go through my github notifications to tag issues and/or prod issue reporters for more info. Is that useful to people?