Saved Replies | Hacker News Reader

Saved Replies

github.com

232 pointsSir_Cmpwn89 comments

Open articleView on HN

Awesome. Now I can add +1 comments with just a click.

You're able to add +1 through their recent GitHub Reactions update now:

https://github.com/blog/2119-add-reactions-to-pull-requests-...

That's the joke :)

Ah, been a long day and completed missed it. Thanks for that!

http://thatsthejoke.net/

Except it doesn't do notifications like a comment does...

Good.

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.

That's gotta be some automated thing gone bad though. Surely a human would not be conducting a conversation like that.

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.

My new username: andrewstuart'); DROP TABLE repositories;--

:-P

(https://xkcd.com/327/)

Hi andrewstuart'); DROP TABLE repositories;--,

Thanks for sending this in! Based on my reading, this is working as intended and is not a bug in the code. Let me know if I'm misreading something.

Thanks again!

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.

It was a bad joke, I guess.

"Sanitization" is the wrong approach. I would hope Github handles things right, by keeping track of what every value represents.

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.

Don't forget https://github.com/blog/2111-issue-and-pull-request-template... - even for private repos it really has changed the way we do bug reporting (for the better).

I use this on Cachet [1] and find that most of the time people just remove the pre-filled content regardless.

[1] https://github.com/CachetHQ/Cachet

Did you notice how open letter worked on github and competition from gitlab? In a good way of course. Finally github started evolving again.

"Please ask support questions on Stack Overflow or the users group. I am closing this."

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.

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.

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 :(

Yeah this is actually my canned response on one of my own projects, and I'm tired of copying and pasting it. Nobody reads CONTRIBUTING.md

In our issues template, we start it with:

"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 :)

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.

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.

"Have you tried turning it off and on again?"

https://www.youtube.com/watch?v=nn2FB1P_Mn8

It's a nice feature for busy repos such as npm (https://github.com/npm/npm/issues) but I hope people with smaller repos stay away from it.

I would hate an automatic reply for filling an issue for a small library or such.

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.

But this is a massive waste of time.

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 :( .

600 issues is a lot, I consider that a popular repository.

I'm not against the feature, I think it's (for big repos) a necessary evil.

Not saying that they've copied or anything, but this has been around for a while: https://github.com/notwaldorf/github-canned-responses

Open Source, eh? canned-responses is MIT licensed, so even if Github just took the time to integrate that code wholesale: hurray, progress for all!

They really have been on a roll with the new features since the Dear Github letter happened

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.

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.

And probably informed internal prioritization a bit, perhaps bubbling to the top a few simpler yet more-desirable features.

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.

I'll be keeping my GitHub subscription :-)

Eh... I don't know how confident I am in that.

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.

Looks like they are mostly picking the low hanging fruits

They basically took the idea from this Chrome extension:

https://chrome.google.com/webstore/detail/github-canned-resp...

The notion of shortcuts for inserting prepared text isn't exactly new.

I was working in a data entry job in 1983 and the system would expand predefined text sequences into the matching full text as needed.

Doing this through a pretty dropdown is the same idea.

I'll bet the idea wasn't new in 1983 either.

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?"

Since the commit history for

https://github.com/notwaldorf/github-canned-responses/commit...

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:

https://github.com/stefanbuck/awesome-browser-extensions-for...

and other similar Chrome extensions.

Right now, they are in a damned if they do and damned if they don't, as the result of the dear GitHub letter.

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.

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

Next Chrome Extension to take ideas from: https://chrome.google.com/webstore/detail/github-module-brow...

Now _this_ is the kind of feature that really, really, really helps me. This will make my life immediately, measurably better.

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.

Yes but you don't need to have a notepad open. Not having to have a notepad open is much easier then needing to have a notepad open.

Though the lack of variables is another issue...

  > 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)

I always write bookmarklets for stuff like this. You could even make it auto-fill reporters name or similar (as I see you wished in another comment)

Yeah, I have used a Chrome extension in the past. Nice to not have to do so, though, as it now works everywhere. I don't even use Chrome anymore.

On the Mac, a utility like TextExpander is great because it lets you expand abbreviations out and fill in variables along the way.

Yeah, but I don't have a Mac, and even so, I look at GitHub from a lot of places, including my phone.

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.

[1]: http://alternativeto.net/software/textexpander/

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.

Ah, that doesn't surprise me. I can mostly get away without using the desktop version these days, mostly thanks to https://github.com/blog/1642-merge-pull-requests-from-your-p... (note that image mockup...)

Also,

- On Windows there's https://autohotkey.com/

- On Linux there's (unmaintained but still working) https://en.wikipedia.org/wiki/AutoKey , EDIT seems this fork is maintained: https://github.com/guoci/autokey-py3 , and it's on AUR as autokey-py3

(that doesn't remove anything to the utility of the GitHub feature, just mentioning these apps in case anyone is interested)

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!

Yeah, as mentioned down thread, those are nice, but are too often tied to a particular computer.

I generally prefer the web for almost all things.

Very good feature. A nice expansion would be "Saved Workflows" to send a saved reply, add label/milestone, assign to user, etc.

That's a really nice animated GIF, with very little color and font degradation. I'd love to know how it was made. I have [a couple I made recently here](http://robenkleene.github.io/2016/03/17/live-search/) using [gifify](https://github.com/vvo/gifify). Maybe it's just the color palette that makes it look better?

Seriously is there a tool for making these gifs? Converting from video always gets degradation.

I know a lot of GitHubbers use http://www.cockos.com/licecap/ to make their GIFs

licecap is awesome, but this gif looks like it was programmatically made. Notice the accelerated yet perfectly aligned cursor movement...

https://github.com/Jam3/ffmpeg-gif

> 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

http://gitsense.github.io/images/realtime-blog/master.gif

The gif in GitHub's post hasn't been scaled down at all, which makes all the difference in the world.

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.

This should probably be available at the repository level too so if you've got collaborators who need to use the same responses they can be shared.

Check out their documentation for less details on the feature: https://help.github.com/articles/working-with-saved-replies/

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.

Nonetheless, probably a helpful tool.

It's nice that only you can see your reply titles.

Asshole

[... a very polite request for the user to stop trolling ...]

Now they just need a "on vacation" button.

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.

I wish Trello would add this.

Clean feature I must say.

Would love to save replies on a per repo basis, so that we can store our jenkins commands in saved replies

Reply on news.ycombinator.com