Contributions are welcome. Here's a few housekeeping rules:
- opiniated repository: many things happen by convention. This includes commit messages (conventional-commit) and release management (semantic-release), as well as formatting (prettier, eslint and typescript rules). Not to forget that the build and development process is managed with
yarn
. - development cycle: as more people wish to contribute than just myself, I've created a
homebridge-dingz/next
branch. This is the main development branch, successful change integrations will trickle down from here to thealpha
,beta
and thenmaster
branches, triggering the respective semantic release. Submit your PR's against this branch. - testing:
homebridge
is notoriously difficult to work with with respect to tests. There's little possibility to add automated tests and so there are none. Nevertheless, please test the functionality of the plug-in as good as possible. Ideally, you work on devices and device integrations that you can reasonably test. This includes, but is not limited, to differentdingz
configurations like blinds, lights, buttons and their automations in HomeKit etc.
I've worked on this plug-in mostly alone for the past few years so please allow me to get used to working with others as the maintainer. It's a new role for me too.
Here's a good article describing the use of conventional commits and semantic-release. This repository aims to adhere to these rules as much as possible. Here's the gist of the commitlint config:
- Types:
build
,change
,chore
,ci
,deprecate
,docs
,feat
,fix
,perf
,refactor
,remove
,revert
,security
,style
,test
, - Scopes:
dev
,deps
,deps-dev
,github
,platform
,accessory
If you use the Conventional Commit extension for VSCode, you'll find normally find it picked the types and scopes up for you.
And last but not least: please be kind.