# Contributing :tada: Thank you for being interested in contributing to the Semaphore project! :tada: Feel welcome and read the following sections in order to know how to ask questions and how to work on something. All members of our community are expected to follow our [Code of Conduct](/CODE_OF_CONDUCT.md). Please make sure you are welcoming and friendly in all of our spaces. We're really glad you're reading this, because we need volunteer developers to help this project come to fruition. 👏 ## Issues The best way to contribute to our projects is by opening a [new issue](https://github.com/semaphore-protocol/semaphore/issues/new/choose) or tackling one of the issues listed [here](https://github.com/semaphore-protocol/semaphore/contribute). ## Pull Requests Pull requests are great if you want to add a feature or fix a bug. Here's a quick guide: 1. Fork the repo. 2. Run the tests. We only take pull requests with passing tests. 3. Add a test for your change. Only refactoring and documentation changes require no new tests. 4. Make sure to check out the [Style Guide](/CONTRIBUTING.md#style-guide) and ensure that your code complies with the rules. 5. Make the test pass. 6. Commit your changes. 7. Push to your fork and submit a pull request on our `main` branch. Please provide us with some explanation of why you made the changes you made. For new features make sure to explain a standard use case to us. > [!IMPORTANT] > We do not accept pull requests for minor grammatical fixes (e.g., correcting typos, rewording sentences) or for fixing broken links, unless they significantly improve clarity or functionality. These contributions, while appreciated, are not a priority for merging. If you notice any of these issues, please create a [GitHub Issue](https://github.com/semaphore-protocol/semaphore/issues/new?template=BLANK_ISSUE) to report them so they can be properly tracked and addressed. ## CI (Github Actions) Tests We use GitHub Actions to test each PR before it is merged. When you submit your PR (or later change that code), a CI build will automatically be kicked off. A note will be added to the PR, and will indicate the current status of the build. ## Style Guide ### Code rules We always use ESLint and Prettier. To check that your code follows the rules, simply run the npm script `yarn lint`. ### Commit rules For commits it is recommended to use [Conventional Commits](https://www.conventionalcommits.org). Don't worry if it looks complicated, in our repositories, `git commit` opens an interactive app to create your conventional commit. Each commit message consists of a **header**, a **body** and a **footer**. The **header** has a special format that includes a **type**, a **scope** and a **subject**: ():