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

1. 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.

2. If enabled, inquire in the setup what the values of days-before-stale and days-before-close should be.

3. 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)

• Yes
• No

I recently switched from actions/stale to sonia-corporation/stale.

actions/stale appears to have no further active development, and sonia-corporation/stale has a nice feature: exempting from marking as stale all issues that are in a project (along with issues that are in milestones, or assigned to someone, both of which actions/stale already had). So if people are proposing features, simply accepting them by adding them to a project, like say a version release plan, will keep them from being marked stale without having to add extra labels.

sonia-corporation/stale also has a much more comprehensive documentation site: https://sonia-corporation.github.io/stale/

The Yaml keys in the workflow have different names but there's basically a 1:1 correspondence, so it was very fast to update my existing workflow to a new one.

Anyway just passing this along in case it's helpful!

https://github.com/premail/premail
Have a great example with better input data template

Feature Request

Describe the Feature Request

There is some wording in some places that seems a little clunky or unclear -- I'm not sure if this is a translation issue or something else, but I thought I could offer some suggestions for making things more straightforward.

Describe Preferred Solution

Happy to make a PR with suggestions if you're open to it.

Describe Alternatives

N/A

Related Code

N/A

Additional Context

I don't have any, but I could probably find style guides etc. if you want "objective" citations for my opinions on things :)

If the feature request is approved, would you be willing to submit a PR?
Yes / No (Help can be provided if you need assistance submitting a PR)