Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I agree with GP that you don't need to answer anything you don't want to, and ignoring is a valid approach. And I think closing issues is also a valid approach, it's your project after all and you can do what you want. That said, I would prefer maintainers didn't close issues that aren't actually resolved, and instead just ignored them. Maybe apply a label like "Needs more info" or "too busy to investigate" or "help needed" and just filter them out of your view.

The reason for this is that it allows others to chime in and add to the issue, and for users to discuss it among themselves and even find solutions and workarounds. I can't say how many times I've had an issue with some open source project and I find related thread in the github issues. And often the solutions or workarounds are suggested by community members, not the maintainers. But I find it soooo frustrating when the issue has been closed by a "stale bot" because it hasn't been active for 30 days.

This is the spirit of open source, IMO. The creator shares their work with the world, with no commitment or obligation, and the world makes of it what they can. Maybe the maintainer volunteers to help people troubleshoot their issues, or maybe the maintainer is too busy. That's ok. Let the issue sit there, and maybe another kind soul will happen across the issue and answer the question. There isn't enough info to reproduce? That's fine, it's quite possible - even likely - that someone else experiencing the same problem will find the issue and be able to add more context.



I loathe, I despise the stale bot on GitHub. It’s a horrible idea that should never have been implemented, and should be ripped out and thrown away with prejudice in every single case. There is simply no genuine use case for it where it does less harm than good. It is honestly the single thing that I interact with on a meaningfully regular basis that infuriates me the most.


I share your loathing.

The stale bot will unhelpfully ask if "this is still an issue" or if something is being waited on for a pull request. You take the time out to reply, so that stale bot keeps the issue open. Repeat this meaningless back and forth, for months as the maintainers ignore the issue or pull request. Eventually lose the will to continue and let the bot close the issue or pull request.

Net outcome: A potential contribution or solution lost.

Stale bot only exists for aesthetic reasons, to keep issue lists clean and to close issues that maintainers don't want to deal with directly by abstracting away the interaction.

More maintainers should understand that it's OK to just ignore an issue but leave it open.


I'm tempted to make an anti-stale bot that comments on every open Terraform issue to force a human to deal with them. I find new bugs in Terraform providers at least once a week, and invariably they're bot-closed with no resolution. There's no justification for it at all.


Unfortunately, I imagine that GitHub would kill an anti-stale bot even faster than their stale bot kills issues.


I was recently thinking along the same lines. Would definitely use it!


As the maintainer of a moderately popular project on GitHub I'm torn in this. I often get issues where I try to solve the user's problem and think I have answered the question or provided a solution, but don't get any reply from the reporter when asking if it is solved, sometimes for years. I configured Stale Bot with a IMO generous delay so the user has enough time to at least give a short reply if the issue persists. If it does, I'll gladly add a 'pinned' tag to keep Stale Bot away from it. But in the end the bot just does what I'd do by hand anyway.

If it's configured with a short timeout and with preventing further comments, I totally agree. That's rally annoying. But maybe there are circumstances where it's actually useful.


I can't agree more. It's like the CADT model (https://www.jwz.org/doc/cadt.html) but on steroids.


Who owns the issue tracker — the maintainer or the user base?

If the maintainer is using the issue tracker to prioritize development, they should feel fine about closing issues, especially when those issues are underspecified, ignore the project's contribution guidelines, or are otherwise incomplete.

> That's fine, it's quite possible - even likely - that someone else experiencing the same problem will find the issue and be able to add more context.

That's not my experience with issue trackers. It's far more likely that underspecified and otherwise problematic issues accumulate until the issue tracker becomes borderline useless.

The issue is still there if it is closed, including any contributed but unapplied patches.


And you likely meant this, but I have often discovered, or provided, patches.

Upstream may not care about them, but they can help others with edge cases too.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: