|
| 1 | +# Contributing to Looker Components |
| 2 | + |
| 3 | +🎉 Before we dive in... Thank you for taking the time contribute! 🎉 |
| 4 | + |
| 5 | +The following is a set of guidelines for contributing to Looker Components and its family packages, which are hosted in the Looker Organization on GitHub. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request. |
| 6 | + |
| 7 | +## Code of Conduct |
| 8 | + |
| 9 | +This project and everyone participating in it is governed by the [Code of Conduct](CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code. |
| 10 | + |
| 11 | +## Developer Setup |
| 12 | + |
| 13 | +See our [README](README.md) for development setup instructions. |
| 14 | + |
| 15 | +### Bug Reports |
| 16 | + |
| 17 | +Bugs from the community are tracked in [Github Issues](https://github.com/looker-open-source/components/issues). |
| 18 | + |
| 19 | +- Use a clear and descriptive title for the issue |
| 20 | +- Note what version of the @looker/components package you're using |
| 21 | +- Describe how to reproduce the problem |
| 22 | + - Bonus points for a working example in [Code Sandbox](https://codesandbox.io) (our [sample template](https://codesandbox.io/s/looker-components-template-trhxc) may come in handy) |
| 23 | +- Explain the behavior your were expecting |
| 24 | +- Label your issue with "bug" |
| 25 | + |
| 26 | +## Enhancements Requests |
| 27 | + |
| 28 | +Enhancements Requests from the community are tracked in [Github Issues](https://github.com/looker-open-source/components/issues). |
| 29 | + |
| 30 | +- Use a clear and descriptive title for the issue |
| 31 | +- Describe what you want to be able to accomplish with Looker Components |
| 32 | +- Label your issue with "enhancement" |
| 33 | + |
| 34 | +## Pull Requests |
| 35 | + |
| 36 | +We're so excited that you're ready to make your first contribution! Go ahead and open a "New Pull Request" and you should see a sample "Developer Checklist" as well as a quick video on what we're looking for to help get your change accepted. |
| 37 | + |
| 38 | +### Title Guidelines |
| 39 | + |
| 40 | +We squash Pull Requests (all commits in a pull request show up in our `main` branch history as a single commit) and we use [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) to generate our CHANGELOG. |
| 41 | + |
| 42 | +So we use Conventional Commit style Pull Request titles: |
| 43 | + |
| 44 | +``` |
| 45 | +<type>[optional scope]: <description> |
| 46 | +``` |
| 47 | + |
| 48 | +#### Types |
| 49 | + |
| 50 | +We generally follow [Angular's types](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#type). The most common types used are: |
| 51 | + |
| 52 | +- fix: a commit of the type fix patches a bug (this correlates with PATCH in Semantic Versioning). |
| 53 | +- feat: a commit of the type feat introduces a new feature or changes and existing one (this correlates with MINOR in Semantic Versioning). |
| 54 | + |
| 55 | +If a change does _NOT_ make a change to the build artifacts produced (`fix` or `feat` above) you can also use on of these alternative types: |
| 56 | + |
| 57 | +- build: Changes that affect the build system or external dependencies |
| 58 | +- docs: Documentation only changes |
| 59 | +- refactor: A code change that neither fixes a bug nor adds a feature |
| 60 | +- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) |
| 61 | +- test: Adding missing tests or correcting existing tests |
| 62 | + |
| 63 | +#### Scope |
| 64 | + |
| 65 | +Specify a scope when your change is focused on a specific component or portion of the code. E.g.: |
| 66 | + |
| 67 | +``` |
| 68 | +feat(Button): Now supports even more colors 🌈 |
| 69 | +``` |
| 70 | + |
| 71 | +### Developer Checklist |
| 72 | + |
| 73 | +Edit the developer checklist to reflect only items relevant to your pull request (delete items that aren't relevant). Feel free to reach out if you have questions or get stuck. |
| 74 | + |
| 75 | +Not sure if an item applies? Leave it in place and ask your reviewer to help determine if it's relevant. |
| 76 | + |
| 77 | +- [ ] ♿️ Accessibility addressed |
| 78 | +- [ ] 🌏 Localization & Internationalization addressed |
| 79 | +- [ ] 🖼 Image Snapshot coverage |
| 80 | +- [ ] Documentation updated 📚 |
| 81 | +- [ ] Bundle size impact addressed 🧳 |
| 82 | +- [ ] Performance impacts addressed 🚤 |
| 83 | +- [ ] Cross-browser tested 👾 |
| 84 | + - [ ] Chrome |
| 85 | + - [ ] Firefox |
| 86 | + - [ ] Safari |
| 87 | + - [ ] IE11 |
| 88 | + |
| 89 | +#### What does "addressed" mean? |
| 90 | + |
| 91 | +If your pull request introduces a regression to the item (or simply leaves that task for a later PR if the component in question isn't already marked as "stable") please document that a follow-up issue has been logged to address that item as technical debt. |
0 commit comments