**Note: in order for some tests to work, you will need to place a [`monerod`](https://www.getmonero.org/downloads/) binary at the root of the repository.**
Some labels will be [automatically added/removed](https://github.com/Cuprate/cuprate/tree/main/.github/labeler.yml) if certain file paths have been changed in a PR.
The following section explains the meaning of various labels used.
This section is primarily targeted at maintainers. Most contributors aren't able to set these labels.
| [C-] | The **category** of an issue. | `C-cleanup`, `C-optimization`
| [D-] | Issues for **diagnostics**. | `D-confusing`, `D-verbose`
| [E-] | The **experience** level necessary to fix an issue. | `E-easy`, `E-hard`
| [I-] | The **importance** of the issue. | `I-crash`, `I-memory`
| [O-] | The **operating system** or platform that the issue is specific to. | `O-windows`, `O-macos`, `O-linux`
| [P-] | The issue **priority**. These labels can be assigned by anyone that understand the issue and is able to prioritize it, and remove the [I-prioritize] label. | `P-high`, `P-low`
If you are working on a larger effort, consider opening a [tracking issue](https://github.com/Cuprate/cuprate/issues/new/choose)!
The main purpose of these are to track efforts that may contain multiple PRs and/or are generally spread out. These don't usually contain the "why", but if they do, they are brief. These contain no implementation details or the how, as those are for the issues/PRs that are being tracked.
Examples:
- https://github.com/Cuprate/cuprate/issues/187
- https://github.com/Cuprate/cuprate/issues/183
## 4. Coding guidelines
These are some rules that are not mandated by any automation, but contributors generally follow.
### 4.1 General guidelines
General guidelines you should keep these in mind when submitting code:
- Separate and sort imports as `core`, `std`, `third-party`, Cuprate crates, current crate
- Follow the [Rust API Guidelines](https://rust-lang.github.io/api-guidelines)
-`// Comment like this.` and not `//like this`
- Use `TODO` instead of `FIXME`
- Avoid `unsafe`
And the most important rule:
- Break any and all of the above rules when it makes sense
### 4.2 Crate names
All of Cuprate's crates (libraries) are prefixed with `cuprate-`. All directories containing crates however, are not.
For example:
| Crate Directory | Crate Name |
|--------------------|--------------------|
| `storage/database` | `cuprate-database` |
| `net/levin` | `cuprate-levin` |
| `net/wire` | `cuprate-wire` |
### 4.3 Pull request title and description
In general, pull request titles should follow this syntax:
```
<AREA>: <SHORT_DESCRIPTION>
```
For example:
```
books: fix typo
```
The description of pull requests should generally follow the template laid out in [`.github/pull_request_template.md`](.github/pull_request_template.md).
If your pull request is long and/or has sections that need clarifying, consider leaving a review on your own PR with comments explaining the changes.
Documentation can be built and viewed using the `cargo` tool. For example, to build and view a specific crate's documentation, run the following command at the repository's root:
`$CRATE` can be any package listed in the [root `Cargo.toml`](https://github.com/Cuprate/cuprate/tree/main/Cargo.toml)'s workspace members list, for example, `cuprate-blockchain`.
You can also build all documentation at once:
```bash
cargo doc
```
and view by using a web-browser to open the `index.html` file within the build directory: `target/doc/$CRATE/index.html`, for example, `target/doc/cuprate_blockchain/index.html`.
Cuprate has various documentation books whose source files live in [`books/`](https://github.com/Cuprate/cuprate/tree/main/books).
Please contribute if you found a mistake! The files are mostly [markdown](https://wikipedia.org/wiki/Markdown) files and can be easily edited. See the `books/` directory for more information.
