Yes, on HN reposts do not count as a dupe if the story hasn't had significant attention yet. In fact we invited the submitter to repost this one, which we sometimes do when a story seems like it would interest the community and deserves a second chance at attention.
HN doesn't have an on-site messaging mechanism. There used to be one, but it was used so rarely that we deleted the code. I sometimes think about restoring it, because not every account has an email address and some that do don't respond.
Hmm, so I guess there's some sort of manual curation going on for what's interesting and can be posted again? Is there a criteria for such curation? Karma? Past posts? Past comments? Social influence? Who the OP really is? Will the OP also be advised on a better timing to post the link again so that it would have a better chance of getting attention?
Here's the email I got inviting me to re-post the story. That's all I know : )
Hi there,
https://news.ycombinator.com/item?id=10690114 looks good, but didn't
get much attention. Would you care to repost it? You can do so
here: https://news.ycombinator.com/repost?id=10690114.
Please use the same account (krallin), title, and URL. When these match,
the software will give the repost an upvote from the mods, plus we'll
help make sure it doesn't get flagged.
This is part of an experiment in giving good HN submissions multiple
chances at the front page. If you have any questions, let us know. And
if you don't want these emails, sorry! Tell us and we won't do it again.
Thanks for posting good things to Hacker News,
Daniel
Software does a first pass through the stories and reviewers look at the rest. "Reviewers" means moderators and a small number of users. Our plan is to open story reviewing to the entire community, but there are some design challenges to solve first. I like the idea of making it a new way of earning karma, because it's both work and community service.
Re criteria for filtering stories: karma isn't a factor; past submissions are. A downside of the latter might be a rich-get-richer effect, but we mitigate that by looking for any earlier submission of the same story and picking that one instead. We don't advise about timing; in fact we randomize the process to reduce timing effects.
We mostly don't send repost invites anymore, but rather re-up the original post by rolling back its internal clock and giving it a random placement near the bottom of the front page. This guarantees a few minutes of community exposure, and regular upvoting decides the rest. On the front page, we display the re-upped timestamp, not the original timestamp, because otherwise it's confusing—only the re-upped time makes sense relative to the other stories on the page. But the original timestamp is available on most of the other pages that list the story, like /submitted and /from, and the discrepancy is temporary, since eventually the two timestamps converge.
The reason we switched from reposts to re-ups is that HN users are averse to duplication. I trust that the programmers among them hold their code to the same standard. We do still send emails when it seems important for the submitter to know that their story may still make the front page—mostly for Show HNs, like this one.
All of this is the latest in a series of experiments we've been running, whose goal is to fix the problem of good stories falling through the cracks on HN. Earlier posts about this, for anyone who wants more background:
Yes, you can. But that's not as granular as watching for changes on one or more specific files. The atom feed provided by GitHub provides the commit message, author, thumbnail, and date only.
Using "github" in your domain name limits you to github (many other repository services exist) and makes you a potential target for trademark claims.
Also, I think you are onto something. Git remotes are mostly passive, where you have to pull to see whether there are any updates. There is no subscription model to get notified of changes. You have to actively pull to find out what is new.
You should try to make this as a standalone service, which works with Git remotes, not just a Git hosting party. Then locally, you can pull the repo/commits and check what has updated (diff) and inform subscribers accordingly.
These are great points; thanks for your feedback! :)
I'm trying to validate whether there's any interest in something this, so I definitely cut a lot of corners (e.g. the app doesn't maintain a copy of the repository — it just uses the GitHub API). Also using GitHub in the name might not have been the best idea.. though! ;)
I agree with you regarding the usefulness of watching arbitrary repositories. There's already git-notifier [0] that does pretty much this, but you have to set it up for yourself and it has to be configured using a text file.
It's slightly more convenient for me to get a notification than to periodically pull repositories and check them for changes, but I understand that might not be the case for everyone!
I write plugins for RpgMaker and a lot of the people who use them are regular users who don't know how to use GitHub. Some of them had asked for a way they could get notifications every time I update a plugin, this will be very useful for that.
Can I request a feature? Would be nice to have a way I could pass the repository and file names on the query string, so I can put a link where people only need to inform their email and submit to start receiving notifications for that.
Indeed, not yet! Private repo support would require authenticating with GitHub, which makes the project a bit more complex.
I definitely plan to add this if there's enough interest. There should be a link to a mailing list to be notified when that rolls around (http://eepurl.com/bILhR1).
Funny thing i almost did exactly this until i realized you can use rss which can also watch directories easily enough for example https://github.com/torvalds/linux/commits/master/Documentati... . Also unfortunately i found that using the api is probably not going to scale if a lot of people want to use it and local clones are pretty expensive.
The GitHub API allows up to 5,000 requests per hour. I currently poll once an hour, so there's a bit of headway. If that becomes a problem, I think I can always space out checks for less-active repositories (there's also the option of allowing users to authenticate with GitHub and use their own quota so they don't have to share it with anyone else).
This was posted a day ago. Source: https://news.ycombinator.com/item?id=10690114
Yes, on HN reposts do not count as a dupe if the story hasn't had significant attention yet. In fact we invited the submitter to repost this one, which we sometimes do when a story seems like it would interest the community and deserves a second chance at attention.
Out of curiosity, when you ask someone to resubmit do you email them or is there some on-site messaging mechanism?
Email (I've gotten one)
HN doesn't have an on-site messaging mechanism. There used to be one, but it was used so rarely that we deleted the code. I sometimes think about restoring it, because not every account has an email address and some that do don't respond.
Hmm, so I guess there's some sort of manual curation going on for what's interesting and can be posted again? Is there a criteria for such curation? Karma? Past posts? Past comments? Social influence? Who the OP really is? Will the OP also be advised on a better timing to post the link again so that it would have a better chance of getting attention?
It seems the reposting is only about how interesting the submission is.
I think a resubmitted post gets a small karma bump (1 or 2 points) to help it. But after that it's up to the community to vote.
Here's the email I got inviting me to re-post the story. That's all I know : )
Software does a first pass through the stories and reviewers look at the rest. "Reviewers" means moderators and a small number of users. Our plan is to open story reviewing to the entire community, but there are some design challenges to solve first. I like the idea of making it a new way of earning karma, because it's both work and community service.
Re criteria for filtering stories: karma isn't a factor; past submissions are. A downside of the latter might be a rich-get-richer effect, but we mitigate that by looking for any earlier submission of the same story and picking that one instead. We don't advise about timing; in fact we randomize the process to reduce timing effects.
We mostly don't send repost invites anymore, but rather re-up the original post by rolling back its internal clock and giving it a random placement near the bottom of the front page. This guarantees a few minutes of community exposure, and regular upvoting decides the rest. On the front page, we display the re-upped timestamp, not the original timestamp, because otherwise it's confusing—only the re-upped time makes sense relative to the other stories on the page. But the original timestamp is available on most of the other pages that list the story, like /submitted and /from, and the discrepancy is temporary, since eventually the two timestamps converge.
The reason we switched from reposts to re-ups is that HN users are averse to duplication. I trust that the programmers among them hold their code to the same standard. We do still send emails when it seems important for the submitter to know that their story may still make the front page—mostly for Show HNs, like this one.
All of this is the latest in a series of experiments we've been running, whose goal is to fix the problem of good stories falling through the cracks on HN. Earlier posts about this, for anyone who wants more background:
https://news.ycombinator.com/item?id=10742610 (more recent, but might as well keep this list up to date)
https://news.ycombinator.com/item?id=10537417
https://news.ycombinator.com/item?id=10395389
https://news.ycombinator.com/item?id=9866140
https://news.ycombinator.com/item?id=8790134
https://news.ycombinator.com/item?id=9828818
You can also just subscribe to commits via RSS.
On GH itself or via OP link?
Oh GH. e.g. https://github.com/torvalds/linux/commits/master.atom
Thanks :)
Yes, you can. But that's not as granular as watching for changes on one or more specific files. The atom feed provided by GitHub provides the commit message, author, thumbnail, and date only.
Thanks! I've been looking for something like this for quite a while now, but without any success.
Using "github" in your domain name limits you to github (many other repository services exist) and makes you a potential target for trademark claims.
Also, I think you are onto something. Git remotes are mostly passive, where you have to pull to see whether there are any updates. There is no subscription model to get notified of changes. You have to actively pull to find out what is new.
You should try to make this as a standalone service, which works with Git remotes, not just a Git hosting party. Then locally, you can pull the repo/commits and check what has updated (diff) and inform subscribers accordingly.
These are great points; thanks for your feedback! :)
I'm trying to validate whether there's any interest in something this, so I definitely cut a lot of corners (e.g. the app doesn't maintain a copy of the repository — it just uses the GitHub API). Also using GitHub in the name might not have been the best idea.. though! ;)
I agree with you regarding the usefulness of watching arbitrary repositories. There's already git-notifier [0] that does pretty much this, but you have to set it up for yourself and it has to be configured using a text file.
[0]: http://www.icir.org/robin/git-notifier/
See my comment above re:
https://github.com/ianmiell/alert-on-change/blob/master/READ...
I wrote a more generic solution to this kind of problem recently, which I run as a service:
https://github.com/ianmiell/alert-on-change/blob/master/READ...
It's probably more suited for the programming types.
For example, you can do a 'raw' GitHub request to determine when a particular file has changed.
What about you know… using Git?
I made this mainly to scratch my own itch :).
It's slightly more convenient for me to get a notification than to periodically pull repositories and check them for changes, but I understand that might not be the case for everyone!
Very useful!
I write plugins for RpgMaker and a lot of the people who use them are regular users who don't know how to use GitHub. Some of them had asked for a way they could get notifications every time I update a plugin, this will be very useful for that.
Can I request a feature? Would be nice to have a way I could pass the repository and file names on the query string, so I can put a link where people only need to inform their email and submit to start receiving notifications for that.
Ha, this is a great idea! I've added this now :). Just reload.
Thanks a lot!
Does not wok on private repo.
Indeed, not yet! Private repo support would require authenticating with GitHub, which makes the project a bit more complex.
I definitely plan to add this if there's enough interest. There should be a link to a mailing list to be notified when that rolls around (http://eepurl.com/bILhR1).
Thanks for checking it out anyway! : )
Funny thing i almost did exactly this until i realized you can use rss which can also watch directories easily enough for example https://github.com/torvalds/linux/commits/master/Documentati... . Also unfortunately i found that using the api is probably not going to scale if a lot of people want to use it and local clones are pretty expensive.
Ha, interesting trick! : )
The GitHub API allows up to 5,000 requests per hour. I currently poll once an hour, so there's a bit of headway. If that becomes a problem, I think I can always space out checks for less-active repositories (there's also the option of allowing users to authenticate with GitHub and use their own quota so they don't have to share it with anyone else).
Cheers