1 | # Contributing to Electron Forge
|
2 |
|
3 | Electron Forge is a community-driven project. As such, we welcome and encourage all sorts of
|
4 | contributions. They include, but are not limited to:
|
5 |
|
6 | * Constructive feedback
|
7 | * [Questions about usage](#questions-about-usage)
|
8 | * [Bug reports / technical issues](#before-opening-bug-reportstechnical-issues)
|
9 | * [Documentation changes](#documentation-changes)
|
10 | * Feature requests
|
11 | * [Pull requests](#filing-pull-requests)
|
12 |
|
13 | We strongly suggest that before filing an issue, you search through the existing issues to see
|
14 | if it has already been filed by someone else.
|
15 |
|
16 | This project is a part of the Electron ecosystem. As such, all contributions to this project follow
|
17 | [Electron's code of conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md)
|
18 | where appropriate.
|
19 |
|
20 | ## Questions about usage
|
21 |
|
22 | If you have questions about usage, we encourage you to visit one of the several [community-driven
|
23 | sites](https://github.com/electron/electron#community).
|
24 |
|
25 | ## Before opening bug reports/technical issues
|
26 |
|
27 | ### Debugging
|
28 |
|
29 | Troubleshooting suggestions can be found in the [support
|
30 | documentation](https://github.com/electron-userland/electron-forge/blob/master/SUPPORT.md#troubleshooting).
|
31 |
|
32 | ## Contribution suggestions
|
33 |
|
34 | We use the label [`help wanted`](https://github.com/electron-userland/electron-forge/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22)
|
35 | in the issue tracker to denote fairly-well-scoped-out bugs or feature requests that the community
|
36 | can pick up and work on. If any of those labeled issues do not have enough information, please feel
|
37 | free to ask constructive questions. (This applies to any open issue.)
|
38 |
|
39 | ## Documentation changes
|
40 |
|
41 | When changing the API documentation, here are some rules to keep in mind.
|
42 |
|
43 | * The first line:
|
44 | * should end with a period
|
45 | * should be in imperative mood (e.g., "Create" instead of "Creates")
|
46 | * First line should not be the function's "signature"
|
47 | * The first word of the first line:
|
48 | * should be properly capitalized
|
49 | * should not be "This"
|
50 |
|
51 | For changes to the website ([electronforge.io](https://electronforge.io)), please file
|
52 | issues/pull requests at [its separate repository](https://github.com/electron-forge/electronforge.io).
|
53 |
|
54 | ## Filing Pull Requests
|
55 |
|
56 | Here are some things to keep in mind as you file pull requests to fix bugs, add new features, etc.:
|
57 |
|
58 | * Travis CI is used to make sure that the project builds packages as expected on the supported
|
59 | platforms, using supported Node.js versions, and that the project conforms to the configured
|
60 | coding standards.
|
61 | * Unless it's impractical, please write tests for your changes. This will help us so that we can
|
62 | spot regressions much easier.
|
63 | * If your PR changes the behavior of an existing feature, or adds a new feature, please add/edit
|
64 | the package's documentation.
|
65 | * One of the philosophies of the project is to keep the code base as small as possible. If you are
|
66 | adding a new feature, think about whether it is appropriate to go into a separate Node module,
|
67 | and then be integrated into this project.
|
68 | * Please **do not** bump the version number in your pull requests, the maintainers will do that.
|
69 | Feel free to indicate whether the changes require a major, minor, or patch version bump, as
|
70 | prescribed by the [semantic versioning specification](http://semver.org/).
|
71 | * This project uses `git-cz` to generate commit messages. To make commits, please run
|
72 | `npm run commit`.
|
73 | * If you are continuing the work of another person's PR and need to rebase/squash, please retain the
|
74 | attribution of the original author(s) and continue the work in subsequent commits.
|
75 |
|
76 | ### Release process
|
77 |
|
78 | - if you aren't sure if a release should happen, open an issue
|
79 | - make sure the tests pass
|
80 | - `npm run release:(patch|minor|major)`
|
81 | - create a new GitHub release from the pushed tag with the contents of `CHANGELOG.md` for that version
|
82 | - close the milestone associated with the version if one is open
|