|
| 1 | + |
| 2 | +Contributing to POT |
| 3 | +=================== |
| 4 | + |
| 5 | + |
| 6 | +First off, thank you for considering contributing to POT. |
| 7 | + |
| 8 | +How to contribute |
| 9 | +----------------- |
| 10 | + |
| 11 | +The preferred workflow for contributing to POT is to fork the |
| 12 | +[main repository](https://github.com/rflamary/POT) on |
| 13 | +GitHub, clone, and develop on a branch. Steps: |
| 14 | + |
| 15 | +1. Fork the [project repository](https://github.com/rflamary/POT) |
| 16 | + by clicking on the 'Fork' button near the top right of the page. This creates |
| 17 | + a copy of the code under your GitHub user account. For more details on |
| 18 | + how to fork a repository see [this guide](https://help.github.com/articles/fork-a-repo/). |
| 19 | + |
| 20 | +2. Clone your fork of the scikit-learn repo from your GitHub account to your local disk: |
| 21 | + |
| 22 | + ```bash |
| 23 | + $ git clone git@github.com:YourLogin/POT.git |
| 24 | + $ cd POT |
| 25 | + ``` |
| 26 | + |
| 27 | +3. Create a ``feature`` branch to hold your development changes: |
| 28 | + |
| 29 | + ```bash |
| 30 | + $ git checkout -b my-feature |
| 31 | + ``` |
| 32 | + |
| 33 | + Always use a ``feature`` branch. It's good practice to never work on the ``master`` branch! |
| 34 | + |
| 35 | +4. Develop the feature on your feature branch. Add changed files using ``git add`` and then ``git commit`` files: |
| 36 | + |
| 37 | + ```bash |
| 38 | + $ git add modified_files |
| 39 | + $ git commit |
| 40 | + ``` |
| 41 | + |
| 42 | + to record your changes in Git, then push the changes to your GitHub account with: |
| 43 | + |
| 44 | + ```bash |
| 45 | + $ git push -u origin my-feature |
| 46 | + ``` |
| 47 | + |
| 48 | +5. Follow [these instructions](https://help.github.com/articles/creating-a-pull-request-from-a-fork) |
| 49 | +to create a pull request from your fork. This will send an email to the committers. |
| 50 | + |
| 51 | +(If any of the above seems like magic to you, please look up the |
| 52 | +[Git documentation](https://git-scm.com/documentation) on the web, or ask a friend or another contributor for help.) |
| 53 | + |
| 54 | +Pull Request Checklist |
| 55 | +---------------------- |
| 56 | + |
| 57 | +We recommended that your contribution complies with the |
| 58 | +following rules before you submit a pull request: |
| 59 | + |
| 60 | +- Follow the PEP8 Guidelines. |
| 61 | + |
| 62 | +- If your pull request addresses an issue, please use the pull request title |
| 63 | + to describe the issue and mention the issue number in the pull request description. This will make sure a link back to the original issue is |
| 64 | + created. |
| 65 | + |
| 66 | +- All public methods should have informative docstrings with sample |
| 67 | + usage presented as doctests when appropriate. |
| 68 | + |
| 69 | +- Please prefix the title of your pull request with `[MRG]` (Ready for |
| 70 | + Merge), if the contribution is complete and ready for a detailed review. |
| 71 | + Two core developers will review your code and change the prefix of the pull |
| 72 | + request to `[MRG + 1]` and `[MRG + 2]` on approval, making it eligible |
| 73 | + for merging. An incomplete contribution -- where you expect to do more work before |
| 74 | + receiving a full review -- should be prefixed `[WIP]` (to indicate a work |
| 75 | + in progress) and changed to `[MRG]` when it matures. WIPs may be useful |
| 76 | + to: indicate you are working on something to avoid duplicated work, |
| 77 | + request broad review of functionality or API, or seek collaborators. |
| 78 | + WIPs often benefit from the inclusion of a |
| 79 | + [task list](https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-comments) |
| 80 | + in the PR description. |
| 81 | + |
| 82 | + |
| 83 | +- When adding additional functionality, provide at least one |
| 84 | + example script in the ``examples/`` folder. Have a look at other |
| 85 | + examples for reference. Examples should demonstrate why the new |
| 86 | + functionality is useful in practice and, if possible, compare it |
| 87 | + to other methods available in scikit-learn. |
| 88 | + |
| 89 | +- Documentation and high-coverage tests are necessary for enhancements to be |
| 90 | + accepted. Bug-fixes or new features should be provided with |
| 91 | + [non-regression tests](https://en.wikipedia.org/wiki/Non-regression_testing). |
| 92 | + These tests verify the correct behavior of the fix or feature. In this |
| 93 | + manner, further modifications on the code base are granted to be consistent |
| 94 | + with the desired behavior. |
| 95 | + For the Bug-fixes case, at the time of the PR, this tests should fail for |
| 96 | + the code base in master and pass for the PR code. |
| 97 | + |
| 98 | +- At least one paragraph of narrative documentation with links to |
| 99 | + references in the literature (with PDF links when possible) and |
| 100 | + the example. |
| 101 | + |
| 102 | +You can also check for common programming errors with the following |
| 103 | +tools: |
| 104 | + |
| 105 | + |
| 106 | +- No pyflakes warnings, check with: |
| 107 | + |
| 108 | + ```bash |
| 109 | + $ pip install pyflakes |
| 110 | + $ pyflakes path/to/module.py |
| 111 | + ``` |
| 112 | + |
| 113 | +- No PEP8 warnings, check with: |
| 114 | + |
| 115 | + ```bash |
| 116 | + $ pip install pep8 |
| 117 | + $ pep8 path/to/module.py |
| 118 | + ``` |
| 119 | + |
| 120 | +- AutoPEP8 can help you fix some of the easy redundant errors: |
| 121 | + |
| 122 | + ```bash |
| 123 | + $ pip install autopep8 |
| 124 | + $ autopep8 path/to/pep8.py |
| 125 | + ``` |
| 126 | + |
| 127 | +Bonus points for contributions that include a performance analysis with |
| 128 | +a benchmark script and profiling output (please report on the mailing |
| 129 | +list or on the GitHub issue). |
| 130 | + |
| 131 | +Filing bugs |
| 132 | +----------- |
| 133 | +We use Github issues to track all bugs and feature requests; feel free to |
| 134 | +open an issue if you have found a bug or wish to see a feature implemented. |
| 135 | + |
| 136 | +It is recommended to check that your issue complies with the |
| 137 | +following rules before submitting: |
| 138 | + |
| 139 | +- Verify that your issue is not being currently addressed by other |
| 140 | + [issues](https://github.com/rflamary/POT/issues?q=) |
| 141 | + or [pull requests](https://github.com/rflamary/POT/pulls?q=). |
| 142 | + |
| 143 | +- Please ensure all code snippets and error messages are formatted in |
| 144 | + appropriate code blocks. |
| 145 | + See [Creating and highlighting code blocks](https://help.github.com/articles/creating-and-highlighting-code-blocks). |
| 146 | + |
| 147 | +- Please include your operating system type and version number, as well |
| 148 | + as your Python, scikit-learn, numpy, and scipy versions. This information |
| 149 | + can be found by running the following code snippet: |
| 150 | + |
| 151 | + ```python |
| 152 | + import platform; print(platform.platform()) |
| 153 | + import sys; print("Python", sys.version) |
| 154 | + import numpy; print("NumPy", numpy.__version__) |
| 155 | + import scipy; print("SciPy", scipy.__version__) |
| 156 | + import ot; print("POT", ot.__version__) |
| 157 | + ``` |
| 158 | + |
| 159 | +- Please be specific about what estimators and/or functions are involved |
| 160 | + and the shape of the data, as appropriate; please include a |
| 161 | + [reproducible](http://stackoverflow.com/help/mcve) code snippet |
| 162 | + or link to a [gist](https://gist.github.com). If an exception is raised, |
| 163 | + please provide the traceback. |
| 164 | + |
| 165 | +New contributor tips |
| 166 | +-------------------- |
| 167 | + |
| 168 | +A great way to start contributing to scikit-learn is to pick an item |
| 169 | +from the list of [Easy issues](https://github.com/scikit-learn/scikit-learn/issues?labels=Easy) |
| 170 | +in the issue tracker. Resolving these issues allow you to start |
| 171 | +contributing to the project without much prior knowledge. Your |
| 172 | +assistance in this area will be greatly appreciated by the more |
| 173 | +experienced developers as it helps free up their time to concentrate on |
| 174 | +other issues. |
| 175 | + |
| 176 | +Documentation |
| 177 | +------------- |
| 178 | + |
| 179 | +We are glad to accept any sort of documentation: function docstrings, |
| 180 | +reStructuredText documents (like this one), tutorials, etc. |
| 181 | +reStructuredText documents live in the source code repository under the |
| 182 | +doc/ directory. |
| 183 | + |
| 184 | +You can edit the documentation using any text editor and then generate |
| 185 | +the HTML output by typing ``make html`` from the doc/ directory. |
| 186 | +Alternatively, ``make`` can be used to quickly generate the |
| 187 | +documentation without the example gallery. The resulting HTML files will |
| 188 | +be placed in ``_build/html/`` and are viewable in a web browser. See the |
| 189 | +``README`` file in the ``doc/`` directory for more information. |
| 190 | + |
| 191 | +For building the documentation, you will need |
| 192 | +[sphinx](http://sphinx.pocoo.org/), |
| 193 | +[matplotlib](http://matplotlib.org/), and |
| 194 | +[pillow](http://pillow.readthedocs.io/en/latest/). |
| 195 | + |
| 196 | +When you are writing documentation, it is important to keep a good |
| 197 | +compromise between mathematical and algorithmic details, and give |
| 198 | +intuition to the reader on what the algorithm does. It is best to always |
| 199 | +start with a small paragraph with a hand-waving explanation of what the |
| 200 | +method does to the data and a figure (coming from an example) |
| 201 | +illustrating it. |
| 202 | + |
| 203 | + |
| 204 | +This Contrubution guide is strongly inpired by the one of the [scikit-learn](https://github.com/scikit-learn/scikit-learn) team. |
0 commit comments