|
| 1 | +# Contributing |
| 2 | + |
| 3 | +## Getting Started |
| 4 | + |
| 5 | +* Make sure you have a [GitHub account](https://github.com/signup/free) |
| 6 | +* Submit a ticket for your issue, assuming one does not already exist. |
| 7 | + * Clearly describe the issue including steps to reproduce when it is a bug. |
| 8 | + * Make sure you fill in the earliest version that you know has the issue. |
| 9 | +* Fork the repository on GitHub |
| 10 | + |
| 11 | + |
| 12 | +## Making Changes |
| 13 | + |
| 14 | +* Create a topic branch from where you want to base your work. |
| 15 | + * This is usually the master branch. |
| 16 | + * Only target release branches if you are certain your fix must be on that |
| 17 | + branch. |
| 18 | + * To quickly create a topic branch based on master; `git checkout -b |
| 19 | + fix/master/my_contribution master`. Please avoid working directly on the |
| 20 | + `master` branch. |
| 21 | +* Make commits of logical units. |
| 22 | +* Check for unnecessary whitespace with `git diff --check` before committing. |
| 23 | +* Make sure your commit messages are in the proper format (see below) |
| 24 | +* Make sure you have added the necessary tests for your changes. |
| 25 | +* Run _all_ the tests to assure nothing else was accidentally broken. |
| 26 | + |
| 27 | +### Writing the commit message |
| 28 | + |
| 29 | +Commit messages should be clear and follow a few basic rules. Example: |
| 30 | + |
| 31 | +``` |
| 32 | +ENH: add functionality X to framework.<submodule>. |
| 33 | +
|
| 34 | +The first line of the commit message starts with a capitalized acronym |
| 35 | +(options listed below) indicating what type of commit this is. Then a blank |
| 36 | +line, then more text if needed. Lines shouldn't be longer than 72 |
| 37 | +characters. If the commit is related to a ticket, indicate that with |
| 38 | +"See #3456", "See ticket 3456", "Closes #3456" or similar. |
| 39 | +``` |
| 40 | + |
| 41 | +Describing the motivation for a change, the nature of a bug for bug fixes |
| 42 | +or some details on what an enhancement does are also good to include in a |
| 43 | +commit message. Messages should be understandable without looking at the code |
| 44 | +changes. |
| 45 | + |
| 46 | +Standard acronyms to start the commit message with are: |
| 47 | + |
| 48 | + |
| 49 | +|Code| Description | |
| 50 | +|----|----------------------------------------------------| |
| 51 | +|API | an (incompatible) API change | |
| 52 | +|BLD | change related to building | |
| 53 | +|BUG | bug fix | |
| 54 | +|DEP | deprecate something, or remove a deprecated object | |
| 55 | +|DEV | development tool or utility | |
| 56 | +|DOC | documentation | |
| 57 | +|ENH | enhancement | |
| 58 | +|MNT | maintenance commit (refactoring, typos, etc.) | |
| 59 | +|REV | revert an earlier commit | |
| 60 | +|STY | style fix (whitespace, PEP8) | |
| 61 | +|TST | addition or modification of tests | |
| 62 | +|REL | related to releasing numpy | |
| 63 | +|WIP | Commit that is a work in progress | |
| 64 | + |
| 65 | +## The Pull Request |
| 66 | + |
| 67 | +* Now push to your fork |
| 68 | +* Submit a [pull request](https://help.github.com/articles/using-pull-requests) to this branch. This is a start to the conversation. |
| 69 | + |
| 70 | +At this point you're waiting on us. We like to at least comment on pull requests within three business days |
| 71 | +(and, typically, one business day). We may suggest some changes or improvements or alternatives. |
| 72 | + |
| 73 | +Hints to make the integration of your changes easy (and happen faster): |
| 74 | +- Keep your pull requests small |
| 75 | +- Don't forget your unit tests |
| 76 | +- All algorithms need documentation, don't forget the .rst file |
| 77 | +- Don't take changes requests to change your code personally |
0 commit comments