Development rules

Rule 1: Code of conduct

Please make sure to adhere to our code of conduct.

Rule 2: Consider writing documentation instead of code

Before even starting to develop a new function, one should ask this important question: Should this feature really be developed, or should I write a tutorial instead?

We remind that Kinetics Toolkit aims to provide tools for the user to achieve their needs in biomechanical research. Often, the best way to control our data is by learning how to do it instead of using a function performs it for us. In that view, any new feature should start with a discussion.

• To develop documentation, please contribute to the kineticstoolkit_doc repository, that versions this website’s code.

• Otherwise, to develop code, then continue with this guide.

Rule 3: For new features, consider writing an extension

Kinetics Toolkit supports extensions. This means you can program and distribute your own functions withing ktk, while keeping in full control and property of your code. Extensions are a good way to test new features and evaluate if they should or shouldn’t become part of the core library.

Rule 4: Contributing code to the core library

Before contributing code to the core library, please start a discussion to avoid misunderstanding or disappointment before even starting to code. Everybody’s efforts should converge toward an efficient direction. Once we agree on the feature being developed, use the usual method of forking, writing, testing, and writing a pull request that is described here.

Before creating a pull request, please ensure that:

• The new code respects the coding style.

• Your new code is tested using proper unit tests.

To ensure that this is the case, run ktk.dev.run_tests(). You should get no error.