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`
|