I agree. I would, however, like to propose maybe 3 week period of time. People go on vacation, or just don't have time to pay attention to issues every day, so 3 weeks seems like a reasonable amount of time to wait for feedback. I would also suggest that we go through and evaluate all issues that are currently in evaluating stage. It would not be fare to close them in bulk due to the fact that we didn't need +1s on the issues before.

👍

GitHub's reaction button does not trigger notifications, but for an example, 👍 reactions are intentions of support. I'm glad that the bot will handle such reactions.

I agree, the growing number of issues makes me a bit nervous. Something between 2 weeks and 1 month seems fine.

My only concern about three weeks is that it's a long time to wait for such feedback (although, compared to forever, like now, it's definitely better).

Can people comment on what they feel is the best waiting period?

And agree @ilyavolodin about going through old issues. That's why I wanted to get this policy in place, so we can go close a bunch of old issues and point back to this discussion.

I mentioned 1 month because 2 weeks sounded a bit aggressive (not against it, though) and it's easier to do the math with 1 month than 3 weeks :). Also because it's the same timespan we have (in theory) for accepted issues in our maintainer guide.

For reference, the current timeframe in that policy to close an issue is 1 year.

We don't have to do math, the days open is listed at the top of the issue. :) We removed the time-based constraints here because we never followed them: e7b1e1c

The 30 day waiting period was for accepted issues (which we can definitely do). What I'm talking about is for unaccepted issues.

My goal is to be as aggressive as possible so we all stay sane. :)

In my opinion, 3 weeks is an acceptable middle ground. I agree with @ilyavolodin that 2 weeks may be a tad too aggressive.
We could re-evaluate after some time, if we still see a lot of "forgotten" issues.

👎

I've seen other projects do something similar, closing out issues after a certain period of inactivity. As a previous user of Sails.js, I felt disappointed and a little abandoned when they implemented their bot and closed out a bunch of old issues which were valid problems but hadn't had much activity (because at some point, once an issue is determined to be a bug, there's not much useful activity that can happen until it's worked on or fixed).

Personally, I don't see the problem with having old valid issues in the stack, and I would rather we lean more towards the side of keeping unnecessary issues around than prematurely closing out valid issues and therefore loosing visibility on them.

If we do go down this road, I think we need to be very careful and thoughtful about how we implement it, or we will quickly garner the ill will of many users and potential contributors.

Maybe a more gentle approach would be for our bot to periodically ping the OP and most active commenters to remind them the issue is still open, and ask them to close it if possible, leaving the final decision to a human. It could also add a label to indicate the issue is old and inactive. But, if an issue is still an issue, I think it does a disservice to everyone to automatically close it out.

I agree with @IanVS that we need to be careful about how we go about this, as it could easily make our users contributing issues feel like their voices aren't being heard. I'd also be worried about closing viable issues that we just haven't gotten around to fixing yet.

That being said, it's hard to imagine that all our older issues will be resolved - I tried to go through and close out some of the older issues when I first started contributing, but at this point it's hard to know if the issues still need to be worked on and can be difficult to get the information we need to actually work on the issue when they were filed so long ago.

I really like the idea of a bot pinging on some of the older issues. What if the bot pinged after 2 weeks of inactivity as a reminder to take a look and then pinged once again after 3 weeks of inactivity to suggest closing the issue?

I feel like that could be a good way to make the process transparent and give fair warning to our users while still bringing our attention to issues that might get lost along the way and making sure all issues are not static and are moving towards a resolution.

First, I think there's been a misunderstanding here: the bot isn't going to do any closing, we are. This is explicitly not a discussion about what the bot should do, it's about our overall policy. We can have a separate issue to talk about what changes, if any, the bot should have to support our overall policy at a later point in time.

@IanVS I think you missed some of my earlier points. The commenting period is for unaccepted issues - that means we haven't been able to make any progress on it. If it's a verified bug, it will be marked as accepted and wouldn't fall under this policy (though we should also discuss what to do about long-lived accepted issues as well). Bugs tend to be verified fairly quickly, so I'm not too worried about important bugs falling through the cracks. What we're really focusing on here are enhancement and feature requests that no one is paying attention to and are otherwise a distraction.

@kaicataldo

That being said, it's hard to imagine that all our older issues will be resolved - I tried to go through and close out some of the older issues when I first started contributing, but at this point it's hard to know if the issues still need to be worked on and can be difficult to get the information we need to actually work on the issue when they were filed so long ago.

This is precisely the point. No one feels like going back and triaging old issues, or tracking down the people who originally opened them, so they just sit there and gather dust. We're not doing anyone a favor by keeping old issues around when we have no intention of working on them.

All that said, the question we need to answer is:

What is the correct commenting period for unaccepted issues?

I proposed 2 weeks, @ilyavolodin countered with 3 weeks. It seems like there is more support for 3 weeks, so I'm happy to go along with that. Other thoughts?

Understood - sorry for going off on a tangent. I'm 👍 for 3 weeks.

I was wrong about when relative dates become absolute so 👍 to 3 weeks