1# Contributing to SPQlios-fft
 2
 3The spqlios-fft team encourages contributions.
 4We encourage users to fix bugs, improve the documentation, write tests and to enhance the code, or ask for new features.
 5We encourage researchers to contribute with implementations of their FFT or NTT algorithms.
 6In the following we are trying to give some guidance on how to contribute effectively.
 7
 8## Communication ##
 9
10Communication in the spqlios-fft project happens mainly on [GitHub](https://github.com/tfhe/spqlios-fft/issues).
11
12All communications are public, so please make sure to maintain professional behaviour in
13all published comments. See [Code of Conduct](https://www.contributor-covenant.org/version/2/1/code_of_conduct/) for
14guidelines.
15
16## Reporting Bugs or Requesting features ##
17
18Bug should be filed at [https://github.com/tfhe/spqlios-fft/issues](https://github.com/tfhe/spqlios-fft/issues).
19
20Features can also be requested there, in this case, please ensure that the features you request are self-contained,
21easy to define, and generic enough to be used in different use-cases. Please provide an example of use-cases if
22possible.
23
24## Setting up topic branches and generating pull requests
25
26This section applies to people that already have write access to the repository. Specific instructions for pull-requests
27from public forks will be given later.
28
29To implement some changes, please follow these steps:
30
31- Create a "topic branch". Usually, the branch name should be `username/small-title`
32  or better `username/issuenumber-small-title` where `issuenumber` is the number of
33  the github issue number that is tackled.
34- Push any needed commits to your branch. Make sure it compiles in `CMAKE_BUILD_TYPE=Debug` and `=Release`, with `-DWARNING_PARANOID=ON`.
35- When the branch is nearly ready for review, please open a pull request, and add the label `check-on-arm`
36- Do as many commits as necessary until all CI checks pass and all PR comments have been resolved.
37
38  >  _During the process, you may optionnally use `git rebase -i` to clean up your commit history. If you elect to do so,
39  please at the very least make sure that nobody else is working or has forked from your branch: the conflicts it would generate
40  and the human hours to fix them are not worth it. `Git merge` remains the preferred option._
41
42- Finally, when all reviews are positive and all CI checks pass, you may merge your branch via the github webpage.
43
44### Keep your pull requests limited to a single issue
45
46Pull requests should be as small/atomic as possible.
47
48### Coding Conventions
49
50* Please make sure that your code is formatted according to the `.clang-format` file and
51  that all files end with a newline character.
52* Please make sure that all the functions declared in the public api have relevant doxygen comments.
53  Preferably, functions in the private apis should also contain a brief doxygen description.
54
55### Versions and History
56
57* **Stable API** The project uses semantic versioning on the functions that are listed as `stable` in the documentation. A version has
58  the form `x.y.z`
59    * a patch release that increments `z` does not modify the stable API.
60    * a minor release that increments `y` adds a new feature to the stable API.
61    * In the unlikely case where we need to change or remove a feature, we will trigger a major release that
62    increments `x`.
63
64    >    _If any, we will mark those features as deprecated at least six months before the major release._
65
66* **Experimental API** Features that are not part of the stable section in the documentation are experimental features: you may test them at
67  your own risk,
68  but keep in mind that semantic versioning does not apply to them.
69
70>  _If you have a use-case that uses an experimental feature, we encourage
71>  you to tell us about it, so that this feature reaches to the stable section faster!_
72
73* **Version history** The current version is reported in `manifest.yaml`, any change of version comes up with a tag on the main branch, and the history between releases is summarized in `Changelog.md`. It is the main source of truth for anyone who wishes to
74  get insight about
75  the history of the repository (not the commit graph).
76
77>  Note: _The commit graph of git is for git's internal use only. Its main purpose is to reduce potential merge conflicts to a minimum, even in scenario where multiple features are developped in parallel: it may therefore be non-linear. If, as humans, we like to see a linear history, please read `Changelog.md` instead!_