- Bug Reports
- Feature Requests
- Simple Issue template
- Documentation Contributions
- Code Contributions
- Submitting changes
This document lays out guidelines and advice for contributing to this project. If you're thinking of contributing, please start by reading this document and getting a feel for how contributing to this project works.
The guide is split into sections based on the type of contribution you're thinking of making.
Bug reports are hugely important! Before you raise one, though, please check through the GitHub issues
, both open and closed, to confirm that the bug hasn't been reported before.
When filing an issue, make sure to answer these questions:
- Which Python version are you using?
- Which version of
trifid
are you using? - What did you expect to see?
- What did you actually see?
- What are you going to do?
The best way to get your bug fixed is to provide a test case, and/or steps to reproduce the issue.
If you believe there is a feature missing, feel free to raise a Feature request
to answer:
- A clear and concise description of what the problem is.
- The solution you would like.
- Alternatives you have considered.
- Additional context.
If you don't feel confortable with the previous options, you can also use the Simple Issue template
Documentation improvements are always welcome!
You do not have to setup a development environment to make small changes to the docs. Instead, you can edit files directly on GitHub
_ and suggest changes.
If you intend to contribute code, do not feel the need to sit on your contribution until it is perfectly polished and complete. It helps everyone involved for you to seek feedback as early as you possibly can. Submitting an early, unfinished version of your contribution for feedback can save you from putting a lot of work into a contribution that is not suitable for the project.
- Create an issue.
- Assign the issue to a developer and create a branch.
- Create a Pull Request.
- The admin (first creator) of the repository will review the Pull Request.
- Always perform work in a feature branch.
- It is better to branch out from
develop
branch. - Delete local and remote feature branches after merging.
- Separate the subject from the body with a newline between the two (if the body exists).
- Limit the subject line to 50 characters and Wrap the body at 72 characters.
- Capitalize the subject line.
- Do not end the subject line with a period.
- Use imperative mood in the subject line.
Example:
git commit -m "Update getting started documentation"
(If applied, this commit will update getting started documentation)