Hacker News new | ask | show | jobs
by dgit 5612 days ago
I use git-backed wikis for the 'conversation' part. Project mailing lists are wrong for the same reason that Subversion/CVS were wrong: Centralization turns a project political, at least that's my experience. Git's distributed storage encourages forking at a whim. If your 'conversation' is via a wiki you can fork that conversation any second.

Git-backed wiki how-to: My "wikis" currently simply are HTML pages served by gitweb right out of the repo, however I am experimenting with gollum and smeagol. That is: if your repos are on some server of your own, not github. I have no exprience with github and won't be caught dead using it.

2 comments

There is nothing worse than collaborative design in this world. To extend the article example, this is why architectural masterpieces are more or less never the result of collaborative design. Why designing langauges, databases, user interfaces, and in general programs should be different? It is not.
>I have no exprience with github and won't be caught dead using it.

...because?

- Should it be out of service for a short time, it'd be disrupting my workflow.

- Should it be out of service for a long time, I'd have to move to a different server and risk losing contacts that only know me by my github name/URL.

- Most importantly: On my server I have repos that are more open that 'private' but less open than 'public'. E.g. I hand out invites to a repo to attendees of a meeting. Or I limit by location using geo-IP.