5 ms·

I think this is perfectly acceptable. If the user hasn’t demonstrated a reproducible problem and more information is required, the user has a week to submit sai

I think this is perfectly acceptable. If the user hasn’t demonstrated a reproducible problem and more information is required, the user has a week to submit said information. If not, the issue is cleaned up automatically. I don’t see why the maintainers should have to manually revisit each ticket if the OP fails to respond. And auto-closing doesn’t mean the issue can’t be reopened. If OP posts additional information after the grace period, the maintainers will be notified and the ticket can be reopened.

diggan 6y ago
Yeah, guess we all have different processes for dealing with reports/GitHub Issues. For me, a closed issue signals a closure of some sort, either that it's not accurate, been fixed, or any other reason. Simply that time has passed does not count as "resolution" for me. But in the end, whatever works for you!
- xboxnolifes 6y ago
  > For me, a closed issue signals a closure of some sort, either that it's not accurate... In this case, wouldn't it fall under being "not accurate" if the issuer doesn't supply requested information showing that it's accurate?
  - diggan 6y ago
    No, as I wouldn't have the full picture of the issue, I can't say if it's accurate or not.
- codethief 6y ago
  Maybe another status "stale" would be the solution here. That way, maintainers would be able to focus on "active" issues while the people who reported the issue could still add information to the issue later on to move it from "stale" back to "open" / "active".
  - diggan 6y ago
    I'd reverse it and say you should have a status for when something is done discussed about, and implementation path is clear "Ready for development" or something like that. Then people who are looking for things to develop, they filter by that. Anything that is not "Ready for development" either needs triaging, or another type of closure.

diggan 6y ago

Yeah, guess we all have different processes for dealing with reports/GitHub Issues. For me, a closed issue signals a closure of some sort, either that it's not accurate, been fixed, or any other reason. Simply that time has passed does not count as "resolution" for me. But in the end, whatever works for you!

xboxnolifes 6y ago
> For me, a closed issue signals a closure of some sort, either that it's not accurate... In this case, wouldn't it fall under being "not accurate" if the issuer doesn't supply requested information showing that it's accurate?
- diggan 6y ago
  No, as I wouldn't have the full picture of the issue, I can't say if it's accurate or not.
codethief 6y ago
Maybe another status "stale" would be the solution here. That way, maintainers would be able to focus on "active" issues while the people who reported the issue could still add information to the issue later on to move it from "stale" back to "open" / "active".
- diggan 6y ago
  I'd reverse it and say you should have a status for when something is done discussed about, and implementation path is clear "Ready for development" or something like that. Then people who are looking for things to develop, they filter by that. Anything that is not "Ready for development" either needs triaging, or another type of closure.