Contributing to Ionic | Ionic Framework

Thanks for the interest in contributing to Ionic Framework!
Please refer to the Contributor Code of Conduct for information on the rules of conduct.
If you have a question about using the framework, please ask on the Ionic Forum.
It is required that you clearly describe the steps necessary to reproduce the issue you are running into. Although we would love to help our users as much as possible, diagnosing issues without clear reproduction steps is extremely time-consuming and simply not sustainable.
The issue list of the Ionic repository is exclusively for bug reports and feature requests. Non-conforming issues will be closed immediately.
Issues with no clear steps to reproduce will not be triaged. If an issue is labeled with "needs: reply" and receives no further replies from the author of the issue for more than 14 days, it will be closed.
If you think you have found a bug, or have a new feature idea, please start by making sure it hasn't already been reported. You can search through existing issues to check if there is a similar one reported. Include closed issues as it may have been closed with a solution.
Next, create a new issue that thoroughly explains the problem. Please fill out the populated issue form before submitting the issue.
A code reproduction is a small application that is built to demonstrate a particular issue. The code reproduction should contain the minimum amount of code needed to recreate the issue and should focus on a single issue.
A code reproduction of the issue you are experiencing helps us better isolate the cause of the problem. This is an important first step to getting any bug fixed!
Without a reliable code reproduction, it is unlikely we will be able to resolve the issue, leading to it being closed. In other words, creating a code reproduction of the issue helps us help you.
We appreciate you taking the time to contribute! Before submitting a pull request, we ask that you please create an issue that explains the bug or feature request and let us know that you plan on creating a pull request for it. If an issue already exists, please comment on that issue letting us know you would like to submit a pull request for it. This helps us to keep track of the pull request and make sure there isn't duplicated effort.
Looking for an issue to fix? Make sure to look through our issues with the help wanted label!
We have very precise rules over how our git commit messages should be formatted. This leads to readable messages that are easy to follow when looking through the project history. We also use the git commit messages to generate our changelog. Our format closely resembles Angular's commit message guidelines.
We follow the Conventional Commits specification. A commit message consists of a header, body and footer. The header has a type, scope and subject:
The header is mandatory and the scope of the header is optional.
If the commit reverts a previous commit, it should begin with revert: , followed by the header of the reverted commit. In the body it should say: This reverts commit <hash>., where the hash is the SHA of the commit being reverted.
If the prefix is feat, fix or perf, it will appear in the changelog. However if there is any BREAKING CHANGE, the commit will always appear in the changelog.
Must be one of the following:
The scope can be anything specifying place of the commit change. Usually it will refer to a component but it can also refer to a utility. For example action-sheet, button, css, menu, nav, etc. If you make multiple commits for the same component, please keep the naming of this component consistent. For example, if you make a change to navigation and the first commit is fix(nav), you should continue to use nav for any more commits related to navigation. As a general rule, if you're modifying a component use the name of the folder.
The subject contains succinct description of the change:
Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.
The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.
Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this.
Does not appear in the generated changelog:
Appears under "Features" header, toast subheader:
Appears under "Bug Fixes" header, skeleton-text subheader, with a link to issue #28:
Appears under "Performance Improvements" header, and under "Breaking Changes" with the breaking change explanation:
Appears under "Breaking Changes" with the breaking change explanation:
The following commit and commit 667ecc1 do not appear in the changelog if they are under the same release. If not, the revert commit appears under the "Reverts" header.
By contributing your code to the ionic-team/ionic GitHub Repository, you agree to license your contribution under the MIT license.