[csarva]

> Effort spent on improving a software rarely goes wasted.

Rarely wasted? Have you seen how many open issues and pull requests on github just languish there forever by unconcerned maintainers? Or projects with a million forks because the maintainer has moved on?

Stating up front that you're not going to even entertain bug reports definitely has an impact on those wishing to improve the software and contribute back. For one, it precludes an entire class of supporters (users who report bugs) from even helping out at all.

[quarnster]

For this project in particular in its current state, I don't need people pointing out where it's broken. I know that it's broken and close to useless in fact and that there's a huge list of things to fix, implement or improve.

So if closing up the issues section gets rid of this unneeded negative reinforcement, that's a good thing and working exactly as intended.

[josephlord]

It is absolutely your choice to have issues or not and as you describe the current project status it is almost certainly the right choice for the moment.

If you intend to the issues up when you reach another state (e.g. widely usable) then indicating that the not accepting issues is a temporary state would be good. I completely understand not wanting issues raised when you already have dozens of things that you know that you need to do already.

From a user point of view the issues list is something I often look at before even using a project to see the activity, scale of the current problems people are having. I also find it a useful source of answers/workarounds. That doesn't mean that you can't be decisive about what issues you choose to work on (from a user perspective a clear response of "no time to work on this issue, send a PR if you sort it" is better than silence).

[rattray]

If you file the issues yourself, you can show to everyone else that you're working on them. That's exactly the kind of communication ST is lacking. Plus, you'll learn about bugs you didnt encounter, so they can be fixed (by you or others) before you have to hit them yourself.

[kelnos]

Give the guy a chance to write a functioning editor first. I'm sure he'll reconsider opening up the issue tracker after the thing is actually useful, and maybe has a few more contributors to share the load.

No one is entitled to anything with open source, not even support or a bug tracker. The author is trying to provide an open source alternative to a closed source product controlled by an uncommunicative company. He deserves support and help, not people telling him what to do.

[sergiosgc]

Try walking a mile on his shoes. Bug triaging is a burdensome task. It is perfectly understandable that, for a one man team working in an incomplete software, his decision is to focus 100% in development of his vision.

Or are you volunteering to do the bug triage part?

[ewzimm]

You're exactly right. I've heard a lot of developers burn out over the sheer amount of work github generates, let alone the amount of entitlement people feel to your labor once you publish your code. If we want to do social coding, we need to be sociable about it.