On 5 Apr 2014, at 1:41, Boris Dušek wrote:

sorry if I missed it somewhere, but what is the best way to report bugs/feature requests in TextMate?

It depends on the bug/feature request and the user’s preference. The options are listed at http://macromates.com/support (and also a primer on writing bug reports).

Will the github issues come back? Or is still the best way for some user who wants to report accessibility bugs to write to the textmate mailing list? Or to the textmate-dev mailing list?

If the user is OK with mailing lists, then this list is fine (textmate-dev is sort of a legacy list that I am considering shutting down), otherwise one can write support or try IRC (where I am often available).

I’m not sure if GitHub Issues will be back, it felt like an unwanted chore, and as people can still submit bug reports or suggest features, the loss of the issue tracker is IMHO negligible — the main advantage people tend to claim is that one can search through existing issues, nonetheless I closed issues as duplicates daily, so in practice few used that feature, and was just burdening me with administrative work that was hard to outsource (and adding more noise to the issue tracker that degraded the searching experience).

If you’re asking from the POV of a contributor, i.e. how can you be made aware of accessibility issues, then we can relay issues reported.

We can also do a new mailing list for people who use the accessibility features. This would also allow soliciting feedback about the current accessability support and make more detailed announcements about the changes being done to improve it.

...

Will the github issues come back? Or is still the best way for some user who wants to report accessibility bugs to write to the textmate mailing list? Or to the textmate-dev mailing list?

If the user is OK with mailing lists, then this list is fine (textmate-dev is sort of a legacy list that I am considering shutting down), otherwise one can write support or try IRC (where I am often available).

I’m not sure if GitHub Issues will be back, it felt like an unwanted chore, and as people can still submit bug reports or suggest features, the loss of the issue tracker is IMHO negligible — the main advantage people tend to claim is that one can search through existing issues, nonetheless I closed issues as duplicates daily, so in practice few used that feature, and was just burdening me with administrative work that was hard to outsource (and adding more noise to the issue tracker that degraded the searching experience).

If you’re asking from the POV of a contributor, i.e. how can you be made aware of accessibility issues, then we can relay issues reported.

Please feel free to relay to me any accessibility issues reported by any channel (except this mailing list which I follow) to you.

I was asking about GitHub issues because I myself prefer some tracker like that. I like to be able to write down issues when they occur to me or anyone else, review the issue list from time to time, close issues as they get fixed etc. E.g. right now I have at least 2 issues that I am keeping in my head :-) and will not be fixing them right away.

But another idea occurred to me - maybe I could then open GitHub issues on my fork of textmate (https://github.com/dusek/textmate/) and mark it as only for accessibility (I already preemptively did that with the fork page title). As the issue topic would be limited to accessibility, closing duplicates would probably not be such a burden (and would be done by me :-)

If you have no objection to that, I would then open the Issues on my fork as that would be the way I would prefer to keep track of accessibility issues. If someone submitted something to the list (or it was relayed to me), I would simply put it in that tracker to not forget it and be able to get back to it sometime. Then README.md on textmate/textmate could get updated to point to the dusek/textmate issues for accessibility issues only.

Would that be OK with you?

We can also do a new mailing list for people who use the accessibility features. This would also allow soliciting feedback about the current accessability support and make more detailed announcements about the changes being done to improve it.

I am not sure that is such a great idea as it might sound at first (mainly for the philosophical reason that since accessibility should be an integral part of a product, accessibility discussions should IMHO be an integral part of the main user mailing list). But I also see the practical advantages you are mentioning. Half of me is for it, half of me is against it - let me think about it for a few days more :-)

Thanks, Boris

(I am terribly sorry for the delay in response, but I was busy with other things...)

On Apr 9, 2014, at 2:22 PM, Allan Odgaard mailinglist@textmate.org wrote:

On 9 Apr 2014, at 3:19, Boris Dušek wrote:

...

[…] another idea occurred to me - maybe I could then open GitHub issues on my fork of textmate […]

I like this idea as it might mitigate some of the scalability problems of GitHub Issues and allows a README associated with reporting an issue, so I went ahead and did:

• https://github.com/textmate/bugs
• https://github.com/textmate/requests

I originally meant e.g. enabling issues at https://github.com/dusek/textmate/issues, but this should work as well.

I don’t understand a few things:

- am I supposed to clone textmate/bugs into dusek/bugs (and similarly for requests) and work there (i.e. log the accessibility bugs there, or direct users to log accessibility bugs there)? Or should I work in textmate/bugs directly (and if yes, would it be possible to add “voiceover” label so that it can be assigned to issues)? - should textmate/textmate’s README.md be updated to point to the bugs and requests repos? If yes, I will submit a pull request to do that.

Thanks for your clarification.