Close Stale Issues/PRs

[fishcharlie]

Now that this project is using GitHub Actions, I think it's worth considering using actions/stale to mark issues and PRs as stale.

There seem to be a lot of issues and PRs that have not received a reply from the original author in an extended period of time. These should be closed to help keep the focus on things that are relevant to the project.

An example of a workflow to handle this can be found at: https://github.com/dynamoose/dynamoose/blob/master/.github/workflows/cron.yml.

I'd be happy to submit a PR to do this, but just want to get a sense of support or lack of support before proceeding.

[ad-m]

I have doubts as to whether such automation is really needed at that moment. Recently, pull requests have been inactive for a long period of time. However, this was not due to the inactivity of the original author who reported it. The main reason was the lack of attention and activity from maintaners to indicate the actions needed to merge the changes.

[fishcharlie]

@ad-m That might be true for PRs. But I can point to 5 issues that should likely be closed right now but aren't:

• Drops first 5 letters of bucket name #541
• [Question/feature request] Run static website without having to put each file after bucket creation #617
• Implement Upload Part - Copy #436
• Credentials can't be configured #498
• S3 - BUG - Meta Tags on PUT Command do not work #591

Now, some of those have received replies recently, and probably wouldn't fall within the timeframe for closing as stale. However I think it's difficult to argue that there aren't things that should be closed, and having this automation would help make that happen automatically.

[ad-m]

On the one hand, it is true that there are currently issues that can now be safely closed. On the other hand, an issue has recently been resolved, which in the case of automation would be excessively closed and the work performed was not used.

I have some concerns that the current increase in project activity is short-lived and the bot will close submissions in a way that rejects contributors. I would like to be wrong about the future of the project, because it is possible that then I would be able to spend more time on developing this project for the needs of a certain organization.

[kherock]

In general I have pretty mixed feelings around automating 'staleness', especially when it's with the intent of automatically closing or locking issues. The only people it serves to benefit are the maintainers who don't want to hear any more noise from those issues. I think there's some value for large repos where the sheer volume makes it hard for maintainers to navigate the noise.

However around here, the staleness of an issue doesn't have much bearing over how soon it will be properly addressed by a maintainer. Most issues on this project are for missing features that you can be sure at least a few people have use cases for and would be valid for as long as this project is feature-incomplete. Contribution activity for this project does tend to happen in short bursts, and it's usually by the people who want to see those features implemented.

Also, of the 5 issues you linked, 3 of them still seem to still be valid:

• [Question/feature request] Run static website without having to put each file after bucket creation #617 should only be closed with some documentation improvements because otherwise someone's probably going to open another issue asking the same question
• Implement Upload Part - Copy #436 is a missing feature that has an unfinished implementation as a PR that shouldn't be difficult to pick up
• Credentials can't be configured #498 is currently being addressed by Configurable access credentials #682

[kherock]

That being said, there is a case for at the very least marking reported bugs as stale (but not closing or locking), so I'd be on board with only-labels in combination with the bug label.