| 1 | # Contributing
|
| 2 |
|
| 3 | We love pull requests. Here's a quick guide:
|
| 4 |
|
| 5 | 1. Check for [existing issues](https://github.com/github/brobbot/issues) for duplicates and confirm that it hasn't been fixed already in the [master branch](https://github.com/github/brobbot/commits/master)
|
| 6 | 2. Fork the repo, and clone it locally
|
| 7 | 3. `npm link` to make your cloned repo available to npm
|
| 8 | 4. Follow [Getting Started](docs/README.md) to generate a testbot (no automated tests yet :sob:)
|
| 9 | 5. `npm link brobbot` in your newly created bot to use your brobbot fork
|
| 10 | 6. Create a new branch for your contribution
|
| 11 | 7. Push to your fork and submit a pull request
|
| 12 |
|
| 13 | At this point you're waiting on us. We like to at least comment on, if not
|
| 14 | accept, pull requests within a few days. We may suggest some changes or improvements or alternatives.
|
| 15 |
|
| 16 | Some things that will increase the chance that your pull request is accepted:
|
| 17 |
|
| 18 | * Use CoffeeScript [idioms](http://arcturo.github.io/library/coffeescript/04_idioms.html) and [style guide](https://github.com/polarmobile/coffeescript-style-guide)
|
| 19 | * Update the documentation: code comments, example code, guides. Basically,
|
| 20 | update anything is affected by your contribution.
|
| 21 | * Include any information that would be relevant to reproducing bugs, use cases for new features, etc.
|
| 22 |
|
| 23 | * Discuss the impact on existing [brobbot installs](docs/README.md), [brobbot adapters](docs/adapters.md), and [brobbot scripts](docs/scripting.md) (e.g. backwards compatibility)
|
| 24 | * If the change does break compatibility, how can it be updated to become backwards compatible, while directing users to the new way of doing things?
|
| 25 | * Your commits are associated with your GitHub user: https://help.github.com/articles/why-are-my-commits-linked-to-the-wrong-user/
|
| 26 | * Make pull requests against a feature branch,
|
| 27 | * Don't update the version in `package.json`, as the maintainers will manage that in a follow-up PR to release
|
| 28 |
|
| 29 | Syntax:
|
| 30 |
|
| 31 | * Two spaces, no tabs.
|
| 32 | * No trailing whitespace. Blank lines should not have any space.
|
| 33 | * Prefer `and` and `or` over `&&` and `||`
|
| 34 | * Prefer single quotes over double quotes unless interpolating strings.
|
| 35 | * `MyClass.myMethod(my_arg)` not `myMethod( my_arg )` or `myMethod my_arg`.
|
| 36 | * `a = b` and not `a=b`.
|
| 37 | * Follow the conventions you see used in the source already.
|
| 38 |
|
| 39 | # Releasing
|
| 40 |
|
| 41 | This section is for maintainers of brobbot. Here's the current process for releasing:
|
| 42 |
|
| 43 | * create a `release-vX.X.X` branch to release off of
|
| 44 | * determine what version to release as:
|
| 45 | * bug fix? patch release
|
| 46 | * new functionality that is backwards compatible? minor version
|
| 47 | * breaking change? major release, but think about if it can be fixed to be a minor release instead
|
| 48 | * update `package.json`
|
| 49 | * summarize changes in `CHANGELOG.md`
|
| 50 | * create a pull request, and cc pull requests included in this release, as well as their contributors
|
| 51 | * merge pull request
|
| 52 | * checkout master branch, and run `script/release`
|