Contributing

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

Content

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

Bug reports

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.

Documentation improvements

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.

Feature requests and feedback

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 :)

Development

To set up deepblink for local development:

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

Pull Request guidelines

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

Follow the commit message style guide to keep things consistent.
Include passing tests (run tox)*.
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 ...

Commit message style guide

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

Format

<type> <subject>

<body>

<footer> (automatically generated)

Message Subject (first line)

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.

Message Body

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.

Message Footer

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.

Notes

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!.

Emojis

Emoji	Raw Emoji Code	Description
🎨	`:art:`	when improving the format/structure of the code
📰	`:newspaper:`	when creating a new file
📝	`:pencil:`	when performing minor changes/fixing the code or language
🐎	`:racehorse:`	when improving performance
📚	`:books:`	when writing docs
🐛	`:bug:`	when reporting a bug, with `@FIXME` Comment Tag
🚑	`:ambulance:`	when fixing a bug
🔥	`:fire:`	when removing code or files
🚜	`:tractor:`	when change file structure. Usually together with 🎨
🔨	`:hammer:`	when refactoring code
☔	`:umbrella:`	when adding tests
💚	`:green_heart:`	when fixing the CI build
🔒	`:lock:`	when dealing with security
⬆️	`:arrow_up:`	when upgrading dependencies
⬇️	`:arrow_down:`	when downgrading dependencies
🚧	`:construction:`	WIP(Work In Progress) Commits
💎	`:gem:`	New Release
🎉	`:tada:`	Initial Commit
✨	`:sparkles:`	when introducing New Features
🤝	`:handshake:`	when Merge files