search

jamhall / s3rver

A fake S3 server written in NodeJs
MIT License
574 stars 149 forks source link

Close Stale Issues/PRs #686

Open fishcharlie opened 3 years ago

fishcharlie commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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:

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 commented 3 years ago

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 commented 3 years ago

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:

kherock commented 3 years ago

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.