|
| 1 | +Contributing to typex |
| 2 | +==================== |
| 3 | + |
| 4 | +.. |fork_logo| image:: https://upload.wikimedia.org/wikipedia/commons/d/dd/Octicons-repo-forked.svg |
| 5 | + :height: 20 |
| 6 | + |
| 7 | +Contents |
| 8 | +-------- |
| 9 | + |
| 10 | +1. `Introduction <#introduction>`_ |
| 11 | + |
| 12 | +2. `Issues <#issues>`_ |
| 13 | + |
| 14 | + a. `Asking Questions <#asking-questions>`_ |
| 15 | + |
| 16 | + b. `Reporting Bugs <#reporting-bugs>`_ |
| 17 | + |
| 18 | + c. `Requesting Features <#requesting-features>`_ |
| 19 | + |
| 20 | +3. `Pull Requests <#pull-requests>`_ |
| 21 | + |
| 22 | + a. `Content <#content>`_ |
| 23 | + |
| 24 | + b. `CI Tests <#ci-tests>`_ |
| 25 | + |
| 26 | + c. `Coverage <#coverage>`_ |
| 27 | + |
| 28 | + d. `Style Guide <#style-guide>`_ |
| 29 | + |
| 30 | +Introduction |
| 31 | +------------ |
| 32 | + |
| 33 | +typex is fully open-source and as such users are welcome to fork, clone and/or reuse the software freely. |
| 34 | +Users wishing to contribute to the development of this package, however, are kindly requested to adhere to the |
| 35 | +following `LICENSE <./LICENSE.rst>`_. |
| 36 | + |
| 37 | +Issues |
| 38 | +------ |
| 39 | + |
| 40 | +The easiest way to contribute to typex is by raising a "New issue". This will give you the opportunity to ask questions, report bugs or |
| 41 | +even request new features. |
| 42 | +Remember to use clear and descriptive titles for issues. This will help other users that encounter similar problems find quick solutions. |
| 43 | +We also ask that you read the available documentation and browse existing issues on similar topics before raising a new issue in order to avoid repetition. |
| 44 | + |
| 45 | +Asking Questions |
| 46 | +~~~~~~~~~~~~~~~~ |
| 47 | + |
| 48 | +Users are of course welcome to ask any question relating to typex and we will endeavour to reply as soon as possible. |
| 49 | + |
| 50 | +These issues should include the **help wanted** label. |
| 51 | + |
| 52 | +Reporting Bugs |
| 53 | +~~~~~~~~~~~~~~ |
| 54 | + |
| 55 | +If you discover a bug while using typex please include the following details in the issue you raise: |
| 56 | + |
| 57 | +* your operating system and the corresponding version (*e.g.* macOS v10.14.1, Ubuntu v20.04.1, *etc.*), |
| 58 | +* the version of Python you are using (*e.g* v3.6.7, *etc.*), |
| 59 | +* and the error message printed or a screen capture of the terminal output. |
| 60 | + |
| 61 | +Be sure to list the exact steps you followed that lead to the bug you encountered so that we can attempt to recreate the conditions. |
| 62 | +If you are aware of the source of the bug we would very much appreciate if you could provide the module(s) and line number(s) affected. |
| 63 | +This will enable us to more rapidly fix the problem. |
| 64 | + |
| 65 | +These issues should include the **bug** label. |
| 66 | + |
| 67 | +Requesting Features |
| 68 | +~~~~~~~~~~~~~~~~~~~ |
| 69 | + |
| 70 | +If you believe typex could be improved with the addition of extra functionality or features feel free to let us know. |
| 71 | +We cannot guarantee that we will include these features, but we will certainly take your suggestions into consideration. |
| 72 | +In order to increase your chances of having a feature included, be sure to be as clear and specific as possible as to the properties this |
| 73 | +feature should have. |
| 74 | + |
| 75 | +These issues should include the **enhancement** label. |
| 76 | + |
| 77 | +Pull Requests |
| 78 | +------------- |
| 79 | + |
| 80 | +If you would like to take a more active roll in the development of typex you can do so by submitting a "Pull request". |
| 81 | +A Pull Requests (PR) is a way by which a user can submit modifications or additions to the nidl package directly. |
| 82 | +PRs need to be reviewed by the package moderators and if accepted are merged into the master branch of the repository. |
| 83 | + |
| 84 | +Before making a PR, be sure to carefully read the following guidelines: |
| 85 | + |
| 86 | +* fork the repository from the GitHub interface, *i.e.* press the button on the top right with this |
| 87 | + symbol |fork_logo|. |
| 88 | + This will create an independent copy of the repository on your account. |
| 89 | +* code the new feature in your fork, ideally by creating a new branch. |
| 90 | +* make a pull request from the GitHub interface for this branch with a clear description of what has been done, why and what issues this relates to. |
| 91 | +* wait for feedback and update your code if requested. |
| 92 | + |
| 93 | +Content |
| 94 | +~~~~~~~ |
| 95 | + |
| 96 | +Every PR should correspond to a bug fix or new feature issue that has already been raised. |
| 97 | +When you make a PR be sure to tag the issue that it resolves (*e.g.* this PR relates to issue #1). |
| 98 | +This way the issue can be closed once the PR has been merged. |
| 99 | + |
| 100 | +The content of a given PR should be as concise as possible. |
| 101 | +To that end, aim to restrict modifications to those needed to resolve a single issue. |
| 102 | +Additional bug fixes or features should be made as separate PRs. |
| 103 | + |
| 104 | +CI Tests |
| 105 | +~~~~~~~~ |
| 106 | + |
| 107 | +Continuous Integration (CI) tests are implemented via GithHub workflows. |
| 108 | +All PRs must pass the CI tests before being merged. |
| 109 | +Your PR may not be reviewed by a moderator until all CI test are passed. |
| 110 | +Therefore, try to resolve any issues in your PR that may cause the tests to fail. |
| 111 | +In some cases it may be necessary to modify the unit tests, but this should be clearly justified in the PR description. |
| 112 | + |
| 113 | +Coverage |
| 114 | +~~~~~~~~ |
| 115 | + |
| 116 | +Coverage tests are implemented via `Coveralls <https://coveralls.io>`_. |
| 117 | +These tests will fail if the coverage, *i.e.* the number of lines of code covered by unit tests, decreases. |
| 118 | +When submitting new code in a PR, contributors should aim to write appropriate unit tests. |
| 119 | +If the coverage drops significantly moderators may request unit tests be added before the PR is merged. |
| 120 | + |
| 121 | +Style Guide |
| 122 | +~~~~~~~~~~~ |
| 123 | + |
| 124 | +All contributions should adhere to the following style guides currently implemented in typex: |
| 125 | + |
| 126 | +* all code should be compatible with the typex dependencies. |
| 127 | +* all code should adhere to `PEP8 <https://www.python.org/dev/peps/pep-0008>`_ standards. |
| 128 | +* docstrings need to be provided for all new modules, methods and classes. |
| 129 | + These should adhere to `numpydoc <https://numpydoc.readthedocs.io/en/latest/format.html>`_ standards. |
0 commit comments