|
| 1 | +Contributing code to hydrogen-web |
| 2 | +================================== |
| 3 | + |
| 4 | +Everyone is welcome to contribute code to hydrogen-web, provided that they are |
| 5 | +willing to license their contributions under the same license as the project |
| 6 | +itself. We follow a simple 'inbound=outbound' model for contributions: the act |
| 7 | +of submitting an 'inbound' contribution means that the contributor agrees to |
| 8 | +license the code under the same terms as the project's overall 'outbound' |
| 9 | +license - in this case, Apache Software License v2 (see |
| 10 | +[LICENSE](LICENSE)). |
| 11 | + |
| 12 | +How to contribute |
| 13 | +----------------- |
| 14 | + |
| 15 | +The preferred and easiest way to contribute changes to the project is to fork |
| 16 | +it on github, and then create a pull request to ask us to pull your changes |
| 17 | +into our repo (https://help.github.com/articles/using-pull-requests/) |
| 18 | + |
| 19 | +We use GitHub's pull request workflow to review the contribution, and either |
| 20 | +ask you to make any refinements needed or merge it and make them ourselves. |
| 21 | + |
| 22 | +Things that should go into your PR description: |
| 23 | + * References to any bugs fixed by the change (in GitHub's `Fixes` notation) |
| 24 | + * Describe the why and what is changing in the PR description so it's easy for |
| 25 | + onlookers and reviewers to onboard and context switch. |
| 26 | + * If your PR makes visual changes, include both **before** and **after** screenshots |
| 27 | + to easily compare and discuss what's changing. |
| 28 | + * Include a step-by-step testing strategy so that a reviewer can check out the |
| 29 | + code locally and easily get to the point of testing your change. |
| 30 | + * Add comments to the diff for the reviewer that might help them to understand |
| 31 | + why the change is necessary or how they might better understand and review it. |
| 32 | + |
| 33 | +We use continuous integration, and all pull requests get automatically tested: |
| 34 | +if your change breaks the build, then the PR will show that there are failed |
| 35 | +checks, so please check back after a few minutes. |
| 36 | + |
| 37 | +Tests |
| 38 | +----- |
| 39 | +If your PR is a feature then we require that the PR also includes tests. |
| 40 | +These need to test that your feature works as expected and ideally test edge cases too. |
| 41 | + |
| 42 | +Tests are written as unit tests by exporting a `tests` function from the file to be tested. |
| 43 | +The function returns an object where the key is the test label, and the value is a |
| 44 | +function that accepts an [assert](https://nodejs.org/api/assert.html) object, and return a Promise or nothing. |
| 45 | + |
| 46 | +Note that there is currently a limitation that files that are not indirectly included from `src/platform/web/main.js` won't be found by the runner. |
| 47 | + |
| 48 | +You can run the tests by running `yarn test`. |
| 49 | +This uses the [impunity](https://github.com/bwindels/impunity) runner. |
| 50 | + |
| 51 | +We don't require tests for bug fixes. |
| 52 | + |
| 53 | +In the future we may formalise this more. |
| 54 | + |
| 55 | +Code style |
| 56 | +---------- |
| 57 | +The js-sdk aims to target TypeScript/ES6. All new files should be written in |
| 58 | +TypeScript and existing files should use ES6 principles where possible. |
| 59 | + |
| 60 | +Please disable any automatic formatting tools you may have active. |
| 61 | +If present, you'll be asked to undo any unrelated whitespace changes during code review. |
| 62 | + |
| 63 | +Members should not be exported as a default export in general. |
| 64 | +In general, avoid using `export default`. |
| 65 | + |
| 66 | +The remaining code-style for hydrogen is [in the process of being documented](codestyle.md), but |
| 67 | +contributors are encouraged to read the |
| 68 | +[code style document for matrix-react-sdk](https://github.com/matrix-org/matrix-react-sdk/blob/master/code_style.md) |
| 69 | +and follow the principles set out there. |
| 70 | + |
| 71 | +Please ensure your changes match the cosmetic style of the existing project, |
| 72 | +and ***never*** mix cosmetic and functional changes in the same commit, as it |
| 73 | +makes it horribly hard to review otherwise. |
| 74 | + |
| 75 | +Attribution |
| 76 | +----------- |
| 77 | +If you change or create a file, feel free to add yourself to the copyright holders |
| 78 | +in the license header of that file. |
| 79 | + |
| 80 | +Sign off |
| 81 | +-------- |
| 82 | +In order to have a concrete record that your contribution is intentional |
| 83 | +and you agree to license it under the same terms as the project's license, we've |
| 84 | +adopted the same lightweight approach that the Linux Kernel |
| 85 | +(https://www.kernel.org/doc/Documentation/SubmittingPatches), Docker |
| 86 | +(https://github.com/docker/docker/blob/master/CONTRIBUTING.md), and many other |
| 87 | +projects use: the DCO (Developer Certificate of Origin: |
| 88 | +http://developercertificate.org/). This is a simple declaration that you wrote |
| 89 | +the contribution or otherwise have the right to contribute it to Matrix: |
| 90 | + |
| 91 | +``` |
| 92 | +Developer Certificate of Origin |
| 93 | +Version 1.1 |
| 94 | +
|
| 95 | +Copyright (C) 2004, 2006 The Linux Foundation and its contributors. |
| 96 | +660 York Street, Suite 102, |
| 97 | +San Francisco, CA 94110 USA |
| 98 | +
|
| 99 | +Everyone is permitted to copy and distribute verbatim copies of this |
| 100 | +license document, but changing it is not allowed. |
| 101 | +
|
| 102 | +Developer's Certificate of Origin 1.1 |
| 103 | +
|
| 104 | +By making a contribution to this project, I certify that: |
| 105 | +
|
| 106 | +(a) The contribution was created in whole or in part by me and I |
| 107 | + have the right to submit it under the open source license |
| 108 | + indicated in the file; or |
| 109 | +
|
| 110 | +(b) The contribution is based upon previous work that, to the best |
| 111 | + of my knowledge, is covered under an appropriate open source |
| 112 | + license and I have the right under that license to submit that |
| 113 | + work with modifications, whether created in whole or in part |
| 114 | + by me, under the same open source license (unless I am |
| 115 | + permitted to submit under a different license), as indicated |
| 116 | + in the file; or |
| 117 | +
|
| 118 | +(c) The contribution was provided directly to me by some other |
| 119 | + person who certified (a), (b) or (c) and I have not modified |
| 120 | + it. |
| 121 | +
|
| 122 | +(d) I understand and agree that this project and the contribution |
| 123 | + are public and that a record of the contribution (including all |
| 124 | + personal information I submit with it, including my sign-off) is |
| 125 | + maintained indefinitely and may be redistributed consistent with |
| 126 | + this project or the open source license(s) involved. |
| 127 | +``` |
| 128 | + |
| 129 | +If you agree to this for your contribution, then all that's needed is to |
| 130 | +include the line in your commit or pull request comment: |
| 131 | + |
| 132 | +``` |
| 133 | +Signed-off-by: Your Name <your@email.example.org> |
| 134 | +``` |
| 135 | + |
| 136 | +We accept contributions under a legally identifiable name, such as your name on |
| 137 | +government documentation or common-law names (names claimed by legitimate usage |
| 138 | +or repute). Unfortunately, we cannot accept anonymous contributions at this |
| 139 | +time. |
| 140 | + |
| 141 | +Git allows you to add this signoff automatically when using the `-s` flag to |
| 142 | +`git commit`, which uses the name and email set in your `user.name` and |
| 143 | +`user.email` git configs. |
| 144 | + |
| 145 | +If you forgot to sign off your commits before making your pull request and are |
| 146 | +on Git 2.17+ you can mass signoff using rebase: |
| 147 | + |
| 148 | +``` |
| 149 | +git rebase --signoff origin/develop |
| 150 | +``` |
0 commit comments