We need to develop not just for ourselves, but for those who follow us. This means following good development process to provide transparency, maintainability and readability to what we’re doing.
Unix style: CRLF line endings.
No trailing spaces.
No tabs: use 4 spaces instead.
Bracketing style: use the style that’s already there.
You are not a compiler: code for readability, not compactness.
We are open source: coding security-by-obscurity is not necessary. Use semantically sensible function and variable names.
Comments. More comments. Still more comments. Nobody will know what your brilliant idea was when you wrote that gnarly piece of code unless you tell them.
Commit messages. Commit discrete changes, don’t munge six different fixes into a single commit. And provide a clear message (preferably tied into a GitHub issue) of what problem these changes address.
Before you begin¶
Found a bug? Got an enhancement? Great!
New Feature considerations: this is an open source project. If your change isn’t a basic part of what is already planned, will you be around to support it? Can you justify why it’s in the best interests of the project to have your change included? We’d love to talk it through with you: contact us via the mailing lists.
First, check out our Guide to GitHub, which covers:
Create a GitHub account.
Fork the repository.
Clone the fork.
Branch the clone.
From there, you:
Take ownership of a GitHub issue (or create a new one to cover what you’re planning to do).
Code code test test test code code test test test.
Use git to commit your changes.
Issue a pull request on GitHub.
Wait for review (a quick note to the mailing list can speed this along).
Once approved, it’ll be merged into the master.
Patches through the mailing list¶
If you’re not planning on regularly submitting changes, you can just send your patch through to the mailing list and one of the regular maintainers will see about incorporating it.