Material Components is an open source project that accepts contributions from community members.
Want to contribute? Great! First, read this page (including the small print).
If you’ve never contributed to an open source project before, take a look at GitHub’s Contributing to Open Source on GitHub to learn some of the basics.
The Material Components authors value respect and are committed to making the repos and communication channels a safe space for all peoples.
To learn more about what to expect from us and what we expect from you, read the Code of Conduct.
Ask them on Stack Overflow and tag them with material-components and the platform (android, ios, web.)
If you find a bug in the source code or a mistake in the documentation, you can help us by submitting an issue to the GitHub repository for that platform.
Even better: propose a fix with a pull request and link it to the issue!
To learn how to request new components or changes to the UX of an existing component, read Components Request Policy.
You can request new features that do not change the UX on an existing component by submitting an issue to the GitHub repository for that platform.
The best way to make an impact is by creating code submissions called pull requests. Pull requests should be ‘solutions’ to GitHub issues.
To make a pull request:
- Make sure there’s a GitHub issue for the change you’re proposing.
- Fork the repo for the platform your code works in.
- Write code on a branch in your fork.
- Create a pull request to merge your branch’s contributions into the corresponding MDC repo.
- The pull request will be triaged by a core team member and code reviewed by the community.
- If the pull request is accepted, the accepting core team member will merge the pull request for you.
MDC follows certain coding styles and conventions. See the CONTRIBUTING files in the platform specific repos for more information.
Regardless of language or platform, all code goes through code review before it can be merged into main branches.
Pull requests can be hard to review if they try to tackle too many things at once. Phabricator's "Writing Reviewable Code" provides a set of guidelines that help increase the likelihood of your pull request getting merged.
In short (slightly modified from the original article):
- A pull request should be as small as possible, but no smaller.
- The smallest a pull request can be is a single cohesive idea: don't make pull requests so small that they are meaningless on their own.
- Turn large pull requests into small pull requests by dividing large problems into smaller problems and solving the small problems one at a time.
- Write sensible pull request descriptions.
Our additions:
- A pull request should affect as few components as possible.
Members of the core team are Google employees responsible for the strategic direction of Material Components and appointment of technical leaders from the community. The core team will work with the community to accept contributions in line with Material Design guidelines.
Please sign our Contributor License Agreement (CLA) before sending pull requests.
For any code changes to be accepted, the CLA must be signed. It's a quick process, we promise!
- For individuals we have a simple click-through form.
- For corporations we'll need you to sign a different agreement.
Contributions made by corporations are covered by a different agreement than the one above, the Software Grant and Corporate Contributor License Agreement.
- Filing an Issue
- Components Request Policy
- Code of Conduct
- Stack Overflow (external site)
- Material.io (external site)
- Material Design Guidelines (external site)