| 1 | # Contributing to Athom and Homey
|
| 2 |
|
| 3 | First off all, thank you for taking the time to contribute!
|
| 4 |
|
| 5 | The following is a set of guidelines for contributing to Athom and its packages, which are hosted in the [Athom Organization](https://github.com/athombv) on GitHub. These are just guidelines, not rules. Use your best judgment, and feel free to contact us if you have any questions.
|
| 6 |
|
| 7 | Please join our [community slack](https://slack.athom.com), if you have not done so already.
|
| 8 | We also have a [forum](https://forum.athom.com) for general discussions.
|
| 9 |
|
| 10 |
|
| 11 | ## Before submitting a bug or feature request
|
| 12 |
|
| 13 | * **Have you actually read the error message**?
|
| 14 | * Have you searched for similar issues?
|
| 15 | * Have you updated homey, all apps, and the development tools (if applicable)?
|
| 16 | * Have you checked that it's not a problem with one of the apps you're using, rather than Homey itself?
|
| 17 | * Have you looked at what's involved in fixing/implementing this?
|
| 18 |
|
| 19 | Capable programmers should always attempt to investigate and fix problems themselves before asking for others to help. Submit a pull request instead of an issue!
|
| 20 |
|
| 21 | Regular support is provided through our [support staff](support@athom.com).
|
| 22 |
|
| 23 | ## A great bug report contains
|
| 24 |
|
| 25 | * Context – what were you trying to achieve?
|
| 26 | * Detailed steps to reproduce the error from scratch. Try isolating the minimal amount of code needed to reproduce the error.
|
| 27 | * Any applicable log files or ID's.
|
| 28 | * Evidence you've looked into solving the problem and ideally, a theory on the cause and a possible solution.
|
| 29 |
|
| 30 | ## A great feature request contains
|
| 31 |
|
| 32 | * The current situation.
|
| 33 | * How and why the current situation is problematic.
|
| 34 | * A detailed proposal or pull request that demonstrates how the problem could be solved.
|
| 35 | * A use case – who needs this feature and why?
|
| 36 | * Any caveats.
|
| 37 |
|
| 38 | ## A great pull request contains
|
| 39 |
|
| 40 | * Minimal changes. Only submit code relevant to the current issue. Other changes should go in new pull requests.
|
| 41 | * Minimal commits. Please squash to a single commit before sending your pull request.
|
| 42 | * No conflicts. Please rebase off the latest master before submitting.
|
| 43 | * Code conforming to the existing conventions and formats. i.e. Please don't reformat whitespace.
|
| 44 | * Passing tests in the test folder (if applicable). Use existing tests as a reference.
|
| 45 | * Relevant documentation.
|
| 46 |
|
| 47 | ## Speeding up your pull request
|
| 48 | Merging pull requests takes time. While we always try to merge your pull request as soon as possible, there are certain things you can do to speed up this process.
|
| 49 |
|
| 50 | * Ask developers to review your code changes and post their feedback.
|
| 51 | * Ask users to test your changes and post their feedback.
|
| 52 | * Keep your changes to the minimal required amount, and dedicated to one issue/feature only.
|
| 53 | * If your PR introduces new features or more than just a small fix, please sign our [Contributor License Agreement](https://go.athom.com/cla).
|