Broid is an open source project. Broid wouldn't be where it is now without contributions by the community. Please consider forking Broid to improve, enhance or fix issues. If you feel like the community will benefit from your fork, please open a pull request.
And because we want to do the better for you. Help us improving Broid by sharing your feedback on our Integrations GitHub Repo and let's build Broid together!
You are also welcome to correct any spelling mistakes or any language issues.
If you want to discuss something or just need help, here is our Gitter room.
Make sure that you're read and understand the Code of Conduct.
To protect the interests of the Broid contributors, Broid, customers and end users we require contributors to sign a Contributors License Agreement (CLA) before we pull the changes into the main repository. Our CLA is simple and straightforward - it requires that the contributions you make to any Broid open source project are properly licensed and that you have the legal authority to make those changes. This helps us significantly reduce future legal risk for everyone involved. It's easy---no faxing or printing required!
You can digitally sign the CLA online. Please indicate your email address in your first pull request so that we can make sure that will locate your CLA. Once you've submitted it, you no longer need to send one for subsequent submissions.
- automatic generating of the changelog
- simple navigation through git history (e.g. ignoring style changes)
<type>(<scope>): <subject>
<body>
<footer>
fix(slack): fix webhook endpoint
Updates the Slack webhook to match the updated API.
Fixes #4433
The first line cannot be longer than 70 characters, the second line is always blank and other lines should be wrapped at 80 characters. The type and scope should always be lowercase as shown below.
- feat (new feature for the user, not a new feature for build script)
- fix (bug fix for the user, not a fix to a build script)
- docs (changes to the documentation)
- style (formatting, missing semi colons, etc; no production code change)
- refactor (refactoring production code, eg. renaming a variable)
- test (adding missing tests, refactoring tests; no production code change)
- chore (updating grunt tasks etc; no production code change)
- discord
- schemas
- slack
The <scope>
can be empty (e.g. if the change is a global or difficult
to assign to a single component), in which case the parentheses are
omitted. In smaller projects such as Karma plugins, the <scope>
is empty.
- uses the imperative, present tense: “change” not “changed” nor “changes”
- includes motivation for the change and contrasts with previous behavior
For more info about message body, see:
- http://365git.tumblr.com/post/3308646748/writing-git-commit-messages
- http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
Closed issues should be listed on a separate line in the footer prefixed with "Closes" keyword like this:
Closes #234
or in the case of multiple issues:
Closes #123, #245, #992
All breaking changes have to be mentioned in footer with the description of the change, justification and migration notes.
BREAKING CHANGE:
`broid-slack` no longer supports method `getRouter` and will return null. Make sure to handle it appropriately.