[9635] | 1 | |
---|
[9717] | 2 | ================= |
---|
[9635] | 3 | Contributing code |
---|
| 4 | ================= |
---|
| 5 | |
---|
[9639] | 6 | The preferred way to contribute to anuga is to fork the |
---|
[9717] | 7 | `main repository <http://github.com/stoiver/anuga_core>`_ on GitHub: |
---|
[9635] | 8 | |
---|
[9717] | 9 | 1. Fork the `project repository <http://github.com/GeoscienceAustralia/anuga_core>`_: |
---|
[9635] | 10 | click on the 'Fork' button near the top of the page. This creates |
---|
| 11 | a copy of the code under your account on the GitHub server. |
---|
| 12 | |
---|
[9717] | 13 | 2. Clone this copy to your local disk:: |
---|
[9635] | 14 | |
---|
[9639] | 15 | $ git clone git@github.com:YourLogin/anuga_core.git |
---|
| 16 | $ cd anuga_core |
---|
[9635] | 17 | |
---|
[9717] | 18 | 3. Create a branch to hold your changes:: |
---|
[9635] | 19 | |
---|
| 20 | $ git checkout -b my-feature |
---|
| 21 | |
---|
| 22 | and start making changes. Never work in the ``master`` branch! |
---|
| 23 | |
---|
| 24 | 4. Work on this copy on your computer using Git to do the version |
---|
[9717] | 25 | control. When you're done editing, do:: |
---|
[9635] | 26 | |
---|
| 27 | $ git add modified_files |
---|
| 28 | $ git commit |
---|
| 29 | |
---|
[9717] | 30 | to record your changes in Git, then push them to GitHub with:: |
---|
[9635] | 31 | |
---|
| 32 | $ git push -u origin my-feature |
---|
| 33 | |
---|
[9640] | 34 | Finally, go to the web page of the your fork of the anuga_core repo, |
---|
[9635] | 35 | and click 'Pull request' to send your changes to the maintainers for |
---|
| 36 | review. request. This will send an email to the committers. |
---|
| 37 | |
---|
| 38 | (If any of the above seems like magic to you, then look up the |
---|
[9717] | 39 | `Git documentation <http://git-scm.com/documentation>`_ on the web.) |
---|
[9635] | 40 | |
---|
| 41 | It is recommended to check that your contribution complies with the |
---|
| 42 | following rules before submitting a pull request: |
---|
| 43 | |
---|
| 44 | - All public methods should have informative docstrings with sample |
---|
| 45 | usage presented as doctests when appropriate. |
---|
| 46 | |
---|
| 47 | - All other tests pass when everything is rebuilt from scratch. On |
---|
[9717] | 48 | Unix-like systems, check with (from the toplevel source folder):: |
---|
[9635] | 49 | |
---|
| 50 | $ make |
---|
| 51 | |
---|
| 52 | - When adding additional functionality, provide at least one |
---|
| 53 | example script in the ``examples/`` folder. Have a look at other |
---|
| 54 | examples for reference. Examples should demonstrate why the new |
---|
[9640] | 55 | functionality is useful in practice. |
---|
[9635] | 56 | |
---|
| 57 | - At least one paragraph of narrative documentation with links to |
---|
[9640] | 58 | references in the literature (with PDF links when possible) and |
---|
| 59 | an example. |
---|
[9635] | 60 | |
---|
| 61 | You can also check for common programming errors with the following |
---|
| 62 | tools: |
---|
| 63 | |
---|
[9717] | 64 | - Code with good unittest coverage (at least 80%), check with:: |
---|
[9635] | 65 | |
---|
| 66 | $ pip install nose coverage |
---|
| 67 | $ nosetests --with-coverage path/to/tests_for_package |
---|
| 68 | |
---|
[9717] | 69 | - No pyflakes warnings, check with:: |
---|
[9635] | 70 | |
---|
| 71 | $ pip install pyflakes |
---|
| 72 | $ pyflakes path/to/module.py |
---|
| 73 | |
---|
[9717] | 74 | - No PEP8 warnings, check with:: |
---|
[9635] | 75 | |
---|
| 76 | $ pip install pep8 |
---|
| 77 | $ pep8 path/to/module.py |
---|
| 78 | |
---|
[9717] | 79 | - AutoPEP8 can help you fix some of the easy redundant errors:: |
---|
[9635] | 80 | |
---|
| 81 | $ pip install autopep8 |
---|
| 82 | $ autopep8 path/to/pep8.py |
---|
| 83 | |
---|
| 84 | Bonus points for contributions that include a performance analysis with |
---|
| 85 | a benchmark script and profiling output (please report on the mailing |
---|
| 86 | list or on the GitHub issue). |
---|
| 87 | |
---|
| 88 | Easy Issues |
---|
| 89 | ----------- |
---|
| 90 | |
---|
[9640] | 91 | A great way to start contributing to anuga is to pick an item |
---|
[9717] | 92 | from the list of `Easy issues <https://github.com/GeoscienceAustralia/anuga_core/issues?labels=Easy>`_ |
---|
[9640] | 93 | in the issue tracker. (Well there are none there yet, but we will be |
---|
| 94 | putting some up soon!) Resolving these issues allow you to start |
---|
[9635] | 95 | contributing to the project without much prior knowledge. Your |
---|
| 96 | assistance in this area will be greatly appreciated by the more |
---|
| 97 | experienced developers as it helps free up their time to concentrate on |
---|
| 98 | other issues. |
---|
| 99 | |
---|
| 100 | Documentation |
---|
| 101 | ------------- |
---|
| 102 | |
---|
[9640] | 103 | We are in the process of creating sphinx based documentation for anuga. |
---|
| 104 | Any help in setting this up will be gratefully accepted! |
---|
| 105 | |
---|
| 106 | At present you will find the user_manual in the doc folder. |
---|
| 107 | |
---|
[9635] | 108 | We are glad to accept any sort of documentation: function docstrings, |
---|
| 109 | reStructuredText documents (like this one), tutorials, etc. |
---|
| 110 | reStructuredText documents live in the source code repository under the |
---|
| 111 | doc/ directory. |
---|
| 112 | |
---|
| 113 | When you are writing documentation, it is important to keep a good |
---|
| 114 | compromise between mathematical and algorithmic details, and give |
---|
| 115 | intuition to the reader on what the algorithm does. It is best to always |
---|
| 116 | start with a small paragraph with a hand-waving explanation of what the |
---|
| 117 | method does to the data and a figure (coming from an example) |
---|
| 118 | illustrating it. |
---|
| 119 | |
---|