"We figured pretty much everybody knows JavaScript"
Haha, that's funny. I guess all of the world's software runs on the web and is written in Silicon Valley. Oh wait, what's that you say, some programmers actually work on all those weird machines like satellites, assembly lines, medical devices, power plants, and even my car?! People actually write new operating systems, compilers, web servers, load balancers, and device drivers?! No way! Why don't they just make a web app for that stuff?Yeesh. I realize that you can't please everyone, but some people chose to live in their own little worlds.
The satellite that you join via pull request can be written in whatever you want :)
"Pull me up, Scotty!"
"Almost everybody who works on a website knows JavaScript."
That I can agree with.I work in systems. I don't really know JS. I do know C, C++, C#, Haskell, various dialects of Lisp, Python, and Ruby however. Why would I subject myself to learning JS unless I absolutely needed to?
> We figured pretty much everybody knows JavaScript
Even with the implied "everybody" being "everybody that would be interested in joining our site", this is a poor assumption. Not everyone is a ninja-rockstar web developer. In fact, some of the best content on HN comes from people who most likely don't know JS. I get the idea for the site, but the description seems very naive.
(FWIW, I do know JS)
I'm still not entirely convinced that it serves as an adequate social filter, however, and I agree it might be too technically limiting to lead to a diverse userbase, but as an experiment I think it's worth watching.
It's an interesting idea for some kind of expertise test to contribute to a public forum, but it will be very self-selecting too.
Assumption confirmed!
Oddly enough, you wouldn't necessarily require people to use the command-line for this, but nor would you need to build any editing UI; instead, the site could just, say, provide a context menu that contains links to the GitHub code-editor view of all the source files, and content files, that were used to render that particular element.
If you really wanted to do this, to be practical, you'd need a pretty good continuous integration server to block the deployed build from failing, but for the codebase itself, I think it'd be a fun experiment to just let people do whatever they like.
---
...or, on a different tangent, you could have something like a CI server that evaluates and accepts/rejects pull requests based on arbitrary criteria. This'd basically be a black box (not part of the editable codebase) serving the same purpose that the site administration currently does.
This process could have very specific rules, like, say, that not only does every test have to pass, but that the commit can't delete any code from a test. So features can be added to a codebase through this black box, but not removed.
Attaching such a black-box-evaluator + automatic CI deployment process to the public web would almost be like throwing a genetic algorithm at your codebase: it would "evolve" roughly according to the constraints of the algorithm, even though people are doing the work.
Good idea, but this is easily gamed by e.g. adding a test that starts failing on a certain date. I've thought about this before, and it's really hard to come up with mechanisms for a system to incorporate untrusted modifications without totally collapsing.
It would be hilarious to design a program that accepts Bitcoin payments, and automatically accepts merge requests from the highest bidder.
Honest question and not trolling. Can I send a pull request to update this text to "We figured JavaScript is very popular these days....."
EDIT: I just did it anyway. Feel free to accept/reject
One thing that this would be good for is almost by default members get experience working with the technologies the site is running -- they learn to use Github, deploy node.js, etc. It gives them a working technology base for their own projects.
One problem I foresee is that without a clear discussion about where the site is going, it could quickly become rife with lots of poorly-interacting features. Another is that delays in merging might well turn away valuable members.
Still, interesting project.
On the bright-side at least the project is MIT. Good ol' MIT.
But never implemented / merged. Surprised the powers-that-be are resisting the most elegant solution. Then again, I came up with it, so I remain bitter and biased :)
The old saying, "don't fix it if it ain't broke."
HAHAHAHA, good luck with that.
(But still, a nice idea for a site)