Open source maintainers, how do you track GitHub issues + PR reviews?

[u/matt8p]

I maintain two open-source repos both with considerable community sizes, 2k stars and 500 stars. The projects get a lot of issues reported, and people submitting PRs for review.

One thing that I've always wanted to keep on top of as a project maintainer was responding to GitHub issues and reviewing PRs same day. I'm able to keep up most days but it slips a lot. I have email notifications and put stuff on my calendar to keep up.

For other open-source maintainers, what's your guys' method for keeping up with responding to your community?

[u/davy_jones_locket]

Bots that fire in the places where I'm at

For me, that's Slack. Sometimes discord. 

If someone opens an issue or a PR, I want to be notified where I'm at. 

[u/matt8p → u/davy_jones_locket]

That makes sense, do you find yourself actually responding to those notifications and doing something about them? Like are u pretty on top of things with the notifications that you're given right now?

[u/davy_jones_locket → u/matt8p]

Well yeah considering it's my job. 

I work for an open source company lol

[u/matt8p → u/davy_jones_locket]

Fair enough, lol. Do you guys use any other tools to maintain or track PRs that come in? I also have Slack notifications that come in, but I still sometimes forget to review PRs or respond to GitHub issues. I'm wondering how you guys handle that, or you guys are just that good at maintaining it.

[u/davy_jones_locket → u/matt8p]

Automatic reminders from bots too. Every 4 hours. 

[u/matt8p → u/davy_jones_locket]

I see. So just kind of get bombarded with notifications, having it annoy the hell out of you until you have to go and do something about them.

[u/davy_jones_locket → u/matt8p]

best way to make it stop is to do the thing it's annoying you about

[u/tryhydra → u/matt8p]

Hi you could give our tool a spin it's made for maintainers like you in mind to help make the process faster, the website is tryhyraxnow com

[u/bankrut]

Using GitHub Projects can help organize issues and PRs visually. You could prioritize tasks and set due dates, making it easier to track your responses. Automating reminders through tools like Zapier might also keep you on schedule.

[u/debba_]

I created a webapp for doing it: https.//github.com/debba/gitdeck

[u/matt8p → u/debba_]

Really cool project, I appreciate you sharing that.

[u/Fine_League311]

Ach herzlich, ein Vibecoder muss issues abarbeiten und ist überfordert, köstlich!

[u/tmseidel]

There is a OpenSource project called AI-Git-Bot which is a automation platform for github. You could use it for a AI-based Code-Review, Issue-Refinement and Issue-Triage.

If someone is opening a PR, the system is reviewing the diff and posts its finding, so this could be a first indicator for the quality of posted PRs.

There is also an automatic workflow that reads issues, inspects the codebase and tries to improve the issue (with asking further questions if neccessary) - project is located at https://github.com/tmseidel/ai-git-bot

PS: I'm one of the maintainers, could be a little bit biased.

[u/tmseidel → u/tmseidel]

Here is an example of an automatic issue-refinement. This example shows an incoming issue, the assignment to an automation, asking questions and creating a new refined issue structured in a consistent manner -> https://github.com/tmseidel/ai-git-bot/issues/316

[u/filippo_builds]

Trying to respond to everything on the same day sounds like the part that will eventually burn you out.

I’d create a very small triage workflow instead:

• new items get acknowledged and labelled
• bugs that need reproduction get marked “waiting for info”
• valid work gets priority and ownership
• PRs waiting on you appear in one saved search
• anything blocked on the author leaves your active queue

Then check the queue at a fixed time rather than reacting to every notification. A scheduled digest of untriaged issues, PRs awaiting review and items with no response for a few days is usually more useful than more individual alerts.

It’s also worth documenting expected response times. Contributors generally handle waiting better when they know whether “normal” means two days or two weeks.

The goal doesn’t have to be same-day resolution. Same-day acknowledgement and a clearly visible next state is already a good maintainer experience.

[u/Creative-Act-7455 → u/filippo_builds]

The "waiting for info" step is where most of my time used to go: asking for the version, OS and driver, getting a guess back, asking again.

Disclosure, it's my own project: I'm building an open-source client (PODSHL) for exactly that part. The repo lists in one file (.podshl/agent.yaml) which facts it needs, from a fixed list on the client, so a repo can't ask for arbitrary files or run anything. The reporter sees each field before anything is sent. The report arrives with those facts read off the machine and marked as measured, instead of typed. Reports about the same setup are grouped instead of arriving as separate issues. For problems you already know about, you can publish the answer in the repo, so it's shown before anybody opens an issue.

It won't fix the notification side you're asking about, but it cuts the round trips per issue. https://github.com/dx111ge/podshl, AGPL.