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).
|