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