Ask HN: What was the last time a requested feature was implemented ?
With some regularity people are being sent to the 'feature request' page to post suggestions about things to add to HN.
It is one of the longest threads since HN was launched, and there are many good suggestions in there, some of them quite old that have not made the cut without any reason given.
This seems to result in two things, an increase in the number of feature requests in regular posts, and a feeling that the feature request page simply exists as a way to vent this stuff so that it can then be safely ignored.
To verify, is the feature request page still actively monitored ?
Has there been a documented case in recent history (say the last couple of months) where a request from the feature request page was picked up and actually implemented ?
And if those cases do not exist would it be an idea to reboot the feature request thread ?
And to tell people if their feature request is not going to be honored why that is ?
I'm appealing especially to those people that always feel the need to point people to the feature request page (assuming you don't do it for the easy karma boost) to prove that it is actually 'live', after all you are sending people there you must have some proof that it works.
Comments
Hackers want features -> they are ignored -> they learn arc and submit patches themselves -> ... -> arc becomes the dominant programming language. Definitely an arc conspiracy.
Seriously, it's just a small non-commercial niche news site with basic functionality. People running it have more interesting stuff to spend their time on. I wonder if reasonable proposed patches are accepted.
It's a little ironic that HN is not particularly responsive to feature requests from the community... in contrast to how YC recommends startups be run.
There's that idea that appropriate profit motives are an important way to make things happen. Therefore, one way to make HN more responsive to requests would be to make it into a startup. Not that that should happen.
We advocate that founders pay a lot of attention to users, not that they literally do what users ask.
What keeps users here is not features but the quality of the links and the comments. So that is what I spend the most time on. E.g. we have really good software for catching spam, and also semi-spam promoted by voting rings. There are also a number of subtle tweaks to prevent flame wars.
The last code I released (the day before yesterday) was to enable the system to ignore the flags of people who flagged too indiscriminately. Which in turn depended on code I wrote to study how big a problem bad flagging is. Like good defense, this kind of work is generally invisible. Even news.ycombinator.com/classic is something I wrote for myself to try to gauge whether quality was declining.
I totally agree; it's just the incongruity.
The epic feature request thread seems vestigial: you often responded there 800-900 days ago but haven't for 428 days, I'd guess because HN has outgrown it.
Yeah, is kind of cheesy to use an ordinary comment thread. But a new, purpose-built feature request system is one of the many potential new features that, while a good idea in principle, would take significant time and yet have little effect on the quality of the site.
What about simply giving meta discussions (including features) a place of their own ?
That way if there is an interesting one (and it does happen, even if rarely) it has a spot and doesn't get killed because it takes up valuable space on the 'new' page.
I've been thinking about that for a while, if only because if there was an official place for meta-discussion, I could make people stop cluttering the real threads with it. On the other hand, maybe this feature would make the site more attractive to the kind of people who like meta-discussion, when I want it to be less attractive to them.
Well, since some of it is useful, give that it's own spot and leave the flag and kill options in place to control the meta discussion should it get out of hand.
Just like in wikipedia there is the 'talk' page, it's out of band but it is not out of control.
That seems to be a good middle ground.
How big of a problem is bad flagging?
It's highly localized. There turn out to be a small number of people who generate large numbers of bad flags. (Bad = flagging something that does not end up getting killed.) Which meant the solution was to be able to turn flagging off for individual users.
It might improve flagging accuracy if you included it on users' profile pages. Give people a metric and they'll tweak it. The result might be dramatic.
That's a really good one actually.
Just being able to measure how many - and which - flags were 'good' flags and which were not would already help.
I flag 10-15 stories per day and very occasionally a comment (maybe three times in all so far or so), but I'd have to track all those stories to see if they end up getting killed or not. Most of them are easy calls, the outright spam. But there are border cases where it would be good to know exactly what the guidelines are.
Especially since 'bad flagging' seems to be a problem, if there is a lack of clarity there then by resolving that 'bad flagging' as an issue might go away.
It's a little ironic that HN is not particularly responsive to feature requests from the community... in contrast to how YC recommends startups be run.
No, it's not ironic. HN is not a startup. Isn't that obvious?
Make something people want is advice about how to get rich, not some moral imperative.
Edit: this whole issue isn't that puzzling either. What part of "the guy is a minimalist and has very little spare time" don't you people understand? :)
Edit 2: ooh, downvoted! Well I do concede that countering spurious claims to irony is a bit of a tic on my part, probably ever sense I saw the brilliant http://www.youtube.com/watch?v=nT1TVSTkAXg
HN would make a terrific startup challenge. It's already got a potential revenue model that would work: Charge for admission. It works for similar sites, and I think it would help a lot for this one.
Because, as I said last time, what Hacker News needs most of all is a bigger sense of entitlement among its users.
Yeah, because Hacker News readers really feel entitled. Where is this arrogance you claim to see, and how is it different from any other web site online?
It's not different in that respect from other websites. People on other sites appear to feel the same asinine sense of entitlement: that the site should be run transparently, that their feature requests should be considered carefully and implemented if possible, etc etc.
I'm not saying you're like that personally, but I think the trend is pretty hard to miss.
That's why I said "different from any other site online." I don't think we're any more entitled princesses than Redditors or Diggers, though.
I don't feel entitled to good service on HN (and thank God, because we sure don't get it), but I think it would be nice to have. If Hacker News could somehow turn itself into a competitive start-up, I'd like that, because I do think this site suffers from a lot of things.
People say exactly --- I mean EXACTLY --- the same thing about Craigslist every day, and Craig Newmark keeps saying "anything I add to the site could take away from it in some other way", and there you have it; Times New Roman, browser-default <a> listings in non-semantic, hard-to-scrape lists, etc.
I don't use Craigslist, but HN is not the same sort of site at all. There are features that would add positively to HN that wouldn't detract anything from it.
One of the main points of the feature request page is to separate feature requests from submmissions. You want to do this because most are either duplicates or bad ideas, and yet (like all meta discussion, including this post) tend to get a lot of upvotes. The feature request page serves that purpose even if no one reads it.
I do check it occasionally. I know search is the main thing people want. But explicit "features" are not my top priority now. The top priority is to maintain (or if possible improve) the quality of links and comments. More details here:
http://news.ycombinator.com/item?id=830485
Ok, are you open to collaboration ?
That way other people could do the stuff that is not priority to you.
I'm more than willing to really dig in to arc if I know the effort is not in vain. (other than learning arc, which is interesting in and of itself but that would be 'academic' interest, nothing productive).
I don't think it would necessarily be a net win. The kind of code that really matters (e.g. techniques for suppressing fluff posts, trolls, and flamewars) I deliberately don't talk about or release publicly. And if some random person wrote, say, a feature-request feature for HN, I'd probably have to spend more time cleaning it up than it would have taken to write from scratch. Plus I'd have to turn into a project manager. Life is too short.
I am happy to incorporate specific fixes, though. I greatly appreciated dfranke's warning about the security hole he found. And if someone wanted to try profiling HN in order to make it faster, I'd be interested to hear what they discovered.
> Life is too short.
Possibly. But if you really want this to go I'm sure if there is one spot where you'd have no shortage of people willing to help out it would be HN.
Also, where would Linux be if Linus had decided that he'd have to make each and every change himself ?
I understand that you wish to keep the 'secret sauce' secret, that makes good sense. No need to make it easier on the spammers to figure out how to bypass the various features that keep the junk in check. Otherwise HN would turn into a useless linkdump in a heart beat.
But stuff like article tagging would be tremendously useful, especially in combination with a filtering function.
The feature request thread has lots of good ideas, if you want I can spend some time to make a digest.
I realize you have lots on your plate but that is precisely the reason why 'life is too short', if the end result of that is that HN feels stagnant (and in some ways it does, even though I can see there is some subtle tuning going on behind the scenes and by the number of restarts) then that seems like a lost opportunity to me.
HN - and arc - are clearly your babies and you get to make the calls, but I'm sure there are enough people of caliber here to help out, and if you tell them 'not good enough' when they present a patch I'm sure they'll try harder, that way you could simply do the quality control end of that.
It'd still be work, but a lot less work than building all those features yourself.
Another thing that came to mind the other day is maybe you do not want to risk eclipsing digg by building a HN that is too good, is that a factor here or rather not ?
I'm sure I could find better hackers here than just about anywhere else, but I don't want to be Linus.
I think the chances of you becoming Linus are remote :)
But still, HN feels like it is purposefully limited. That's fine if that is the stated policy, but then you might as well shut down the 'feature request' thread and state that the policy is to keep HN in the form that it is today besides tuning things to accomodate growth.
On another note, I realize that HN being written the way it is must be quite hard to split across multiple machines, should the need come for that do you have plans in that direction ?
And while we're talking about the feature request thread:
I put a fairly simple one in that would make flagging nonsense a lot easier for the people keeping an eye on the new page as well as less load on the server because of the extra pageview to get the 'discuss' page for spam links. Simply add a 'flag' option to any articles appearing on the new page that are also on 'noobstories', or alternatively add 'flag' links to the 'noobstories' page.
The main reason for this is that HN can be very slow and if you do not have to leave the page it will save a lot of time while flagging.
> And if some random person wrote, say, a feature-request feature for HN, I'd probably have to spend more time cleaning it up
In open source projects that's certainly true the first time, but if that process of correction is transparent to the person sending in the patch, then they eventually learn the ropes well enough that you don't have to correct their future patches, and in fact, they can correct the patches of others.
There's a pretty big gap between wrangling a small group of people sending patches and being a full-time project manager. For the couple of widespread-ish OSS projects that I've started they took maybe an hour a week until I handed them off to new maintainers -- another nice possibility that arises from having additional contributors.
(Note: I don't mean to imply that things necessarily should go this way, just that the process can be somewhat more rewarding than it would seem at first.)
I'm happy to not get down-modded below 10 points anymore if I say something critical about the US president.
So far as I can tell, HN wasn't built to be a home for a community as much as it was built as an experiment in Arc.
after all you are sending people there you must have some proof that it works.
that doesn't follow. The feature request thread os the communally accepted place for feature requests, whether it works or not is a separate thing.
Also, your implication that it needs restarting if it doesn't work doesn't make sense - it's still an accurate record.
news.arc is open-source, right? So if you want a feature, just add it.
http://news.ycombinator.com/item?id=830156
It could be kept bare to keep away the digg, TC crowd etc.
> It could be kept bare to keep away the digg, TC crowd etc.
Possible, but then let's just have that as a statement out in the open, then we can be done with it.
Instead of pointing people to the 'feature request' thread we could then give that as an answer. Right now it almost feels like giving someone a pacifier or a placebo.
In another thread someone literally used the words 'so he stops bothering us'.
There can be a conflict of interest between YC (ie PG) and HN users, particularly long-term ones. That's how I've come to terms with it. This forum is first and foremost a hook for entrepreneurs into YC and a way for PG to assess potential investees by their participation and statements. Everyone else is going along on their ride, at the core.
That doesn't do much good if news.yc.com is never updated.
What is news.arc?
The arc source distribution. HN is built on a dialect of scheme that Paul Graham came up with.
Arc is a pretty ambitious project, a language for 'the next hundred years' (see http://en.wikipedia.org/wiki/Arc_(programming_language) ).
Not sure about how many people actually use it though, HN is the only application that I'm aware of that uses it.
Not sure about how many people actually use it though, HN is the only application that I'm aware of that uses it.
NewMogul
http://www.newmogul.com/
also uses the same software to run its site.
Sorry for not being more clear, I meant anything else written in arc. There are plenty of sites that use the arc code to serve up forums with a thin layer of css changes to make it look a little different.
But this was about the language, not about the news.arc implementation.
Presumably you could write anything that you want in arc, if the language stands as an individual piece of code then 'HN' is sort of an example of what arc can do. So then the question is: has anybody written any other application using arc. And I'm not aware that that has happened.
edit:
So, after some digging I found this:
http://docs.google.com/View?id=dgjgbnzn_123dcb5g9hc
http://arclanguage.org/forum
My Arc REPL online uses Arc on the backend, see http://dabuttonfactory.com:8080 (the code is linked there), but it's just a tiny project.
But yes, there are not so many projects using it to my Arc-forum-user knowledge too.
Where can I download the software? I like it a lot. Maybe YCombinator should sell it ;-)
http://ycombinator.com/arc/arc3.1.tar, it includes news.arc, the code running HN/NewMogul/etc and a "how-to-run-news" text file.
You need MzScheme 4 to run Arc.
See also http://arclanguage.org/install (installation instructions, but a bit out-of-date, it's for Arc 3.0) and http://arclanguage.org/item?id=10254 (Arc 3.1 announcement).