|
| 1 | +# Welcome to the Blink Labs contributing guide <!-- omit in toc --> |
| 2 | + |
| 3 | +Thank you for investing your time in contributing to our project! |
| 4 | + |
| 5 | +Read our [Code of Conduct](./CODE_OF_CONDUCT.md) to keep our community |
| 6 | +approachable and respectable. |
| 7 | + |
| 8 | +In this guide you will get an overview of the contribution workflow from |
| 9 | +opening an issue, creating a PR, reviewing, and merging the PR. |
| 10 | + |
| 11 | +## Getting started |
| 12 | + |
| 13 | +To get an overview of the project, read the [README](README.md). Here are some |
| 14 | +resources to help you get started with open source contributions: |
| 15 | + |
| 16 | +- [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) |
| 17 | + |
| 18 | +Blink Labs repositories use Conventional Commits for all commits. This defines |
| 19 | +a standard format for commit messages across repositories and projects. |
| 20 | + |
| 21 | +- [CODEOWNERS](CODEOWNERS) |
| 22 | + |
| 23 | +Blink Labs repositories use CODEOWNERS files to provide information on who |
| 24 | +should review a contribution. For repositories with regular outside |
| 25 | +contributors, they will be listed within this file in the repository or |
| 26 | +repositories which they maintain. |
| 27 | + |
| 28 | +<br> |
| 29 | + |
| 30 | +Contributions to open source come in many forms. You can contribute to Blink |
| 31 | +Labs projects in several ways. |
| 32 | + |
| 33 | +### Issues |
| 34 | + |
| 35 | +#### Create a new issue |
| 36 | + |
| 37 | +If you spot a problem with a project, search if an issue already exists. If a |
| 38 | +related issue doesn't exist, you can open a new issue in the repository. |
| 39 | + |
| 40 | +#### Solve an issue |
| 41 | + |
| 42 | +Scan through our existing issues to find one that interests you. You can narrow |
| 43 | +down the search using `labels` as filters. As a general rule, we don’t assign |
| 44 | +issues to anyone. If you find an issue to work on, you are welcome to open a PR |
| 45 | +with a fix. |
| 46 | + |
| 47 | +### Pull Request |
| 48 | + |
| 49 | +When you're finished with the changes, create a pull request, also known as a |
| 50 | +PR. |
| 51 | +- Don't forget to |
| 52 | +[link PR to issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) |
| 53 | +if you are solving one. |
| 54 | +- Enable the checkbox to |
| 55 | +[allow maintainer edits](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/allowing-changes-to-a-pull-request-branch-created-from-a-fork) |
| 56 | +so the branch can be updated for a merge. |
| 57 | +Once you submit your PR, a Docs team member will review your proposal. We may |
| 58 | +ask questions or request additional information. |
| 59 | +- We may ask for changes to be made before a PR can be merged, either using |
| 60 | +[suggested changes](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/incorporating-feedback-in-your-pull-request) |
| 61 | +or pull request comments. You can apply suggested changes directly through the |
| 62 | +UI. You can make any other changes in your fork, then commit them to your |
| 63 | +branch. |
0 commit comments