|
| 1 | +# Contributing to openHAB |
| 2 | + |
| 3 | +Want to hack on openHAB? Awesome! Here are instructions to get you |
| 4 | +started. They are probably not perfect, please let us know if anything |
| 5 | +feels wrong or incomplete. |
| 6 | + |
| 7 | +## Reporting Issues |
| 8 | + |
| 9 | +Please report [openHAB2 specific issues here](https://github.com/openhab/openhab2/issues), while issues that are related to the core framework should be reported in the [bugzilla of Eclipse SmartHome](https://bugs.eclipse.org/bugs/buglist.cgi?product=SmartHome&component=Core). |
| 10 | +Do not worry, if you are not clear, which category your issue belongs to - we will redirect you, if necessary. |
| 11 | + |
| 12 | +## Build Environment |
| 13 | + |
| 14 | +For instructions on setting up your development environment, please |
| 15 | +see our dedicated [IDE setup guide](https://github.com/openhab/openhab/wiki/IDE-Setup). |
| 16 | + |
| 17 | +## Contribution guidelines |
| 18 | + |
| 19 | +### Pull requests are always welcome |
| 20 | + |
| 21 | +We are always thrilled to receive pull requests, and do our best to |
| 22 | +process them as fast as possible. Not sure if that typo is worth a pull |
| 23 | +request? Do it! We will appreciate it. |
| 24 | + |
| 25 | +If your pull request is not accepted on the first try, don't be |
| 26 | +discouraged! If there's a problem with the implementation, hopefully you |
| 27 | +received feedback on what to improve. |
| 28 | + |
| 29 | +We're trying very hard to keep openHAB lean and focused. We don't want it |
| 30 | +to do everything for everybody. This means that we might decide against |
| 31 | +incorporating a new feature. However, there might be a way to implement |
| 32 | +that feature *on top of* openHAB. |
| 33 | + |
| 34 | +### Discuss your design on the mailing list |
| 35 | + |
| 36 | +We recommend discussing your plans [on the mailing |
| 37 | +list](https://groups.google.com/group/openhab) |
| 38 | +before starting to code - especially for more ambitious contributions. |
| 39 | +This gives other contributors a chance to point you in the right |
| 40 | +direction, give feedback on your design, and maybe point out if someone |
| 41 | +else is working on the same thing. |
| 42 | + |
| 43 | +### Create issues... |
| 44 | + |
| 45 | +Any significant improvement should be documented as [a GitHub |
| 46 | +issue](https://github.com/openhab/openhab2/issues) before anybody |
| 47 | +starts working on it. |
| 48 | + |
| 49 | +### ...but check for existing issues first! |
| 50 | + |
| 51 | +Please take a moment to check that an issue doesn't already exist |
| 52 | +documenting your bug report or improvement proposal. If it does, it |
| 53 | +never hurts to add a quick "+1" or "I have this problem too". This will |
| 54 | +help prioritize the most common problems and requests. |
| 55 | + |
| 56 | +### Conventions |
| 57 | + |
| 58 | +Fork the repo and make changes on your fork in a feature branch: |
| 59 | + |
| 60 | +- If it's a bugfix branch, name it XXX-something where XXX is the number of the |
| 61 | + issue |
| 62 | +- If it's a feature branch, create an enhancement issue to announce your |
| 63 | + intentions, and name it XXX-something where XXX is the number of the issue. |
| 64 | + |
| 65 | +Submit unit tests for your changes. openHAB has a great test framework built in; use |
| 66 | +it! Take a look at existing tests for inspiration. Run the full test suite on |
| 67 | +your branch before submitting a pull request. |
| 68 | + |
| 69 | +Update the documentation when creating or modifying features. Test |
| 70 | +your documentation changes for clarity, concision, and correctness, as |
| 71 | +well as a clean documentation build. |
| 72 | + |
| 73 | +Write clean code. Universally formatted code promotes ease of writing, reading, |
| 74 | +and maintenance. |
| 75 | + |
| 76 | +Pull requests descriptions should be as clear as possible and include a |
| 77 | +reference to all the issues that they address. |
| 78 | + |
| 79 | +Pull requests must not contain commits from other users or branches. |
| 80 | + |
| 81 | +Commit messages must start with a capitalized and short summary (max. 50 |
| 82 | +chars) written in the imperative, followed by an optional, more detailed |
| 83 | +explanatory text which is separated from the summary by an empty line. |
| 84 | + |
| 85 | +Code review comments may be added to your pull request. Discuss, then make the |
| 86 | +suggested modifications and push additional commits to your feature branch. Be |
| 87 | +sure to post a comment after pushing. The new commits will show up in the pull |
| 88 | +request automatically, but the reviewers will not be notified unless you |
| 89 | +comment. |
| 90 | + |
| 91 | +Before the pull request is merged, make sure that you squash your commits into |
| 92 | +logical units of work using `git rebase -i` and `git push -f`. After every |
| 93 | +commit the test suite should be passing. Include documentation changes in the |
| 94 | +same commit so that a revert would remove all traces of the feature or fix. |
| 95 | + |
| 96 | +Commits that fix or close an issue should include a reference like `Closes #XXX` |
| 97 | +or `Fixes #XXX`, which will automatically close the issue when merged. |
| 98 | + |
| 99 | +Add your name to the AUTHORS file, but make sure the list is sorted and your |
| 100 | +name and email address match your git configuration. The AUTHORS file is |
| 101 | +regenerated occasionally from the git commit history, so a mismatch may result |
| 102 | +in your changes being overwritten. |
| 103 | + |
| 104 | +### Sign your work |
| 105 | + |
| 106 | +The sign-off is a simple line at the end of the explanation for the |
| 107 | +patch, which certifies that you wrote it or otherwise have the right to |
| 108 | +pass it on as an open-source patch. The rules are pretty simple: if you |
| 109 | +can certify the below (from |
| 110 | +[developercertificate.org](http://developercertificate.org/)): |
| 111 | + |
| 112 | +``` |
| 113 | +Developer Certificate of Origin |
| 114 | +Version 1.1 |
| 115 | +
|
| 116 | +Copyright (C) 2004, 2006 The Linux Foundation and its contributors. |
| 117 | +660 York Street, Suite 102, |
| 118 | +San Francisco, CA 94110 USA |
| 119 | +
|
| 120 | +Everyone is permitted to copy and distribute verbatim copies of this |
| 121 | +license document, but changing it is not allowed. |
| 122 | +
|
| 123 | +
|
| 124 | +Developer's Certificate of Origin 1.1 |
| 125 | +
|
| 126 | +By making a contribution to this project, I certify that: |
| 127 | +
|
| 128 | +(a) The contribution was created in whole or in part by me and I |
| 129 | + have the right to submit it under the open source license |
| 130 | + indicated in the file; or |
| 131 | +
|
| 132 | +(b) The contribution is based upon previous work that, to the best |
| 133 | + of my knowledge, is covered under an appropriate open source |
| 134 | + license and I have the right under that license to submit that |
| 135 | + work with modifications, whether created in whole or in part |
| 136 | + by me, under the same open source license (unless I am |
| 137 | + permitted to submit under a different license), as indicated |
| 138 | + in the file; or |
| 139 | +
|
| 140 | +(c) The contribution was provided directly to me by some other |
| 141 | + person who certified (a), (b) or (c) and I have not modified |
| 142 | + it. |
| 143 | +
|
| 144 | +(d) I understand and agree that this project and the contribution |
| 145 | + are public and that a record of the contribution (including all |
| 146 | + personal information I submit with it, including my sign-off) is |
| 147 | + maintained indefinitely and may be redistributed consistent with |
| 148 | + this project or the open source license(s) involved. |
| 149 | +``` |
| 150 | + |
| 151 | +then you just add a line to every git commit message: |
| 152 | + |
| 153 | + Signed-off-by: Joe Smith <[email protected]> (github: github_handle) |
| 154 | + |
| 155 | +using your real name (sorry, no pseudonyms or anonymous contributions.) |
| 156 | + |
| 157 | +One way to automate this, is customise your get ``commit.template`` by adding |
| 158 | +a ``prepare-commit-msg`` hook to your openHAB checkout: |
| 159 | + |
| 160 | +``` |
| 161 | +curl -o .git/hooks/prepare-commit-msg https://raw.github.com/openhab/openhab2/master/contrib/prepare-commit-msg.hook && chmod +x .git/hooks/prepare-commit-msg |
| 162 | +``` |
| 163 | + |
| 164 | +* Note: the above script expects to find your GitHub user name in ``git config --get github.user`` |
| 165 | + |
| 166 | +#### Small patch exception |
| 167 | + |
| 168 | +There are several exceptions to the signing requirement. Currently these are: |
| 169 | + |
| 170 | +* Your patch fixes spelling or grammar errors. |
| 171 | +* Your patch is a single line change to documentation. |
| 172 | + |
| 173 | +### How can I become a maintainer? |
| 174 | + |
| 175 | +* Step 1: learn the component inside out |
| 176 | +* Step 2: make yourself useful by contributing code, bugfixes, support etc. |
| 177 | +* Step 3: volunteer on the discussion group (https://groups.google.com/group/openhab) |
| 178 | + |
| 179 | +Don't forget: being a maintainer is a time investment. Make sure you will have time to make yourself available. |
| 180 | +You don't have to be a maintainer to make a difference on the project! |
0 commit comments