Pull requests are welcome, as long as you're willing to put in the effort to meet the guidelines.

Over years of writing big scalable systems, I'm convinced that striving for simplicity wherever possible is the only way to build robust systems. This simplicity could be in design, or could be in coding, or could be achieved by rewriting the whole module, you just painfully wrote yesterday.

While putting all these guidelines in place, I'm aware that under certain circumstances some regression from the guidelines is inevitable. But, I hope that such a trade-off is clear and only applicable in rare conditions, with the knowledge that effort should be made as soon as possible to bring the project back within the guidelines.

General Guidelines

• DGraph aims for clear, well written, maintainable code.
• Simple and minimal approach to features, like Go.
• Refactoring existing code now for better performance, better readability, or better testability wins over adding a new feature.
• Don't add a function to a module that you don't use right now, or doesn't clearly enable a planned functionality.
• Don't ship a half done feature, which would need to be significantly altered to fully work.
• Avoid technical debt like cancer.

Style Guide

• If you see any code which clearly violates the style guide, please fix it and send a pull request. No need to ask for a permission.
• We're following Go Code Review.
• Use gofmt for formatting your code.
• Use go vet for checking your code.
• Use golint as well.
• Avoid unnecessary vertical spaces. Use your judgement, or follow the code review comments.
• Wrap your code and comments to 100 characters, unless doing so makes the code less legible.
• Follow the C++ style guide for any C/C++ code submissions.

Code Review Workflow

• All contributors need to sign the Contributor License Agreement.
• Pick an issue from pending issues.
• If the issue isn't currently present in the list, file a new issue.
• If you file a new issue, do bring it up on Google Group or Gitter Chat, and get someone with push access to think through the issue and acknowledge it.
• Indicate that you're working on the issue by assigning the issue to yourself.
• Create a new branch, write your code, and commit your changes locally.
• Make sure you run go test ./... from the root.
• Create a pull request
• DGraph uses Reviewable for code reviews, and follows a rigorous code review process.
• Address the comments, and repeat the cycle, until you get an LGTM by someone qualified.
• Once you have an LGTM, go ahead and merge. Most new contributors aren't allowed to merge themselves, in that case, we'll do it for you.