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 the Google rules for C++ with a column width of 120 characters and an indentation of 4 whitespaces. For this purpose, we use clang-format
, which can be installed in MacOs by executing the next command: brew install clang-format
.
We use the clang-format
plugin for the VS Code editor to format our codes. This plugin uses the clang-format
program and the aforementioned rules under the hood.
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 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.
We have included an initial set of algorithms, but feel free to add any new one(s).
Khiva could always use better documentation, whether as part of the official Khiva docs,
doc/sphinx/source/*.rst
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 -ti shapelets/khiva