General Contributing Guidelines
The Material Components contributing policies and procedures can be found in the main Material Components documentation repository’s contributing page.
The iOS team also abides by the following policy items:
MDC follows certain coding styles and conventions for its code to help everyone easily read, review, and understand our code. Please follow these conventions when submitting pull requests.
All components should pass these checks or give a compelling reason why they shouldn’t.
There is a great script that checks for some of these criteria. Run it regularly during development. It will also be run by the continuous integration system when you make a pull request. If the script fails at that point, the pull request will be blocked.
Issue and Pull Request Titles
Start the title with
[ComponentName] to identify which component a change affects. Use
[ComponentName|OtherComponentName] for commits affecting multiple components, which should be rare.
[FooBar] Removes the deprecated fooWithBar:(Bar*)bar method.
Pull request continuous integration for new contributors
All other pull requests must be labeled with
kokoro:force-run by a member of the repo
with write access in order for continuous integration to be initiated. This label must
be added again each time the pull request has new commits pushed to it.
For Googlers: b/115490922 is tracking making the above work more streamlined for new contributors.
Using assignee to indicate who should action on a PR
Since PRs on github permanently stay in the
Changes requested state it is hard to tell when the author has addressed the concerns. By change the assignee to whomever still needs to action (review or modify/justify) we can more easily keep track of what needs attention in our PR queues.
- For a reviewer this means adding the author as an assignee once the review is finished.
- For an author it means adding back the reviewer (and removing themselves) as an assignee.
See deprecation_policy.md for details.
Finding an issue to work on
MDC-iOS uses GitHub to file and track issues. To find an issue to work on, filter the issues list by the “is:fixit” label.
If you’re new to iOS development and have a computer running OS X, these steps should help you get all the prerequisites. More experienced users may just need to see the last steps.
- We assume you already have installed on you mac
- To see your work within the catalog
pod install --project-directory=catalog/
- Navigate to the component you want to work on in Pods -> Development Pods -> Material Components -> <#component>.
- Run the
MDCDragonstarget to see the full set of examples.
- Tests can also be run from the Product menu.
- To send us a change make a Pull Requests from your own fork.
The small print
Contributions made by corporations are covered by a different agreement than the one above, the Software Grant and Corporate Contributor License Agreement.