On 24 Mar 2013, at 15:43, Meryn Stol wrote:
[…] Removing a place to submit issues to doesn't make the issues go away.
Which is why I am pointing to IRC, mailing list, or writing MacroMates directly.
I think I would be doing people a disservice if I kept the issue tracker open but ignored issues, because people have a natural expectation that opening an issue on the official TextMate repository will have someone from the team address their issue.
There is also the problem that pull requests are treated as issues, so if I unwatch issues, I am not notified about pull requests, and just the general “bad smell” of having hundreds of issues open, many of which may be invalid, having a solution, etc.
I don't see how on this mailing list, you should be any less careful on "not to upset" a submitter.
I don’t need to close every letter sent to the mailing list with a reason as to why I decided to close it.
[…] Maybe ask people to solve some random crossword before being able to submit an issue or feature suggestion?
I would like for GitHub to present a first time splash-screen before posting an issue, basically just stating what the issue tracker should be used for and linking to http://kb.textmate.org/writing_bug_reports
But the goal is not to introduce obstacles for reporting bugs or suggesting features, it’s that the GitHub issue tracker is not suitable for troubleshooting and many feature requests.
For a feature request, if I like it, I just add it to my to-do list in the appropriate section with the appropriate priority. If I don’t understand it, I’ll ask you to elaborate and/or explain what problem you’re trying to solve, and that may result in tweaking another part of TextMate to accommodate the workflow, or similar. I.e. requesting features is more of a dialog and the end result may be me updating my own to-do list or just having your issue in the back of my head (for when I touch the code involved).
[ Issue Archive ]
Unfortunately GitHub does not have an option for that.
I'm sad to hear that. Do you think you can recover the data somehow in the future, or will you just leave at it this?
The data is still there — I’ll ask GitHub if they can add an option to just disallow creating new issues, without taking it all offline.
As for the future: I have thought of various schemes, maybe keep issue tracker open when there are less than 20 open issues, maybe keep it open up to 24 hours after each update, etc.
[…] add a note in the readme that you might not respond to most issues posted
Previously the README told users a) where to download prebuilt binaries, and b) if you can’t build following the instructions in the README, use IRC or txmt-dev mailing list, *do not open an issue* — yet dozens of issues were opened from people who couldn’t read^H^H^H^H build TextMate… :)
Generally, I think a database with unaddressed (or quickly closed) issue reports is valuable in its own right. For example, a user can then realize he's not alone experiencing a certain issue, or that a feature he/she wishes for is just "not gonna happen", at least not until some kind soul stands up and does it voluntarily.
For bugs, yes, a public database is now sorely missed.
For feature requests, it might be useful with a list of “this has been requested a lot so you don’t need to request it again”, but given that roughly 20% of issues on GitHub were duplicates, I am not sure how much searching people do. A curated list might actually work better than telling people “search before you open a new issue”.