The step of just adding yourself to the userlist seems ill-conceived. Automatic merges are just going to overwrite the last person added unless manually merged. Can I propose this just use github for authentication, and only allow those on the contributors list (http://developer.github.com/v3/repos/#list-contributors) to successfully log in?
Op here: sorry, we got a little back logged processing the PRs when we hit the front page, and also because of exactly this username merge problem (whoops).
It's amusing because I've seen so many people mad at HN's lack of features, and spend so much noise demanding pg add this or that, or creating bookmarklets to "fix" it, or even forking the entire site just to try to modify a part of its functionality. But when offered the chance to collaboratively control the whole thing, on github, now it's "meh? why would anyone want that".
It's almost as if there are different people demanding different things for varying reasons or something.
Nah, just like Reddit, HN is a hivemind, and we all want the same thing at the same time. Any contradiction is evidence of our hypocrisy, not of the disjointed nature of our composition.
People seem to be questioning the validity of having domain knowledge in node/heroku/mongodb and an approved pull request be a prerequisite for joining a site not obviously about node development, not to the idea of an open source site in and of itself. If people had to learn Arc and have a pull request approved just to join HN, there would be maybe two or three people here.
Well, I managed to get a local instance running, poke around then hack together something. I would by no means call it 'borderline facile' though, just a set of annoying dependencies to install and hoops to jump through. That said, getting it set up was easier than I anticipated. (though granted, nobody has to do any of that to submit a pull request...)
Unfortunately I'm not interested in working on this code for the sole purpose of posting comments on this website. I honestly don't have that kind of time.
It's a fascinating idea. There is the Eternal September effect that can be combated by having a barrier to entry. Metafilter has $5 registration, stack-overflow has their own sauce. My friend who runs the VMS company prgmr.com requires someone to give them a public key to sign up.
I generally think this is a good idea to keep the riff-raff out. (then again, I've done countless anonymous spelling, format, and grammar corrections on wikipedia - but some people say their convoluted markup is the barrier)
The point here is, if I can get my eyes on the prize (the privilege to post), and if it doesn't look terribly valuable - then I have very little motive to hop on board.
My core contention is that the barrier has actually been placed too high. $5, a public key, learning wiki markup, providing correct answers - these are all easy tasks of very little effort. Doing code comprehension and diving into a project - that's a fairly large commitment.
Am I to be held responsible for the code? Will the people behind the project care if I continue to submit after I get the prize?
I count the circle of people I listen to, respect, and care about (here, it would be the commenting accounts) as greatly outnumbering the circle I'd want to work on code with.
Unfortunately, it appears to include node developers who don't have the time or patience to submit a pull request, those who do but whose requests won't be approved, and developers who code in languages other than javascript and who therefore have nothing useful enough to add, among the 'riff-raff'.
Some kind of proof of work is an interesting idea for a site like this, but I wonder if it self-selects for too narrow a domain? I don't know that the correlation between "submitted code" and "provides quality content" are strong enough for this particular filter to provide results worth the effort.
Op here: yeah, it might be the case that the community selection will be too narrow, but we figured almost any programmer knows something of HTML or CSS or JavaScript, so that seemed like a good lowest common denominator for a minimal standard of contribution.
The problem with that assumption is that it's very domain specific. While all good developers of web apps definitely know HTML and JS, there are a lot of fantastic programmers who have never touched it. The world of software is much, much bigger than just web apps.
It might run counter to your goals but wouldn't it accomplish more or less the same thing to require an approved pull request for any open source project? A similar amount of overhead would still be required, but you would wind up with a much more diverse population. You could even showcase the repos being worked on.
Op here: yeah, exactly - that's part of the thinking. Or maybe the feature surface area will expand enough that there's always low hanging fruit somewhere. I'm not really sure.
Or perhaps it will be a sparkling clean codebase, as I'm sure a lot of the low-hanging fruit will be re-factoring existing stuff and improving clarity/readability.
I had never thought about using the git push/pull model for anything but code and data. Could git, tunneled over ssh, build the decentralized web that we're all bandying about?
Selling one's personal data and selling one's 'soul' (principles) are two different things.
Just because GitHub only requires an email address to join, doesn't mean they're not incentivised to replace a decentralised Free Software system (git) with a centralised proprietary alternative (git+github).
I'm a massive fan of git, which is precisely why I do not, and never will, use github.
Hmm. I wasn't thinking about it from that perspective. Still, I don't see github as a replacement, but simply an optional nice UI for git collaboration. It's easy to set yourself up so that if Github went down or you wanted to move off it, you could. The only tricky part would be not investing too deeply in the issue tracker, but that's not a replacement for git anyway.
I'm not sure they can be said to be incentivized to do something that's nearly impossible.
GitHub is shady in its tracking and data gathering and is opposite the decentralized nature of git, so signing up would indeed be selling out on my principles for the ability to use this website. Truthfully, I've forgone things much more convenient or interesting for far less important matters (which is not to say this site is uninteresting.)
OP here, we just tried to pick a language that the most people would know. I'm pretty bad at JavaScript, but I know enough to get things done so we went with that.
Sure you could, but the point is rather to require this specific language. No option is totally without controversy, but this choice ensures a very specific audience (not just programmers/technical people, but ones who are into node) and anyone outside the audience is implicitly not welcome at all.
