Preliminaries
The project SHALL use the Git distributed revision control system.
Git has its faults. Its command-line API is horribly inconsistent, and it has a complex, messy internal model that it shoves in your face at the slightest provocation. But despite doing its best to make its users feel stupid, Git does its job really, really well. More pragmatically, Iâve found that if you stay away from certain areas (branches!), people learn Git rapidly and donât make many mistakes. That works for me.
The project SHALL be hosted on github.com or equivalent, herein called the âPlatformâ.
Iâm sure one day some large firm will buy GitHub and break it, and another platform will rise in its place. GitHub serves up a near-perfect set of minimal, fast, simple tools. Iâve thrown hundreds of people at it, and they all stick like flies in a dish of honey.
The project SHALL use the Platform issue tracker.
We made the mistake in libzmq
of switching
to Jira because we hadnât learned yet how to properly use the GitHub
issue tracker. Jira is a great example of how to turn something useful
into a complex mess because the business depends on selling more
âfeatures.â But even without criticizing Jira, keeping the issue tracker
on the same platform means one less UI to learn, one less login, and
smooth integration between issues and patches.
The project SHOULD have clearly documented guidelines for code style.
This is a protocol plug-in: insert code style guidelines here. If you donât document ...
Get ZeroMQ now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.