This page provides some general guidelines for contriubting to the Swellaby Generator.
First make sure that the issue has not already been reported. If you find that your issue has already been reported, you can subscribe to that issue so that you will be notified of updates. If you'd like to vote on an existing issue, use the reaction/emoji features. Please do not leave random "+1" or "I have this too" comments, as they don't help resolve the issue. The being said, if you have additional information or suggestions feel free to post that.
Click the below links to create a new issue:
Be sure to scrub any sensetive information if you include logs
If you found a bug or typo feel free to open a pull request with a fix. For any significant contribution, please open an issue before working on it.
Pull requests will need to pass a number of automated gates before being considered for approval. After the automated gates pass, the pull request will be reviewed by one or more core callaborators before being merged.
Swellaby members should create a branch within the repository, make changes there, and then submit a PR.
Outside contributors should fork the repository, make changes in the fork, and then submit a PR.
We are not commit message police but here are a few guidelines:
- Use clear and precise language
- Try to stick to under 50 characters
- Stick to the what/why not the how
Here is a good reference if you are unsure about what a good commit message should look like.
Rules will be enforced by precommit hooks, automated gates, and core callaborator reviews.
The rules:
- Test coverage will not dip below 100%
- All code must pass the tslint rules defined here
- All code must pass the eslint rules defined here
- Inline linter exceptions or rule changes can be requested in the relevant pull request
- Documentation should be updated to reflect new features being add and/or behaviour changes