You are more than welcome to contribute to sse-r-plugin! Follow these guidelines and you will be ready to start:
Please read and follow our Code of conduct.
Bugs can be reported by adding issues in the repository. Submit your bug fix by creating a Pull Request, following the GIT guidelines.
Features can be requested by adding issues in the repository. If the feature includes new designs or bigger changes, please be prepared to discuss the changes with us so we can cooperate on how to best include them.
Submit your feature by creating a Pull Request, following the GIT guidelines. Include any related documentation changes.
Documentation changes can be requested by adding issues in the repository.
Submit your documentation changes by creating a Pull Request, following the GIT guidelines. If the change is minor, you can submit a Pull Request directly without creating an issue first.
Generally, development should be done directly towards the master
branch.
1. Fork and clone the repository
git clone [email protected]:YOUR-USERNAME/sse-r-plugin.git
2. Create a branch in the fork
The branch should be based on the master
branch in the master repository.
git checkout -b my-feature-or-bugfix master
3. Commit changes on your branch
Commit changes to your branch, following the commit message format.
git commit -m "Fix outKey being sent in all requests."
4. Push the changes to your fork
git push -u myfork my-feature-or-bugfix
5. Create a Pull Request
Before creating a Pull Request, make sure the following items are satisfied:
- CircleCI is green (OBS!! This does not work with SSE yet right?)
- Commit message format is followed
- CLA is signed
In the Github UI of your fork, create a Pull Request to the master
branch of the master repository.
If the branch has merge conflicts or has been outdated, please do a rebase against the master
branch.
WARNING: Squashing or reverting commits and force-pushing thereafter may remove GitHub comments on code that were previously made by you or others in your commits. Avoid any form of rebasing unless necessary.
There are currently no conventions on how to format commit messages. We'd like you to follow some rules on the content however:
- Use the present form, e.g. Add schema file for Qlik Sense 3.x
- Be descriptive and avoid messages like Minor fix.
- If the change is breaking an API, add a [breaking] tag in the message.
Some examples of good commit messages:
- Fix outKey being sent in all requests.
- Bump after-work.js to 0.12.9
- Rename communication module to registry
We need you to sign our Contributor License Agreement (CLA) before we can accept your Pull Request. Visit this link for more information: https://github.com/qlik-oss/open-source/blob/master/sign-cla.md.