|
| 1 | +# Contributing to InvertibleNetworks.jl |
| 2 | + |
| 3 | +We welcome third-party contributions, and we would love you to become an active contributor! |
| 4 | + |
| 5 | +Software contributions are made via GitHub pull requests. If you are planning a large contribution, we encourage you to engage with us frequently to ensure that your effort is well-directed. See below for more details. |
| 6 | + |
| 7 | +This repository is distributed under the MIT License, https://github.com/slimgroup/InvertibleNetworks.jl/blob/master/LICENSE. The act of submitting a pull request or patch (with or without an explicit Signed-off-by tag) will be understood as an affirmation of the following: |
| 8 | + |
| 9 | + Developer's Certificate of Origin 1.1 |
| 10 | + |
| 11 | + By making a contribution to this project, I certify that: |
| 12 | + |
| 13 | + (a) The contribution was created in whole or in part by me and I |
| 14 | + have the right to submit it under the open source license |
| 15 | + indicated in the file; or |
| 16 | + |
| 17 | + (b) The contribution is based upon previous work that, to the best |
| 18 | + of my knowledge, is covered under an appropriate open source |
| 19 | + license and I have the right under that license to submit that |
| 20 | + work with modifications, whether created in whole or in part |
| 21 | + by me, under the same open source license (unless I am |
| 22 | + permitted to submit under a different license), as indicated |
| 23 | + in the file; or |
| 24 | + |
| 25 | + (c) The contribution was provided directly to me by some other |
| 26 | + person who certified (a), (b) or (c) and I have not modified |
| 27 | + it. |
| 28 | + |
| 29 | + (d) I understand and agree that this project and the contribution |
| 30 | + are public and that a record of the contribution (including all |
| 31 | + personal information I submit with it, including my sign-off) is |
| 32 | + maintained indefinitely and may be redistributed consistent with |
| 33 | + this project or the open source license(s) involved. |
| 34 | + |
| 35 | +### Reporting issues |
| 36 | + |
| 37 | +There are several options: |
| 38 | +* Talk to us. The current main developer is Rafael Orozco [[email protected]] |
| 39 | +* File an issue or start a discussion on the repository. |
| 40 | + |
| 41 | +### Making changes |
| 42 | + |
| 43 | +First of all, read our [code of conduct](https://github.com/slimgroup/.github/blob/master/CODE_OF_CONDUCT.md) and make sure you agree with it. |
| 44 | + |
| 45 | +The protocol to propose a patch is: |
| 46 | +* [Recommended, but not compulsory] Talk to us about what you're trying to do. There is a great chance we can support you. |
| 47 | +* As soon as you know what you need to do, [fork](https://help.github.com/articles/fork-a-repo/) the repository. |
| 48 | +* Create a branch with a suitable name. |
| 49 | +* Write code following the guidelines below. Commit your changes as small logical units. |
| 50 | +* Write meaningful commit messages. |
| 51 | +* Write tests to convince us and yourself that what you've done works as expected. Commit them. |
| 52 | +* Run **the entire test suite**, including the new tests, to make sure that you haven't accidentally broken anything else. |
| 53 | +* Push everything to your fork. |
| 54 | +* Submit a Pull Request on our repository. |
| 55 | +* Wait for us to provide feedback. This may require a few iterations. |
| 56 | + |
| 57 | +Tip, especially for newcomers: prefer short, self-contained Pull Requests over lengthy, impenetrable, and thus difficult to review, ones. |
| 58 | + |
| 59 | +### Coding guidelines |
| 60 | + |
| 61 | +Some coding rules are "enforced" (and automatically checked by our Continuous Integration systems), some are "strongly recommended", others are "optional" but welcome. |
| 62 | + |
| 63 | +* We _strongly recommend_ to document any new module, type, method, ... with [julia documentation](https://docs.julialang.org/en/v1/manual/documentation/). |
| 64 | +* We _strongly recommend_ to follow standard Julia coding guidelines: |
| 65 | + - Use camel caps for struct names, e.g. ``struct FooBar``. |
| 66 | + - Method names must start with a small letter; use underscores to separate words, e.g. ``function my_meth_...``. |
| 67 | + - Variable names should be explicative (We prefer "long and clear" over "short but unclear"). |
| 68 | + - Comment your code, and do not be afraid of being verbose. |
| 69 | +* We _like_ that blank lines are used to logically split blocks of code implementing different (possibly sequential) tasks. |
| 70 | + |
| 71 | +### Adding tutorials or examples |
| 72 | + |
| 73 | +We always look forward to extending our [suite of tutorials and examples](https://github.com/slimgroup/SLIMTutorials) with new Jupyter Notebooks. Even something completely new, such as a new series of tutorials showing your work with our softwares, would be a great addition. |
0 commit comments