Skip to content

Latest commit

 

History

History
executable file
·
53 lines (37 loc) · 2.8 KB

CONTRIBUTING.md

File metadata and controls

executable file
·
53 lines (37 loc) · 2.8 KB
Raw

Contributing to Athom and Homey

First off all, thank you for taking the time to contribute!

The following is a set of guidelines for contributing to Athom and its packages, which are hosted in the Athom Organization on GitHub. These are just guidelines, not rules. Use your best judgment, and feel free to contact us if you have any questions.

Please join our community slack, if you have not done so already. We also have a forum for general discussions.

Before submitting a bug or feature request

  • Have you actually read the error message?
  • Have you searched for similar issues?
  • Have you updated homey, all apps, and the development tools (if applicable)?
  • Have you checked that it's not a problem with one of the apps you're using, rather than Homey itself?
  • Have you looked at what's involved in fixing/implementing this?

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!

Regular support is provided through our support staff.

A great bug report contains

  • Context – what were you trying to achieve?
  • Detailed steps to reproduce the error from scratch. Try isolating the minimal amount of code needed to reproduce the error.
  • Any applicable log files or ID's.
  • Evidence you've looked into solving the problem and ideally, a theory on the cause and a possible solution.

A great feature request contains

  • The current situation.
  • How and why the current situation is problematic.
  • A detailed proposal or pull request that demonstrates how the problem could be solved.
  • A use case – who needs this feature and why?
  • Any caveats.

A great pull request contains

  • Minimal changes. Only submit code relevant to the current issue. Other changes should go in new pull requests.
  • Minimal commits. Please squash to a single commit before sending your pull request.
  • No conflicts. Please rebase off the latest master before submitting.
  • Code conforming to the existing conventions and formats. i.e. Please don't reformat whitespace.
  • Passing tests in the test folder (if applicable). Use existing tests as a reference.
  • Relevant documentation.

Speeding up your pull request

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.

  • Ask developers to review your code changes and post their feedback.
  • Ask users to test your changes and post their feedback.
  • Keep your changes to the minimal required amount, and dedicated to one issue/feature only.
  • If your PR introduces new features or more than just a small fix, please sign our Contributor License Agreement.