Skip to content

Latest commit

 

History

History
56 lines (35 loc) · 2.24 KB

CONTRIBUTING.md

File metadata and controls

56 lines (35 loc) · 2.24 KB
Raw

Questions

Want to hack on Nanocloud? This page contains information about reporting issues and contributing code.

Issues

Think you've found a bug or have a new feature to suggest? Let us know!

  1. Update to the most recent master release if possible. We may have already fixed your bug.

  2. Search for similar issues. It's possible somebody has encountered this bug already.

  3. Your issue will be verified. Please provide as much information as possible to reproduce the issue.

  4. Keep up to date with feedback from the Nanocloud team on your ticket. Your ticket may be closed if it becomes stale.

The more information you provide, the easier it is for us to validate that there is a bug and the faster we'll be able to take action.

Pull Requests

We love pull requests. Here's a quick guide:

  1. Fork the repo.

  2. Run the tests. We only take pull requests with passing tests, and it's great to know that you have a clean slate: make tests.

  3. Add a test for your change. Only refactoring and documentation changes require no new tests. If you are adding functionality or fixing a bug, we need a test!

  4. Make the test pass.

  5. Push to your fork and submit a pull request. Please provide us with some explanation of why you made the changes you made. For new features make sure to explain a standard use case to us.

Before you make a pull request, squash your commits into logical units of work using git rebase -i and git push -f. A logical unit of work is a consistent set of patches that should be reviewed together: for example, upgrading the version of a vendored dependency and taking advantage of its now available new feature constitute two separate units of work. Implementing a new function and calling it in another file constitute a single logical unit of work.

Syntax:

  • Two spaces, no tabs.
  • No trailing whitespace. Blank lines should not have any space.
  • a = b and not a=b.
  • Follow the conventions you see used in the source already.
  • Run test-linter to validate your code syntax

Travis CI Tests

We use Travis CI to test each PR before it is merged.

When you submit your PR (or later change that code), a Travis build will automatically be kicked off. A note will be added to the PR, and will indicate the current status of the build.