-
|
Hi, what do you use to manage this problem? I'm sure this is not just this project problem. AI generates a lot of issues and PRs. A lot of them a good, but the maintainer can't be expected to read all of them. So lots of them go stale. How do you deal with this? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
This repo runs the same problem — GSD-2 generates PRs for its own development, and the volume is real. The approach that works here: issue-first workflow (PRs without linked issues get returned), adversarial code review (no rubber-stamps), stale closure at 5 days for unreplied change requests, and an automated triage workflow that processes the full backlog each run. The key leverage points: (1) labeling everything so you can filter, (2) requiring tests so low-quality PRs close themselves, and (3) not letting "it looks fine" substitute for an actual review. See https://github.com/gsd-build/gsd-2/blob/main/CONTRIBUTING.md for the standards this repo enforces. |
Beta Was this translation helpful? Give feedback.
This repo runs the same problem — GSD-2 generates PRs for its own development, and the volume is real. The approach that works here: issue-first workflow (PRs without linked issues get returned), adversarial code review (no rubber-stamps), stale closure at 5 days for unreplied change requests, and an automated triage workflow that processes the full backlog each run. The key leverage points: (1) labeling everything so you can filter, (2) requiring tests so low-quality PRs close themselves, and (3) not letting "it looks fine" substitute for an actual review. See https://github.com/gsd-build/gsd-2/blob/main/CONTRIBUTING.md for the standards this repo enforces.