Feature Request
Describe the Feature Request
I think the project should be more transparent about a) including this specific workflow, and b) allowing it to be more easily configurable.
My projects are mostly pretty small. If I get contributions, I'm willing to give a long time for contributors to respond to feedback, and I might never close an issue, even if it hasn't had activity, in case someone is willing to take it up at some point in the future. (I don't mind issues being closed so much as them being locked to new comments.)
PR #2 is actually a good example. For your project it may make sense to mark it as stale after 30 days, and close it a week later, but for me that would be too quick. I don't have many contributors, and I want to give them more leeway.
If this is added to an existing project, maintainers might not realize this is one of the workflows being enabled, and/or might not realize the timeline that's now being enforced.
I realize one can go in and just remove the workflow or change the days-before-stale
or days-before-close
values, but this is about surfacing something that could be a surprising or disruptive change for a small project.
Describe Preferred Solution
-
Assuming you don't want to inquire in the setup process about every single workflow, consider making this one a special case and allowing people to enable/disable it on setup.
-
If enabled, inquire in the setup what the values of days-before-stale
and days-before-close
should be.
-
Note in the project documentation how to remove or change this workflow (and maybe workflows in general) if it isn't important to a project.
Describe Alternatives
Just do number 3 above. To me that would be sub-optimal, but better than not mentioning it at all.
Related Code
Additional Context
N/A
If the feature request is approved, would you be willing to submit a PR?
(Help can be provided if you need assistance submitting a PR)