| 1 | # Contributing Guide
|
| 2 |
|
| 3 | You will need:
|
| 4 |
|
| 5 | - Node.js/io.js & npm
|
| 6 | - Bower
|
| 7 | - Gulp
|
| 8 |
|
| 9 |
|
| 10 | ## Getting started
|
| 11 |
|
| 12 | 1. Fork the project
|
| 13 | 2. Clone your forked project by running `git clone git@github.com:{
|
| 14 | YOUR_USERNAME }/tether.git`
|
| 15 | 3. Run `npm install` to install both node modules and bower components
|
| 16 | 4. Test that you can build the source by moving/renaming the existing `dist`
|
| 17 | directory and running `npm run build`
|
| 18 | 5. Assuming everything went well, you should now have a `dist` directory that
|
| 19 | matches the one you moved in step 4
|
| 20 |
|
| 21 |
|
| 22 | ## Writing code!
|
| 23 |
|
| 24 | We use `gulp` to facilitate things like transpilation, minification, etc. so
|
| 25 | can you focus on writing relevant code. If there is a fix or feature you would like
|
| 26 | to contribute, we ask that you take the following steps:
|
| 27 |
|
| 28 | 1. Most of the _editable_ code lives in the `src` directory while built code
|
| 29 | will end up in the `dist` directory upon running `npm run build`.
|
| 30 |
|
| 31 | 2. Depending on how big your changes are, bump the version numbers appropriately
|
| 32 | in `bower.json` and `package.json`. We try to follow semver, so a good rule
|
| 33 | of thumb for how to bump the version is:
|
| 34 | - A fix to existing code, perform a patch bump e.g. x.x.0 -> x.x.1
|
| 35 | - New feature, perform a minor bump e.g. x.0.x -> x.1.x
|
| 36 | - Breaking changes such a rewrite, perform a major bump e.g.
|
| 37 | 1.x.x -> 2.x.x
|
| 38 |
|
| 39 | Versioning is hard, so just use good judgement and we'll be more than happy
|
| 40 | to help out.
|
| 41 |
|
| 42 | __NOTE__: There is a `gulp` task that will automate some of the versioning.
|
| 43 | You can run `gulp version:{type}` where type is `patch|minor|major` to
|
| 44 | update both `bower.json` and `package.json` as well as add the appropriate
|
| 45 | git tag.
|
| 46 |
|
| 47 | 3. Provide a thoughtful commit message and push your changes to your fork using
|
| 48 | `git push origin master` (assuming your forked project is using `origin` for
|
| 49 | the remote name and you are on the `master` branch).
|
| 50 |
|
| 51 | 4. Open a Pull Request on GitHub with a description of your changes.
|
| 52 |
|
| 53 |
|
| 54 | ## Testing
|
| 55 |
|
| 56 | Work in progress. We are hoping to add some tests, so if you would like to help
|
| 57 | us get started, feel free to contact us through the Issues or open a Pull
|
| 58 | Request.
|
| 59 |
|