Contributing - BBQuercus/deepBlink GitHub Wiki

Contributions are welcome 🙇, and they are greatly appreciated! Every little bit helps, and credit 💳 will always be given.

• 🐛 Bug reports
• 📚 Documentation improvements
• ✨ Feature request and feedback
• 💻 Development
• 🦮 Pull Request Guidelines
• 🎨 Commit Message Style guide

When reporting a bug please include:

• Your operating system name and version.
• Any details about your local setup that might be helpful in troubleshooting.
• Detailed steps to reproduce the bug.

DeepBlink could always use more documentation, whether as part of the official deepblink docs, in docstrings, or even on the web in blog posts, articles, and such. As the build process takes a while, please make sure to combine multiple changes (such as typos) into a single pull request.

The best way to send feedback is to file an issue.

If you are proposing a feature:

• Explain in detail how it would work.
• Keep the scope as narrow as possible, to make it easier to implement.
• Remember that this is a volunteer-driven project, and that code contributions are welcome :)

To set up deepblink for local development:

1. Fork deepblink (look for the "Fork" button).
2. Clone your fork locally: git clone [email protected]:BBQuercus/deepBlink.git.
3. Create a branch for local development with git checkout -b name-of-your-bugfix-or-feature. Now you can make your changes locally.
4. For the development environment all you need is pip install -e . and pip install tox.
5. When you're done making changes run all the checks and docs builder with tox one command: tox.
6. Commit your changes once tox is happy and push your branch to GitHub.
7. Submit a pull request through the GitHub website.

All pull requests are code reviewed by the core development team. For larger changes make sure to:

1. Follow the commit message style guide to keep things consistent.
2. Include passing tests (run tox)*.
3. Update documentation when there's new API, functionality etc.

* If you don't have all the necessary python versions available locally you can rely on Travis - it will run the tests for each change you add in the pull request. It will be much slower though ...

This style guide was adapted from @slashsbin/styleguide-git-commit-message. Go check out his for more detail for your own project.

<type> <subject>

<body>

<footer> (automatically generated)

• Capitalize the <subject>.
• Do not end the first line with a period.
• Total characters of the first line MUST be Less than or Equal to 50 characters Long.
• Use the present tense ("Add feature" not "Added feature").
• Use the imperative mood ("Move the cursor to..." not "Moves cursor to...").
• Use <type> to identify what type of changes introduced in this commit; see below for list of Emojis
• If you need more than one keyword or emoji to use, you should probably think twice!. This usually means you need to break this commit into more smaller commits; If that's not the case then separate each emoji with space.

• Includes motivation for the change and contrasts with previous behavior.
• Use the body to explain whats and whys vs. hows.
• Wrap each line of the body at 72 characters.

• Reference issues this commit is related to with the status of that Issue; Ex. Issue #27, Ref T27 or Ref T27, T56 or Fixes T8.
• Supported issue tracker status keywords:
  • Fixes/Fixed
  • Closes/Closed
  • Resolves/Resolved
  • Ref
  • Issue/Issues
• More info on issue tracker status keywords on GitHub Issues
• It's also recommended to use Full URL to the Issues, instead of just issue ID Number; Doing so will ease browsing issues from terminal.
• In the case of multiple issues separate them with commas, Ex. Closes #27, #56.

• Use valid MarkDown format in the <body>.
• All WIP(Work In Progress) commits SHOULD have the 🚧 Emoji.
• Although WIP commits SHOULD be avoided for PRs.
• Referencing Issues by using special keywords like Fixes or Resolves will mark them as closed automatically! For more information about automatic issue closing using keywords see their documentation(linked above).
• There is NO new-line after the <footer>.
• Every emoji text(:emoji:) is counted as one character!.