Thank you for considering contributing to Otter! We welcome all contributions, and appreciate your effort in improving our project. To ensure a smooth contribution process, please follow the guidelines below.
Please create a new issue on our repository and choose "Feature request". This will allow us to review and prioritize your request accordingly.
Before you submit an issue, please make sure the issue is not already in our issues backlog.
The issue creation template requires:
- a description of the failing use case
- the version of library where the issue occurs
- NodeJS version
- a fix suggestion, if possible
If you already have a fix for the problem don't hesitate to open a pull request. Each pull request should be assign to an issue, so please create the issue and link it to the PR.
When creating a pull request, please link the corresponding issue in the pull request description. This will help us track the progress of your contribution and ensure that it is reviewed in a timely manner.
In order to have a nice change log generated, you will need to follow some guidelines:
- For bugfix:
git commit -m "[fix|fixes|bugfix|bugfixes]: this is a commit message for a fix" - For feature:
git commit -m "[feat|feature|features]: this is a commit message for a feature" - For documentation: the commit message should contain the word
doc,docsordocumentation - For breaking change: the commit message should contain the word
breaking,breaking change,breaking changes,breaking-changeorbreaking-changes
Those are common examples, for more information don't hesitate to have a look at https://github.com/conventional-changelog/commitlint/#what-is-commitlint
When contributing, please keep in mind the following rules:
- Make only non-breaking changes in minor versions. Enhancements to existing code are possible - please discuss it beforehand with the Otter team via a feature request.
- If the new feature you are adding is replacing an existing one, please deprecate the old code in minor versions. Add the @deprecated tag in the JSDoc while mentioning the major version when it will be removed. Note that only even major Otter versions allow breaking changes. This means we only allow breaking changes in
n+2major versions. - Please ensure that you are submitting quality code, specifically make sure that the changes comply with our code styling convention.
- Always write description comments for methods and properties
- A description comment must use the pattern
/** [Your comment] */ - Linter tasks must pass
- Add relevant Unit Tests
- Any change should be followed by changes in the generator whenever it's applicable
- Properties should have the most restricted type possible
🚫
private type: string;
✅private type: "A" | "B";
To ease the process, we are providing a set of:
After submitting a pull request, you will receive feedback from the Otter team. The review process will continue until the pull request is ready to be merged.
As a reviewer, please follow these guidelines:
- When using the
Request changesoption, please include at least one comment with a specific change required. A question alone does not count as a change requirement. This option indicates that the reviewer is not in favor of merging the pull request until the requested changes are made. - When using the
Approved option, the reviewer may still include change requests if desired. This option indicates that the reviewer is in favor of merging the pull request as-is, but suggests that the author may wish to consider making some small changes. - Always stay polite and professional in your comments.
- The purpose of comments is to suggest improvements, ask a question or request for a change.
- Comments should be constructive and suggest ways to improve things.
Request changesoption should't be used if the comments consist only of questions.
Thanks in advance for your contribution, and we look forward to hearing from you :)