Development Guidelines

PranaDB development guidelines

If you're starting work on a task that's going to take longer than a few days, best to create a short one pager document to outline the design approach that's going to be taken. This gives everyone a chance to discuss it.

When reviewing PRs, don't be pedantic or obsess over cosmetic things or code style. If the PR is more or less right and just needs some small changes, prefer to approve with some notes so the author can apply the changes themselves and merge. Uber's Go Style Guide is a good resource of idiomatic code snippets that we can point to for small review nits.
We are a globally distributed team and it's important that we don't get blocked due to timezones. If you submit a PR at the end of your working day, the other team members should try to review it before you start work the next day. If it hasn't been reviewed, feel free to merge it yourself. We value trust over perfection and any needed changes can be applied later.
If you have a really trivial change in a PR (cosmetic, one liner), unless it's super quick to get someone to stamp the PR, feel free just to merge it yourself.

Thank you for your interest in contributing to PranaDB!

You will need to sign the Block CLA in order to contribute
If you are interested in doing some development, we suggest first trying a simple task - these are marked with "Good First Issue" in GitHub issues
If you're confident to tackle something more complex, we suggest first commenting on the issue to show your interest and we can take it from there.