|
a |
|
b/CONTRIBUTING.md |
|
|
1 |
# Contributing to InMoose |
|
|
2 |
|
|
|
3 |
InMoose aims at brining state-of-the-art bioinformatics tools to the Python |
|
|
4 |
ecosystem. The project is still in development, and any contribution is |
|
|
5 |
important! |
|
|
6 |
|
|
|
7 |
## How to contribute |
|
|
8 |
|
|
|
9 |
You have **many** ways to contribute to the InMoose project, and make it successful by: |
|
|
10 |
|
|
|
11 |
* adding features |
|
|
12 |
|
|
|
13 |
* reporting and fixing issues (from plain bugs to ergonomic concerns or |
|
|
14 |
documentation) |
|
|
15 |
|
|
|
16 |
* providing interesting examples and use cases (and make the data available) |
|
|
17 |
|
|
|
18 |
## Contributing in practice |
|
|
19 |
|
|
|
20 |
Any contribution should first be traced in a github issue. Before opening an |
|
|
21 |
issue, please make sure the topic you wish to address is not already covered by |
|
|
22 |
an existing issue. |
|
|
23 |
|
|
|
24 |
An issue is the place where a topic is discussed by the community: scope and |
|
|
25 |
implementation ideas for enhancements, reproduction steps and possible |
|
|
26 |
workarounds for bugs, ... |
|
|
27 |
|
|
|
28 |
Once an issue is mature enough for implementation, fork the github repo, and |
|
|
29 |
create a dedicated branch for the issue. Once your work is ready for review, |
|
|
30 |
please open a pull request (PR) to merge your branch into the master branch. |
|
|
31 |
Note that your code will be reviewed before merging, which may trigger further |
|
|
32 |
discussions or change requests on your code. Once the review process has |
|
|
33 |
converged towards approval, your PR (*i.e.* your contribution) will be merged in |
|
|
34 |
InMoose. Voilà! |
|
|
35 |
|
|
|
36 |
To be accepted, your contribution should be complete: |
|
|
37 |
- the targeted issue should be fully addressed, or limitations clearly |
|
|
38 |
documented. If needed, an issue may be split into several issues. |
|
|
39 |
- the new behavior should be properly tested. It means adding tests for new |
|
|
40 |
features, and updating existing tests when modifying an existing features. |
|
|
41 |
Bugfixes should typically add test cases to make sure that the bug is properly |
|
|
42 |
fixed. |
|
|
43 |
- the new behavior should be properly documented. This means: |
|
|
44 |
+ updating the documentation upon adding a feature, or when modifying an |
|
|
45 |
existing feature |
|
|
46 |
+ properly comment the code, especially parts that are not self-explanatory |
|
|
47 |
+ write sensible commit messages |
|
|
48 |
+ update the issue to describe the solution implemented |
|
|
49 |
|
|
|
50 |
## Testing InMoose on new data |
|
|
51 |
|
|
|
52 |
We believe that the best way of increasing InMoose robustness is to use it on as |
|
|
53 |
many various datasets as possible. |
|
|
54 |
|
|
|
55 |
## Writing documentation |
|
|
56 |
|
|
|
57 |
InMoose uses |
|
|
58 |
[Sphinx](https://www.sphinx-doc.org/en/master/usage/quickstart.html) to |
|
|
59 |
automatically document the main scripts. You can use the following command to |
|
|
60 |
build the documentation (from the docs folder): |
|
|
61 |
|
|
|
62 |
```bash |
|
|
63 |
sphinx-build -b html source/ . |
|
|
64 |
``` |