# Submission guidelines
# Report a bug
Before creating an issue please make sure you have checked out the docs, you might want to also try searching Github. It's pretty likely someone has already asked a similar question.
Issues can be reported in the issue tracker (opens new window).
# Pull Requests
We love pull requests and we're continually working to make it as easy as possible for people to contribute.
We prefer small pull requests with minimal code changes. The smaller they are the easier they are to review and merge. A core team member will pick up your PR and review it as soon as they can. They may ask for changes or reject your pull request. This is not a reflection of you as an engineer or a person. Please accept feedback graciously as we will also try to be sensitive when providing it.
Although we generally accept many PRs they can be rejected for many reasons. We will be as transparent as possible but it may simply be that you do not have the same context or information regarding the roadmap that the core team members have. We value the time you take to put together any contributions so we pledge to always be respectful of that time and will try to be as open as possible so that you don't waste it.
# Commit message guidelines
We follow the Conventional commits specifications (opens new window) which provides a set of rules to make commit messages more readable when looking through the project history. But also, we use the git commit messages to generate the change log.
# Commit message format
The commit message should be structured as follows:
<type>: <subject> [optional `breaking`]
type must be one of the following:
build: changes that affect the build system (external dependencies)
ci: changes to our CI configuration files and scripts
chore: changes that affect the project structure
docs: changes that affect the documentation only
feat: a new feature
fix: a bug fix
perf: a code change that improves performance
refactor: a code change that neither fixes a bug nor adds a feature
revert: revert changes
style: changes that do not affect the meaning of the code (lint issues)
test: adding missing tests or correcting existing tests
Use the optional
[ breaking ] keyword to declare a BREAKING CHANGE.
- Commit message with description and breaking change in body
feat: allow provided config object to extend other configs [ breaking ] (closes #12)
- Commit message with no body
docs: correct spelling in the contributing.md file
- Commit message for a fix using an issue number.
fix: fix minor issue in code (closes #12)
# Versioning guidelines
We rely on Semantic Versioning (opens new window) for versioning a release. Indeed, given a version number
MAJOR.MINOR.PATCH, increment the:
MAJORversion when you make a major evolution leading to breaking changes,
MINORversion when you add functionality in a backwards-compatible manner
PATCHversion when you make backwards-compatible bug fixes.
yarn release:<type>, where
<type> is either
major, helps you to do the release.
It performs the following task for you:
- increase the package version number in the
- generate the change log
- create a tag accordingly in the git repository and push it
Please refer to the Publish your app guide to learn more about the way to publish the modules and the applications
# Contributor Code of Conduct
As contributors and maintainers of this project, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.
We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, or religion.
Examples of unacceptable behavior by participants include the use of sexual language or imagery, derogatory comments or personal attacks, trolling, public or private harassment, insults, or other unprofessional conduct.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. Project maintainers who do not follow the Code of Conduct may be removed from the project team.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by opening an issue or contacting one or more of the project maintainers.
This Code of Conduct is adapted from the Contributor Covenant (opens new window), version 1.0.0, available at http://contributor-covenant.org/version/1/0/0/ (opens new window)