Skip to content
This repository was archived by the owner on Mar 8, 2025. It is now read-only.

Improved CONTRIBUTING.md for better clarity #20

Open
wants to merge 8 commits into
base: develop
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
210 changes: 85 additions & 125 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,191 +2,151 @@

## What to Contribute

Welcome to the Optimism Monorepo Contributing Guide!
If you're reading this then you might be interested in contributing to the Optimism Monorepo.
Before diving into the specifics of this repository, you might be interested in taking a quick look at just a few of the ways that you can contribute.
You can:
Welcome to the **Optimism Monorepo Contributing Guide**! If you're reading this, you might be interested in contributing to the **Optimism Monorepo**. Before diving into the specifics of this repository, take a moment to explore some of the different ways you can contribute:

- Report issues in this repository. Great bug reports are detailed and give clear instructions for how a developer can reproduce the problem. Write good bug reports and developers will love you.
- **IMPORTANT**: If you believe your report impacts the security of this repository, refer to the canonical [Security Policy](https://github.com/ethereum-optimism/.github/blob/master/SECURITY.md) document.
- Fix issues that are tagged as [`D-good-first-issue`](https://github.com/ethereum-optimism/optimism/labels/D-good-first-issue) or [`S-confirmed`](https://github.com/ethereum-optimism/optimism/labels/S-confirmed).
- Help improve the [Optimism Developer Docs](https://github.com/ethereum-optimism/docs) by reporting issues, fixing typos, or adding missing sections.
- Get involved in the protocol design process by joining discussions within the [OP Stack Specs](https://github.com/ethereum-optimism/specs/discussions) repository.
- **Report issues**: A great bug report is detailed and provides clear steps for reproducing the issue. Developers will appreciate well-written reports!
- **IMPORTANT**: If you believe your report impacts the security of this repository, refer to the official **Security Policy** document.
- **Fix issues**: Look for issues tagged with `D-good-first-issue` or `S-confirmed`.
- **Improve documentation**: Help enhance the **Optimism Developer Docs** by fixing typos, adding missing sections, or improving explanations.
- **Engage in protocol design discussions**: Join the conversations within the **OP Stack Specs** repository.

## Code of Conduct

Interactions within this repository are subject to a [Code of Conduct](https://github.com/ethereum-optimism/.github/blob/master/CODE_OF_CONDUCT.md) adapted from the [Contributor Covenant](https://www.contributor-covenant.org/version/1/4/code-of-conduct/).
All interactions within this repository are subject to a **Code of Conduct** adapted from the **Contributor Covenant**.

## Development Quick Start

### Software Dependencies

| Dependency | Version | Version Check Command |
| ------------------------------------------------------------- | -------- | ------------------------ |
| [git](https://git-scm.com/) | `^2` | `git --version` |
| [go](https://go.dev/) | `^1.21` | `go version` |
| [node](https://nodejs.org/en/) | `^20` | `node --version` |
| [nvm](https://github.com/nvm-sh/nvm) | `^0.39` | `nvm --version` |
| [just](https://github.com/casey/just) | `^1.34.0`| `just --version` |
| [foundry](https://github.com/foundry-rs/foundry#installation) | `^0.2.0` | `forge --version` |
| [make](https://linux.die.net/man/1/make) | `^3` | `make --version` |
| [jq](https://github.com/jqlang/jq) | `^1.6` | `jq --version` |
| [direnv](https://direnv.net) | `^2` | `direnv --version` |
| [docker](https://docs.docker.com/get-docker/) | `^24` | `docker --version` |
| [docker compose](https://docs.docker.com/compose/install/) | `^2.23` | `docker compose version` |
| Dependency | Version | Version Check Command |
|-------------------|---------|---------------------------|
| `git` | ^2 | `git --version` |
| `go` | ^1.21 | `go version` |
| `node` | ^20 | `node --version` |
| `nvm` | ^0.39 | `nvm --version` |
| `just` | ^1.34.0 | `just --version` |
| `foundry` | ^0.2.0 | `forge --version` |
| `make` | ^3 | `make --version` |
| `jq` | ^1.6 | `jq --version` |
| `direnv` | ^2 | `direnv --version` |
| `docker` | ^24 | `docker --version` |
| `docker compose` | ^2.23 | `docker compose version` |

### Notes on Specific Dependencies

#### `node`
#### Node.js
Make sure to use the version specified in `.nvmrc`. You can use **nvm** to manage multiple versions of Node.js and automatically switch to the correct version when working on this repository.

Make sure to use the version of `node` specified within [`.nvmrc`](./.nvmrc).
You can use [`nvm`](https://github.com/nvm-sh/nvm) to manage multiple versions of Node.js on your machine and automatically switch to the correct version when you enter this repository.
#### Foundry
**Foundry** is updated frequently and may introduce breaking changes. This repository pins a specific version in `versions.json`. Use the command:

#### `foundry`

`foundry` is updated frequently and occasionally contains breaking changes.
This repository pins a specific version of `foundry` inside of [`versions.json`](./versions.json).
Use the command `just update-foundry` at the root of the monorepo to make sure that your version of `foundry` is the same as the one currently being used in CI.

#### `direnv`
```sh
just update-foundry
```

[`direnv`](https://direnv.net) is a tool used to load environment variables from [`.envrc`](./.envrc) into your shell so you don't have to manually export variables every time you want to use them.
`direnv` only has access to files that you explicitly allow it to see.
After [installing `direnv`](https://direnv.net/docs/installation.html), you will need to **make sure that [`direnv` is hooked into your shell](https://direnv.net/docs/hook.html)**.
Make sure you've followed [the guide on the `direnv` website](https://direnv.net/docs/hook.html), then **close your terminal and reopen it** so that the changes take effect (or `source` your config file if you know how to do that).
to ensure your version matches the one used in CI.

#### `docker compose`
#### Direnv
**Direnv** loads environment variables from `.envrc` automatically. After installing `direnv`, make sure it is hooked into your shell by following the guide on the **direnv website**. Restart your terminal or reload your config file for the changes to take effect.

[Docker Desktop](https://docs.docker.com/get-docker/) should come with `docker compose` installed by default.
You'll have to install the `compose` plugin if you're not using Docker Desktop or you're on linux.
#### Docker Compose
Docker Desktop includes **docker compose** by default. If you're on Linux or not using Docker Desktop, you may need to install the **Compose plugin** separately.

### Setting Up
## Setting Up

Clone the repository and open it:
Clone the repository and navigate to it:

```bash
```sh
git clone [email protected]:ethereum-optimism/optimism.git
cd optimism
```

### Building the Monorepo
## Building the Monorepo

Make sure that you've installed all of the required [Software Dependencies](#software-dependencies) before you continue.
You will need [foundry](https://github.com/foundry-rs/foundry) to build the smart contracts found within this repository.
Refer to the note on [foundry as a dependency](#foundry) for instructions.
Before proceeding, ensure all required dependencies are installed. **Foundry** is required to build the smart contracts. Refer to the section on **Foundry** above for setup instructions.

Install dependencies and build all packages within the monorepo by running:
To install dependencies and build all packages:

```bash
```sh
make build
```

Packages built on one branch may not be compatible with packages on a different branch.
**You should rebuild the monorepo whenever you move from one branch to another.**
Use the above command to rebuild the monorepo.
⚠️ **Note:** Packages built on one branch may not be compatible with those on a different branch. Always **rebuild** the monorepo after switching branches.

### Running tests
## Running Tests

Before running tests: **follow the above instructions to get everything built.**

#### Running unit tests (solidity)

```bash
### Solidity Unit Tests
```sh
cd packages/contracts-bedrock
just test
```

#### Running unit tests (Go)

Change directory to the package you want to run tests for, then:
### Go Unit Tests
Navigate to the package you want to test and run:

```shell
```sh
go test ./...
```

#### Running e2e tests (Go)
### End-to-End (E2E) Tests
For E2E tests, refer to the documentation.

See [this document](./op-e2e/README.md)
### Contract Static Analysis
We use **slither** for static analysis. Ensure **Python 3.x** is installed, then run:

#### Running contract static analysis

We perform static analysis with [`slither`](https://github.com/crytic/slither).
You must have Python 3.x installed to run `slither`.
To run `slither` locally, do:

```bash
```sh
cd packages/contracts-bedrock
pip3 install slither-analyzer
just slither
```

## Labels
Labels help categorize issues and pull requests. Here are some key labels:

Labels are divided into categories with their descriptions annotated as `<Category Name>: <description>`.

The following are a comprehensive list of label categories.

- **Area labels** ([`A-`][area]): Denote the general area for the related issue or PR changes.
- **Category labels** ([`C-`][category]): Contextualize the type of issue or change.
- **Meta labels** ([`M-`][meta]): These add context to the issues or prs themselves primarily relating to process.
- **Difficulty labels** ([`D-`][difficulty]): Describe the associated implementation's difficulty level.
- **Status labels** ([`S-`][status]): Specify the status of an issue or pr.

Labels also provide a versatile filter for finding tickets that need help or are open for assignment.
This makes them a great tool for contributors!
- **`A-<category>`**: Defines the general area of the issue/PR.
- **`C-<category>`**: Provides contextual information about the type of change.
- **`M-<category>`**: Adds metadata about process-related aspects of the issue/PR.
- **`D-<level>`**: Indicates the difficulty level of an implementation.
- **`S-<status>`**: Specifies the current status of an issue/PR.

[area]: https://github.com/ethereum-optimism/optimism/labels?q=a-
[category]: https://github.com/ethereum-optimism/optimism/labels?q=c-
[meta]: https://github.com/ethereum-optimism/optimism/labels?q=m-
[difficulty]: https://github.com/ethereum-optimism/optimism/labels?q=d-
[status]: https://github.com/ethereum-optimism/optimism/labels?q=s-
You can filter issues labeled **`M-community`** to find those available for external contributions:
🔗 [Community Issues](https://github.com/ethereum-optimism/optimism/labels/M-community)

### Filtering for Work
For easy-to-fix issues, check **`D-good-first-issue`**:
🔗 [Good First Issues](https://github.com/ethereum-optimism/optimism/labels/D-good-first-issue)

To find tickets available for external contribution, take a look at the https://github.com/ethereum-optimism/optimism/labels/M-community label.
## Modifying Labels
If you alter or delete labels, be aware that:

You can filter by the https://github.com/ethereum-optimism/optimism/labels/D-good-first-issue
label to find issues that are intended to be easy to implement or fix.

Also, all labels can be seen by visiting the [labels page][labels]

[labels]: https://github.com/ethereum-optimism/optimism/labels

### Modifying Labels

When altering label names or deleting labels there are a few things you must be aware of.

- This may affect the mergify bot's use of labels. See the [mergify config](.github/mergify.yml).
- If the https://github.com/ethereum-optimism/optimism/labels/S-stale label is altered, the [close-stale](.github/workflows/close-stale.yml) workflow should be updated.
- If the https://github.com/ethereum-optimism/optimism/labels/M-dependabot label is altered, the [dependabot config](.github/dependabot.yml) file should be adjusted.
- Saved label filters for project boards will not automatically update. These should be updated if label names change.
- **Mergify bot** uses labels for automation. Ensure you update the **Mergify configuration**.
- If modifying **`S-stale`**, update the **close-stale workflow**.
- If modifying **`M-dependabot`**, update the **Dependabot config**.
- Saved label filters on project boards will **not automatically update**.

## Workflow for Pull Requests

🚨 Before making any non-trivial change, please first open an issue describing the change to solicit feedback and guidance. This will increase the likelihood of the PR getting merged.

In general, the smaller the diff the easier it will be for us to review quickly.

In order to contribute, fork the appropriate branch, for non-breaking changes to production that is `develop` and for the next release that is normally `release/X.X.X` branch, see [details about our branching model](https://github.com/ethereum-optimism/optimism/blob/develop/README.md#branching-model-and-releases).

Additionally, if you are writing a new feature, please ensure you add appropriate test cases.

Follow the [Development Quick Start](#development-quick-start) to set up your local development environment.

We recommend using the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) format on commit messages.
🚨 **Before making major changes, open an issue** to discuss your proposal. This increases the chances of your PR being merged.

Unless your PR is ready for immediate review and merging, please mark it as 'draft' (or simply do not open a PR yet).
### PR Guidelines
- **Smaller PRs** are easier to review and merge.
- **Fork the repository**:
- Use the `develop` branch for non-breaking changes.
- Use the `release/X.X.X` branch for upcoming releases.
- **Ensure proper test coverage** for new features.
- **Follow the Conventional Commits format** for commit messages.
- **Mark PRs as 'draft'** until they are ready for review.
- **Provide a clear PR description** to help reviewers understand the changes.
- **Add comments in the 'Files Changed' tab** to clarify key parts of your PR.

Once ready for review, make sure to include a thorough PR description to help reviewers. You can read more about the guidelines for opening PRs in the [PR Guidelines](docs/handbook/pr-guidelines.md) file.
## Response Time
We aim to provide a **meaningful response within 2 business days** for external contributions.

**Bonus:** Add comments to the diff under the "Files Changed" tab on the PR page to clarify any sections where you think we might have questions about the approach taken.
## Keeping a Clean Git History

### Response time
We use **git rebase** to maintain a clean commit history. Learn more here:
🔗 [Git Rebase Tutorial](https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase)

We aim to provide a meaningful response to all PRs and issues from external contributors within 2 business days.
---

### Rebasing
📢 **You're now ready to contribute!** 🚀 Follow this guide, and you'll be on your way to making a meaningful impact on Optimism.

We use the `git rebase` command to keep our commit history tidy.
Rebasing is an easy way to make sure that each PR includes a series of clean commits with descriptive commit messages
See [this tutorial](https://docs.gitlab.com/ee/topics/git/git_rebase.html) for a detailed explanation of `git rebase` and how you should use it to maintain a clean commit history.
19 changes: 19 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -136,3 +136,22 @@ Feature branches are typically used when there are conflicts between 2 projects
## License

All other files within this repository are licensed under the [MIT License](https://github.com/ethereum-optimism/optimism/blob/master/LICENSE) unless stated otherwise.
Mise à jour du 26 janvier 2025 ✅
Mise à jour du 28 janvier 2025 ✅
Mise à jour du 29 janvier 2025 ✅
Mise à jour du 30 janvier 2025 ✅
Mise à jour du 31 janvier 2025 ✅
Mise à jour du 01 fevrier 2025 ✅
Mise à jour du 02 fevrier 2025 ✅
Mise à jour du 03 fevrier 2025 ✅
Mise à jour du 04 fevrier 2025 ✅
Mise à jour du 05 fevrier 2025 ✅
Mise à jour du 06 fevrier 2025 ✅
Mise à jour du 07 fevrier 2025 ✅
Mise à jour du 08 fevrier 2025 ✅