Skip to content

Latest commit

 

History

History
74 lines (43 loc) · 3.64 KB

CONTRIBUTING.md

File metadata and controls

74 lines (43 loc) · 3.64 KB
Raw

Help us to help you!

Thank you for taking the time to contribute!

Suggesting a feature

We can't think of everything. If you've got a good idea for a feature or plugin, then please let us know!

Feature suggestions are embraced, but will often be filed for a rainy day. If you require a feature urgently it's best to write it yourself. Please consider sharing your work!

When suggesting a feature, make sure to:

  • Check the code on GitHub to make sure it's not already hiding in an unreleased version ;)
  • Check existing issues, open and closed, to make sure it hasn't already been suggested

Filing a bug report

If you're having trouble with Cardinal, the fastest way to get a response is to join us at #cardinal on the DarkScience IRC network. (irc.darkscience.net/+6697 &emdash; SSL required)

If all else fails then please raise an Issue to let us know. Be as detailed as possible, and be ready to answer questions when we get back to you. Some information that will help:

  • Tell us which version of Cardinal you're running: git describe --tags
  • Tell us which version of Docker you're running: docker version
  • List the steps you've taken so far and any solutions you've tried
  • Logs around the time of the issue (Cardinal and IRC logs as relevant)

Submitting a pull request

If you've decided to fix a bug, even something as small as a single-letter typo then great! Anything that improves the code/documentation for all future users is warmly welcomed.

If you decide to work on a requested feature it's best to let us (and everyone else) know what you're working on to avoid any duplication of effort. You can do this by replying to the original Issue for the request.

If you want to contribute an example, go for it! The wiki would be a great place to start.

When contributing a new example or making a change to a library please keep your code style consistent with ours. We try to stick to the PEP 8 guidelines for Python.

Do

  • Do use PEP 8 style guidelines
  • Do comment your code where necessary
  • Do submit only a single plugin/feature/bugfix per pull-request
  • Do include a description of what your code is expected to do

Don't

  • Don't include any license information in your code - our repositories are MIT licensed
  • Don't try to do too much at once - each pull request should contain a single idea

Licensing

When you submit code to our libraries, you implicitly and irrevocably agree to adopt the associated licenses. You should be able to find this in the file named LICENSE.

We use the MIT license; which permits Commercial Use, Modification, Distribution and Private use of our code, and therefore also your contributions. It also provides good compatibility with other licenses, and is intended to make re-use of our code as painless as possible for all parties.

You can learn more about the MIT license at Wikipedia: https://en.wikipedia.org/wiki/MIT_License

Submitting your code

Once you're ready to share your contribution with us you should submit it as a Pull Request.

  • Be ready to receive and embrace constructive feedback.
  • Be prepared for rejection; we can't always accept contributions. If you're unsure, ask first!
  • If you like, add your name to the CONTRIBUTORS file as part of your pull request! It's not a requirement, but we like to show thanks for contributions.

Thank you!

Happy hacking!

-- Cardinal development