1# Contributing to Crypto
  2
  3#### First off, thanks for taking the time to contribute!
  4
  5We want to make contributing to this project as easy and transparent as possible, whether it's:
  6
  7- Reporting a [bug](https://github.com/0xPolygonMiden/crypto/issues/new)
  8- Taking part in [discussions](https://github.com/0xPolygonMiden/crypto/discussions)
  9- Submitting a [fix](https://github.com/0xPolygonMiden/crypto/pulls)
 10- Proposing new [features](https://github.com/0xPolygonMiden/crypto/issues/new)
 11
 12 
 13
 14## Flow
 15We are using [Github Flow](https://docs.github.com/en/get-started/quickstart/github-flow), so all code changes happen through pull requests from a [forked repo](https://docs.github.com/en/get-started/quickstart/fork-a-repo).
 16
 17### Branching
 18- The current active branch is `next`. Every branch with a fix/feature must be forked from `next`.
 19
 20- The branch name should contain a short issue/feature description separated with hyphens [(kebab-case)](https://en.wikipedia.org/wiki/Letter_case#Kebab_case).
 21
 22    For example, if the issue title is `Fix functionality X in component Y` then the branch name will be something like: `fix-x-in-y`.
 23
 24- New branch should be rebased from `next` before submitting a PR in case there have been changes to avoid merge commits.
 25i.e. this branches state:
 26  ```
 27          A---B---C fix-x-in-y
 28         /
 29    D---E---F---G next
 30            |   |
 31         (F, G) changes happened after `fix-x-in-y` forked
 32  ```
 33
 34  should become this after rebase:
 35
 36
 37  ```
 38                  A'--B'--C' fix-x-in-y
 39                 /
 40    D---E---F---G next
 41  ```
 42
 43
 44  More about rebase [here](https://git-scm.com/docs/git-rebase) and [here](https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase#:~:text=What%20is%20git%20rebase%3F,of%20a%20feature%20branching%20workflow.)
 45
 46
 47### Commit messages
 48- Commit messages should be written in a short, descriptive manner and be prefixed with tags for the change type and scope (if possible) according to the [semantic commit](https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716) scheme.
 49For example, a new change to the AIR crate might have the following message: `feat(air): add constraints for the decoder`
 50
 51- Also squash commits to logically separated, distinguishable stages to keep git log clean:
 52    ```
 53    7hgf8978g9... Added A to X \
 54                                \  (squash)
 55    gh354354gh... oops, typo --- * ---------> 9fh1f51gh7... feat(X): add A && B
 56                                /
 57    85493g2458... Added B to X /
 58
 59
 60    789fdfffdf... Fixed D in Y \
 61                                \  (squash)
 62    787g8fgf78... blah  blah --- * ---------> 4070df6f00... fix(Y): fixed D && C
 63                                /
 64    9080gf6567... Fixed C in Y /
 65    ```
 66
 67### Code Style and Documentation
 68- For documentation in the codebase, we follow the [rustdoc](https://doc.rust-lang.org/rust-by-example/meta/doc.html) convention with no more than 100 characters per line.
 69- For code sections, we use code separators like the following to a width of 100 characters::
 70    ```
 71    // CODE SECTION HEADER
 72    // ================================================================================
 73    ```
 74
 75- [Rustfmt](https://github.com/rust-lang/rustfmt) and [Clippy](https://github.com/rust-lang/rust-clippy) linting is included in CI pipeline. Anyways it's prefferable to run linting locally before push:
 76    ```
 77    cargo fix --allow-staged --allow-dirty --all-targets --all-features; cargo fmt; cargo clippy --workspace --all-targets --all-features -- -D warnings
 78    ```
 79
 80### Versioning
 81We use [semver](https://semver.org/) naming convention.
 82
 83 
 84
 85## Pre-PR checklist
 861. Repo forked and branch created from `next` according to the naming convention.
 872. Commit messages and code style follow conventions.
 883. Tests added for new functionality.
 894. Documentation/comments updated for all changes according to our documentation convention.
 905. Clippy and Rustfmt linting passed.
 916. New branch rebased from `next`.
 92
 93 
 94
 95## Write bug reports with detail, background, and sample code
 96
 97**Great Bug Reports** tend to have:
 98
 99- A quick summary and/or background
100- Steps to reproduce
101- What you expected would happen
102- What actually happens
103- Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
104
105 
106
107## Any contributions you make will be under the MIT Software License
108In short, when you submit code changes, your submissions are understood to be under the same [MIT License](http://choosealicense.com/licenses/mit/) that covers the project. Feel free to contact the maintainers if that's a concern.