Every contribution to Grafana's software begins with a [pull request](https://help.github.com/en/articles/about-pull-requests/). This document guides you through the process of creating a PR.
If this is your first time contributing to an open-source project on GitHub, make sure you read GitHub's article on [creating a pull request](https://help.github.com/en/articles/creating-a-pull-request).
- Use the `actionCreatorFactory` and `reducerFactory` helpers instead of traditional switch statement reducers in Redux. Refer to [Redux framework](/contribute/style-guides/redux.md) for more details.
- Use `reducerTester` to test reducers. Refer to [Redux framework](/contribute/style-guides/redux.md) for more details.
- Don't add snapshots tests. We are incrementally removing existing snapshot tests, and so we don't want more.
- If an existing unit test is written in Enzyme, migrate it to React Testing Library (RTL), unless you’re fixing a bug. Bug fixes usually shouldn't include any bigger refactoring, so it’s okay to skip migrating the test to RTL.
Pull requests that create new UI components or modify existing ones must adhere to the following accessibility guidelines:
- Use semantic HTML.
- Use ARIA roles, labels and other accessibility attributes correctly. Accessibility attributes should only be used when semantic HTML doesn't satisfy your use case.
- Use the [Grafana theme palette](/contribute/style-guides/themes.md) for styling. The palette contains colors with good contrast to aid accessibility.
Before submitting pull requests that introduce accessibility (a11y) errors, refer to the [accessibility guidelines](/contribute/style-guides/accessibility.md).
We make use of a tool called [**Betterer**](https://phenomnomnominal.github.io/betterer/) in order to drive long-running code quality improvements. Our intention is for this requirement to be as unintrusive as possible; however, there are some things to be aware of:
- You may get an error when trying to commit something that decreases the overall code quality. You can either fix these errors or temporarily override the checks (for example, to commit something that's a work in progress). To do so, use `git commit --no-verify`. All errors will eventually have to be fixed before your code can be merged because...
- You may see the following error message in the CI: `Unexpected changes detected in these tests while running in CI mode`. To resolve the error, merge with the target branch (usually `main`).
- You may see merge conflicts for the `.betterer.results` file. To resolve, merge with the target branch (usually `main`), and then run `yarn betterer:merge` and commit.
Once you've created a pull request, the next step is to have someone review your change. A review is a learning opportunity for both the reviewer and the author of the pull request.
If you think a specific person needs to review your pull request, then you can tag them in the description or in a comment. To tag a user on GitHub, go to Reviewers box on the Conversations page and enter the `@` symbol followed by their GitHub username.
A well-written pull request minimizes the time to get your change accepted. The following guidelines help you to write good commit messages and descriptions for your pull requests.
Grafana uses the guidelines for commit messages outlined in the article [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/), with the following additions:
The Grafana team _squashes_ all commits into one when we accept a pull request. The title of the pull request becomes the subject line of the squashed commit message. We still encourage contributors to write informative commit messages, as they become a part of the Git commit body.
