[TxMt] Re: github issues forum

[Allan Odgaard]

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”.