Hello,
Why has Github issues forum been removed? It seems I'm now forced to subscribe to a mailing list just for the ability to give feedback.
Is there any archive of the discussions in the github issues forum? Currently, all urls currently resolve to 404. :(
Meryn
On 23 Mar 2013, at 18:59, Meryn Stol wrote:
Why has Github issues forum been removed?
It was not a forum.
It seems I'm now forced to subscribe to a mailing list just for the ability to give feedback.
You can also use IRC or write MacroMates directly: https://github.com/textmate/textmate#feedback
It’s ironic you state this as a problem, not considering that previously I was forced to go to github.com roughly five times a day to assign labels to issues, search for duplicates to properly link them, engage in one-on-one troubleshooting, and for issues that got closed, try to state why it was closed in a way that wouldn’t upset the submitter.
Not saying there wasn’t value in the issue tracker, there certainly was, and part of me feels bad for having closed it, but it was just too much of a distraction.
Long-term it might be back, we may try another issue tracker, or maybe even a forum. But for now, I’ll just focus on development, and I can assure you, despite having closed the issue tracker, there is no scarcity of feedback :)
Is there any archive of the discussions in the github issues forum? Currently, all urls currently resolve to 404. :(
Unfortunately GitHub does not have an option for that.
Hi Allan,
On Sun, Mar 24, 2013 at 10:14 AM, Allan Odgaard mailinglist@textmate.orgwrote:
Why has Github issues forum been removed?
It was not a forum.
Allright, maybe I should have said "board", or "reporting system" instead of forum. I thought just calling it "github issues" was a bit weird because it seemed to refer to "issues with github", or some "collection of issues" or so.
previously I was forced to go to github.com roughly five times a day to
assign labels to issues, search for duplicates to properly link them, engage in one-on-one troubleshooting, and for issues that got closed, try to state why it was closed in a way that wouldn’t upset the submitter.
No, you were not. You could easily ignore most of what was posted there, if you wished. It would just made you seem somewhat unresponsive / inaccessible. Removing a place to submit issues to doesn't make the issues go away. Perhaps they are never shared now.
I don't see how on this mailing list, you should be any less careful on "not to upset" a submitter. Chances are though, that you may receive less feedback you feel you ought to respond too, which may be a good outcome for you. Perhaps, if you feel totally swamped in work, the less communication you get the better. Then any hurdles you set up would be good. Maybe ask people to solve some random crossword before being able to submit an issue or feature suggestion? Then you'll be sure to only get the most pressing ones, or those coming from the most tenacious users. :)
Not saying there wasn’t value in the issue tracker, there certainly was,
and part of me feels bad for having closed it, but it was just too much of a distraction.
I guess this is more closer to reality. I guess it could be a distraction. It much depends on how capable you are in "fully" dealing with feedback. Not only responding to it in word, but also fixing the bugs and implementing the feature suggestions (if they make sense).
Long-term it might be back, we may try another issue tracker, or maybe even a forum. But for now, I’ll just focus on development, and I can assure you, despite having closed the issue tracker, there is no scarcity of feedback :)
Is there any archive of the discussions in the github issues forum?
Currently, all urls currently resolve to 404. :(
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? Maybe the "issues board" always has been a sideshow? It wouldn't have occured me to ever check the Textmate mailing list if you wouldn't have removed it. But maybe the discussions contained are truly inconsequential compared to the info on the mailing list. What I do know is that some github issue reports ranked quite high when googling. I think I have found an answer to questions like this multiple times. I do not recall ever stumbling upon threads on this mailing list.
My preference would be to have the "github issues board" be reinstated. You could add a note in the readme that you might not respond to most issues posted, and that you'll be very aggressive in closing issues. This I fully respect. Generally, I'm very happy that there's active development on Textmate again, and I'm waiting for the time the "alpha" is over (it's stable and functional enough for my purposes..) so I can hand you over some money. :)
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.
Best, Meryn
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”.
Thank you for addressing my comments so extensively. I do want to apologize about my "snark" re the crossword puzzle, because this isn't anything close to reality. You're clearly open to user feedback.
All in all, I can understand your decision to disable Github Issues. Now I found the nabble front-end for this list, the mailing list form bothers me less too. I do wonder if people would be bothered by different conversation styles naturally arising from using different media.
"dozens of issues were opened from people who couldn’t read^H^H^H^H build TextMate… :) "
Perhaps making it just a little bit more difficult to give feedback is attractive then. Also, by not using GitHub issues, you're more in control over what channels you point people to. I.e. "For questions about A, use list A, for questions about B, use list B", for questions about C, use IRC". For me at least, the existence of the "Issues" tab removed the need to look for general instructions re feedback at all, because the route was obvious (i.e. click on the Issues tab). I guess It would help if people who'd be forced to read a splash-screen with instructions before being able to post.
I also agree that a plain database of issues is not the best way to educate users who want to give meaningful feedback. Effectively educating users for this purpose is probably a science in its own right. Hand-crafted content would generally work better I think, with the caveat that seriously outdated content it may start to harm. Although in this case, there would be good incentive for a project owner or other stakeholders to update the content so quality of feedback gets restored again.
I sincerely hope Github acts on your request for disabling submitting new issues, while keeping the archive accessible. Just today I stumbled upon a link to a TextMate GitHub issue in Google. It would be just sad if good comments there are deleted. In general, I find I'm learning so much from just random stumbles upon old discussions about various projects. Often on blogs, sometimes on bug trackers.
-- View this message in context: http://textmate.1073791.n5.nabble.com/github-issues-forum-tp26406p26438.html Sent from the textmate users mailing list archive at Nabble.com.