|
| 1 | +# Contributing to Material Design Components for Angular |
| 2 | + |
| 3 | + - [Code of Conduct](#coc) |
| 4 | + - [Issues and Bugs](#issue) |
| 5 | + - [Submission Guidelines](#submit) |
| 6 | + - [Coding Rules](#rules) |
| 7 | + - [Commit Message Guidelines](#commit) |
| 8 | + - [Signing the CLA](#cla) |
| 9 | + |
| 10 | +## <a name="coc"></a> Code of Conduct |
| 11 | +Help us keep Angular open and inclusive. Please read and follow our [Code of Conduct][coc]. |
| 12 | + |
| 13 | +## <a name="issue"></a> Found an Issue? |
| 14 | +If you find a bug in the source code or a mistake in the documentation, you can help us by |
| 15 | +submitting an issue to our [GitHub Repository][github]. Even better you can submit a Pull Request |
| 16 | +with a fix. |
| 17 | + |
| 18 | +* **Small Changes** can be crafted and submitted to [GitHub Repository][github] as a Pull Request. |
| 19 | + |
| 20 | +## <a name="submit"></a>Submission Guidelines |
| 21 | + |
| 22 | +We're still in early development but we look forward to welcoming community contributions soon. |
1 | 23 |
|
2 | 24 | ### Javascript Conventions |
3 | 25 |
|
|
6 | 28 | - Use the 'revealing pattern' when possible. API at top, function definitions at bottom. See src/components/checkbox/checkbox.js |
7 | 29 | - JSHint conventions in progress |
8 | 30 |
|
| 31 | + |
9 | 32 | ### Testing Conventions |
10 | 33 |
|
11 | 34 | - For testing, use `beforeEach` loops and global variables as little as possible. |
|
15 | 38 | * Create a `setup(attrs)` function which takes attributes to put on the directive |
16 | 39 | * The `setup` function should register the module for the test and return the compiled directive element. |
17 | 40 | * Use `el.scope()` and `el.isolateScope()` to access the element's scope. |
| 41 | + |
| 42 | + |
| 43 | +## <a name="commit"></a> Git Commit Guidelines |
| 44 | + |
| 45 | +We have very precise rules over how our git commit messages can be formatted. This leads to **more |
| 46 | +readable messages** that are easy to follow when looking through the **project history**. But also, |
| 47 | +we use the git commit messages to **generate the AngularDart change log**. |
| 48 | + |
| 49 | +### Commit Message Format |
| 50 | +Each commit message consists of a **header**, a **body** and a **footer**. The header has a special |
| 51 | +format that includes a **type**, a **scope** and a **subject**: |
| 52 | + |
| 53 | +``` |
| 54 | +<type>(<scope>): <subject> |
| 55 | +<BLANK LINE> |
| 56 | +<body> |
| 57 | +<BLANK LINE> |
| 58 | +<footer> |
| 59 | +``` |
| 60 | + |
| 61 | +Any line of the commit message cannot be longer 100 characters! This allows the message to be easier |
| 62 | +to read on github as well as in various git tools. |
| 63 | + |
| 64 | +### Type |
| 65 | +Must be one of the following: |
| 66 | + |
| 67 | +* **feat**: A new feature |
| 68 | +* **fix**: A bug fix |
| 69 | +* **docs**: Documentation only changes |
| 70 | +* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing |
| 71 | + semi-colons, etc) |
| 72 | +* **refactor**: A code change that neither fixes a bug or adds a feature |
| 73 | +* **perf**: A code change that improves performance |
| 74 | +* **test**: Adding missing tests |
| 75 | +* **chore**: Changes to the build process or auxiliary tools and libraries such as documentation |
| 76 | + generation |
| 77 | + |
| 78 | +### Scope |
| 79 | +The scope could be anything specifying place of the commit change. For example `$location`, |
| 80 | +`$browser`, `$compile`, `$rootScope`, `ngHref`, `ngClick`, `ngView`, etc... |
| 81 | + |
| 82 | +### Subject |
| 83 | +The subject contains succinct description of the change: |
| 84 | + |
| 85 | +* use the imperative, present tense: "change" not "changed" nor "changes" |
| 86 | +* don't capitalize first letter |
| 87 | +* no dot (.) at the end |
| 88 | + |
| 89 | +###Body |
| 90 | +Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes" |
| 91 | +The body should include the motivation for the change and contrast this with previous behavior. |
| 92 | + |
| 93 | +###Footer |
| 94 | +The footer should contain any information about **Breaking Changes** and is also the place to |
| 95 | +reference GitHub issues that this commit **Closes**. |
| 96 | + |
| 97 | + |
| 98 | +A detailed explanation can be found in this [document][commit-message-format]. |
| 99 | + |
| 100 | +## <a name="cla"></a> Signing the CLA |
| 101 | + |
| 102 | +Please sign our Contributor License Agreement (CLA) before sending pull requests. For any code |
| 103 | +changes to be accepted, the CLA must be signed. It's a quick process, we promise! |
| 104 | + |
| 105 | +* For individuals we have a [simple click-through form][individual-cla]. |
| 106 | +* For corporations we'll need you to |
| 107 | + [print, sign and one of scan+email, fax or mail the form][corporate-cla]. |
| 108 | + |
| 109 | + |
| 110 | +[coc]: https://github.com/angular/code-of-conduct/blob/master/CODE_OF_CONDUCT.md |
| 111 | +[commit-message-format]: https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit# |
| 112 | +[communityMilestone]: https://github.com/angular/angular.dart/issues?milestone=13&state=open |
| 113 | +[corporate-cla]: http://code.google.com/legal/corporate-cla-v1.0.html |
| 114 | +[dart-style-guide]: https://www.dartlang.org/articles/idiomatic-dart/ |
| 115 | +[github]: https://github.com/angular/material |
| 116 | +[individual-cla]: http://code.google.com/legal/individual-cla-v1.0.html |
0 commit comments