ci: mark issues and PRs as stale #2554
Conversation
|
I am unsure about this. Often, issues are inactive because of us devs not having the time to answer all of them in time, not because of the contributors. Is there any accepted polite strategy to take this into account? |
|
A good way to get progress into an issue is to create a PR with a test case that reproduces the issue. Maybe rather than closing them automatically after some time, we could have some bot logic that checks whether an issue is linked to a PR and if not the logic could add a label first, noting that the issue needs a PR that adds at least a test case? |
|
Only for bugs of course, not for enhancement requests. Also, I think that enhancement requests should never be marked as stale. |
|
I think we can still mark issues and PR as stale since, even though it is probably due to devs not having enough time, they are still stale. What we could definitely do, is disable closing issues; this way they would just be marked stale. Apart from that, for issues/bugs, I like the idea of checking if a PR exist with a test case that reproduces the error, but not quite sure how to implement it. How would you link the issue to the PR? If the PR is referenced? By the issue or PR name? |
Ok, agreed!
Yes, that is also unclear to me. I have no good solution to be honest. |
|
Or we can also set the closing of a stale issue only after a long time (e.g. one year). After a long time, it is likely that the issue might not be relevant, or need re-testing with the newest version. Either way, it will force the user to do something and/or remind the devs if the issue is still relevant. This will help to clean up irrelevant (or where the user lost interest) issues and make easier for devs to focus on the important issues. Right now, the longer an issue is open, the less likely it is someone will find it (since it drowns among all the other issues). |
|
Ok, that sounds good. So we mark as stale first, and after one year of being stale, we close it automatically. |
|
Done for issues. |
|
Description
QC
docs/) is updated to reflect the changes or this is not necessary (e.g. if the change does neither modify the language nor the behavior or functionalities of Snakemake).