3 ms·
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 p
by dgit 16y 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.
- antirez 16y agoThere 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.
- metageek 16y ago>I have no exprience with github and won't be caught dead using it. ...because?
- dgit 16y ago- 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.