Hi, I agree that PR's getting more and more difficult to handle when they are inactive, but issues and bugs are normally not gone/fixed by waiting, so I won't auto close them.
As written during the GitHub migration discussion by several others: We need to triage them regulary. Yes this is work, but at least I'm motivated to do it (and thinking about options to support us doing this). I know that I most probaly can't handle them all, but I want to give it a try. Matthias Am 10.02.2025 um 18:58 schrieb Slawomir Jaranowski:
Hi, I added shared GitHub action to management stale - old issues and PRs. In first step I add an automation for items with label: waiting-for-feedback, and we have for such items: - will mark as stale after 60 days - will close after next 30 days - items with milestone or labels `priority:blocker`, `priority:critical` will not be checked - waiting-for-feedback label will be removed after comments To apply such automation we need to add a GitHub action in the project, I will prepare a documentation and example PR for it. In next step we can manage for all other issues and PRs, so questions: - do we want to automatically close issues and PRs? - how many days wait for it to become stale? - how many days wait to close after marking as stale? - we can exclude some with specific labels and so on from checking To be clear first automation step add stale label and message about it ... so it will be notified again Personally I'm for closing old items .... especially PR are difficult to merge after long time due to code changes and conflicts -- Sławomir Jaranowski --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
