Bad maintainers will rejoice at the possibility of replicating a fiasco like this: https://github.com/ansible/ansible-modules-core/pull/2023 with zero effort. Saved replies are a silver bullet only for those who already took the time to compose meaningful (engaging?) replies. For all the others, a quick way to shoot themselves in their feet.
Neat feature, should save a bunch of time. I wonder if they'll consider support for variables like {{ submitter }} or {{ owner }} that would fill in a mention to the user who filed the issue or the repo's owner.
That's the output, yes, assuming proper input sanitization, which I would not expect to be a problem given that it's github and they deal with a ton of the most dangerous kind of dynamic content (any kind of code) already.
With interpreted text languages, and indeed with machine code, there are no types to associate with a value and a value may very well be executable code. This invariably means that the only approach is to "sanitize" your output for a given context if the type associated with it means it should only be interpreted as data.
Interpretation does not prevent typing, and machine code is an execution format. The right thing in any language is: express the operations that you are going to perform in a form that clearly distinguishes between values that represent different varieties of thing. (Types make this easier, otherwise you have to implement more of it yourself).
You talk about code and data as though they were the only things, but they're not; getting one variety of data when you were expecting another variety can just as easily lead to security bugs as getting code instead of data or vice versa. Sanitization very rarely works - and in the rare cases where it does, it still indicates a deficiency in the underlying model.
This is awesome. I have a repo with only about 1k stars, so nowhere near the adoption of something like npm, etc.
Even on my repo, I still regularly receive issues that say "it doesn't work. Why?" With no reproducable info. These will cut the time on asking for that info and give more time back to other users or the project itself.
I would be okay with these responses if it was remotely apparent whether Issues acts as a discussion forum or not. It varies for every project unfortunately. For smaller projects, the risk of asking on SO is the maintainer, and anyone else familiar with the project, will never see it as they wouldn't be actively monitoring it.
Hopefully Github's current blast of Issues updates will make it easier for project owners to explain their respective policy on this.
Maybe integrating issues search with SO would be a good idea?
Personally, I create an issue if I strongly believe that it is a bug in the project or I want to suggest some improvements (e.g. found some strongly outdated docstrings) and head to SO if I believe that it's me doing something wrong.
But I can easily see how the distinction is very subjective and blurry.
This is where CONTRIBUTING.md comes in. If a project doesn't want Issues to be used for support, then it should mention it there. Whether people actually read it is another story :(
It's not at all logical to look into the guidelines for contributing to a project of what you seek is support, not to contribute a feature request or a patch. I'd never look there.
"GitHub issues are for bugs / installation problems / feature requests.
For general support from the community, see [StackOverflow](link)"
However, we still get plenty of issues filed that are more appropriate for StackOverflow, so not sure there's anything technical you can do without integrating more closely with StackOverflow :)
Love those cold, corporate, canned responses?
Does Level 1 tech. support make your day by asking if you've rebooted?
These features and more, can all be yours!
Well, I try to at least drop a hint as to the right search terms when I do this, and an encouraging word. But IMO your issue is not my issue. I am not going to track your issue.
But if I have time I might try to point you in the right direction, in the right forum.
It has nothing to do with the popularity of the repository, really, but more with the quality of the issues.
>>> I would hate an automatic reply for filling an issue for a small library or such.
If the issue is lets say not reproducible because of lack of information provided, does it really matter if the response was typed out by hand? The response would be the same, give or take a couple of words.
The maintainer could see that, due to the nature of the issue, maybe the user OS would matter. Or maybe there's another version on the horizon that changes completely the functionally in topic. A hand crafted reply asking some curated questions/suggestions is not the same from an automatic "not enough information".
It's not about typing, it's about making a conversation.
For example, this past weekend I triaged over 600 issues on a project that sees a lot of maintainer churn (ui-select for Angular) - the low quality issues is a lot of the problem, and maintainers waste a lot of mental energy when they have to focus on a lot of issues where the reporter didn't do the basic level of due diligence.
If this feature was released beforehand, it probably would have saved me a couple of hours :( .
Keep in mind that these kinds of features were likely in development prior to the letter, although it's likely the letter accelerated the time table a bit.
If it got GitHub to roll things out faster, then good job to the letter writers and good job to GitHub!
FWIW, I sent an email to Jono Bacon soon after that letter hit HN, and he was very polite and actually listened to my ramblings. I couldn't be more impressed.
The previous stuff they've launched was clearly in development earlier, but canned responses is a fairly simple, high-visibility feature that easily could have been built in response to the open letter.
Yeah. Before that I was really wondering what the heck they were doing with that $100M they raised. I mean, I get that GitHub Enterprise is a good moneymaker, but still.
The implication here, isn't so much that what was created was new, it's "Would this feature had been created had somebody else not shown GitHub a better way?"
is fairly new, it's easy to believe this feature was in GitHub's pipeline for a while.
If this wasn't the case, it can sting from a brand perception point of view. GitHub is suppose to be synonymous with innovation, and if you start getting called out for copying, no matter how trivial, it will devalue your brand over time.
The question now is, how closely is GitHub looking at something like this:
> GitHub is suppose to be synonymous with innovation
I'm not sure I agree. GitHub's core service - git - is one that they did not create. I'd argue that if anything, GitHub is synonymous with accessibility and reliability.
I sincerely doubt much of their userbase will look at things so emotionally as to damage the company. Most of github seems to quietly continue ticking over no matter what the drama.
I don't disagree. My sister has been using GitHub for years and she's never heard of the dear GitHub letter. The reputation part will have greater impact on Enterprise though.
The reason why Enterprise sales cycles are so long, is because they want to make sure if they go with vendor X, they aren't shooting themselves in the foot in the long run. The trial period for the most part is risk assessment, because once you start building solutions around something, decoupling is extremely painful and risky.
Companies are desperately trying to get off ClearCase (million dollar licenses), but they can't because their existing build systems, verification, etc. are so integrated with it, that decoupling introduces too much down time risk.
If we found a situation where GitHub was constantly copying from Bitbucket or GitLab or who ever becomes the next thing, it's definitely going to introduce doubts about whether GitHub is the right choice for the long run.
Drama will not affect that web designer that is paying $7 a month for a hosting plan, but it will cause doubts for those looking to spend 10s of thousands a year.
> GitHub is suppose to be synonymous with innovation...
What was their innovation previously, though? I think they built a pretty great site around git, but I struggle to see where this massive innovation is.
Really? Why not just a notepad?
It is on per user basis. So you can't even have different reply per repo. Or have some variable like user name or repo name.
I mean. This really is the same as having a text file opened and copy paste something.
> This really is the same as having a text file opened and copy paste something.
Convenience is a feature. Two clicks is far better than "have another application open, switch over to it, find the right part in the notepad, select that bit of text, copy and paste it over."
I do a _lot_ of issue triage. The time savings is not negligible for me.
(I do agree that per-repo would be nice, but I'm happy to have this in the meantime)
That's certainly reasonable. There are likely similar utilities for other platforms[1]. For people with Macs and iOS devices, TextExpander snippets can be synced across devices so that they're available everywhere.
Saved Replies on GitHub is still a great feature, and I don't mean to imply otherwise. I'm just noting a more general solution to this problem.
Truth, and I do think that's useful to point out :) I use Linux and iOS, so I tend to be in a weird place for anything sync-ing, most people seem to assume Linux/Android or Mac OS/iOS.
GitHub hasn't implemented this feature (or any of the rich text editing ones) on the mobile version of their site. You'll have to force the desktop version and somewhat tediously navigate the menus to use this, though I suppose it's still an improvement over typing long messages.
FYI, there are lots of tools that bring this functionality to any application or website, such as https://www.trankynam.com/atext/ or http://www.yesware.com/ for Gmail. Sharing templates isn't the bottleneck, just inserting them. No need to wait for Github to build it!
> Maybe it's just the color palette that makes it look better
The color palette size definitely plays a part, but the vast majority of degradation is the result of scaling down. This is what a gif looks like which was captured at HD (1280x720) and scaled down to 670x377
Why am I getting the Saved Replies dropdown appearing every single time I add a comment? It's extremely irritating. I understand doing it once to tell me that the feature exists, but doing it repeatedly after I keep closing the dropdown is really aggravating.
What a coincidence. The discussion board for the github Atom editor just started offering canned replies today also. It is not their software, it is the new discuss software by coding-horror that is getting popular.
I feel like, much like the PHP bug reporting system's canned responses, this might get irritating quickly. After all, it's too easy to simply copy/paste your "Not A Bug" message and move on, without explaining it.
The done thing on bugzilla.mozilla.org seems to be changing your display name to include "vacation" or similar, but I haven't seen much of that on GitHub.
