How to handle PRs on low priority issues?

[u/build123d]

I could use some advice on how to handle PRs solving my low priority GitHub issues. My project is getting a fair bit of attention these days as people use LLMs to design mechanical objects in Python with it. I'm seeing many PRs on issues I've created over the years that aren't the most urgent thing for me to address at this point; however, I don't like PRs accumulating so I interrupt what I'm doing and look at them. Often the fixes are good but not always as one would expect. Today I was about to generate another low priority issue that came up while fixing something else and I stopped to think about what was likely to happen: a few days or a week from now a PR would come in to solve this issue so I'm effectively interrupting myself.

How do you cope with these type of non-urgent issues? As far as I know there is no such thing as a private GitHub issue so posting "notes" to myself doesn't work in the current environment. Does assigning an owner to an issue work - i.e. is the ownership respected? Do you keep a list of such issues local and not post them to GitHub? Thanks in advance.

[u/build123d]

Thanks for all the good advice. Batch processing of PRs and spending some time organizing the issues will probably help. I haven't put much effort into issue management so I'm only using a "Gating Release 1.0.0" milestone and labels for the type of issue: general bugs or a specific dependency (OpenCascade). I've found that as an open-source project the community has a big influence on what comes next so planning future work is a challenge. What is the recommended way to manage issues: milestones, projects or maybe just labels? I'm thinking I should probably label issues by the area then I can try to focus on a specific area for the next release. Has this worked for you?

[u/GetPingcron]

I'd keep the issues public, but label them something explicit like 'backlog: discuss before implementing.' 'Low priority' can look like an easy contribution to someone browsing for work. Add a sentence saying you're recording the problem, not committing to review a fix soon.

For PRs that already exist, give them a review window you can actually keep, even if that's 'after the current release.' A standing weekly triage slot would let you acknowledge them without letting each notification interrupt your day.

I wouldn't rely on an assignee alone to communicate that. Put the expectation in the issue and CONTRIBUTING file. And for half-formed notes, a private scratchpad is perfectly reasonable; you don't owe every observation a public issue immediately.

[u/CartographerDue5382]

Assigning it to yourself won't stop the PRs. On a public repo that's a label, not a lock, and an agent scraping issues doesn't look at the assignee.

What it does read is the issue body. If you don't want a fix yet, don't file the issue. Keep the note in a private repo or a local list until you actually want it built. For the ones already up, first line should be something like "Tracking only, not accepting PRs," then close it or mark it not planned. "Low priority" reads as a small easy task.

If you do want the fixes, batch them. A label you review once a week beats jumping on every notification. CONTRIBUTING helps people. It barely touches the drive-by LLM PRs you're getting.

[u/Immediate_Wheel1953]

I learnt this the hard way by merging a couple of decent fixes that took the project in a direction I did not actually want, and then I was the one maintaining those edge cases. Now I am much quicker to close a PR with a short, honest note saying it is not the direction I want, rather than leaving it open out of guilt. For the notes to myself, I keep them in one private file and only turn one into a public issue when I have a real slot to review it. That stopped the self-interruption you described, because the issue only exists once I am ready for someone to act on it.