Contributions are welcome and are greatly appreciated! Every little bit helps, and credit will always be given.
- Formatting Style
- Branching model
- Contribution process
- Types of Contributions
- Documentation
- Development and Testing
In order to have a standardised code base, we only accept code that is formatted according to PEP 8.
Our branching model has one permanent branch, master. We aim at using master
as the main branch, where all
features are merged. In this sense, we also use the master branch to contain the release versions of the C# Khiva library
by means of git tags.
In order to contribute to the code base, we follow the next process :
- The main branch is
master
, every developer should pull the current status of the branch before starting to develop any new feature.git pull
- Create a new branch with the following pattern "feature/[name_of_the_feature]"
git checkout -b feature/example_feature
- Develop the new feature on the the new branch. It includes testing and documentation.
git commit -a -m "Bla, Bla, Bla"; git push
- Open a Pull Request to merge the feature branch into
master
. Currently, a pull request has to be reviewed at least by one person. - Finally, delete the feature branch.
- Move back to
master
branch.git checkout master
- Pull the latest changes.
git pull
Report bugs through GitHub issues
Please follow the project issue template to exhibit the problem.
Look through the GitHub issues for bugs. Anything is open to whoever wants to implement it.
Look through the GitHub issues for feature requests. Any unassigned "Improvement" issue is open to whoever wants to implement it.
Khiva could always use better documentation, whether as part of the official Khiva docs, or even description of the methods in the different namespaces.
The best way to send feedback is to open an issue on GitHub issues
If you are proposing a feature, please follow the feature request template.
Start a new docker container.
# Start docker
docker run --rm -ti shapelets/khiva-csharp