Skip to content

Commit

Permalink
docs: Add documentation
Browse files Browse the repository at this point in the history
  • Loading branch information
sebsadface committed Sep 2, 2024
1 parent bae5bee commit a7bee13
Show file tree
Hide file tree
Showing 7 changed files with 495 additions and 49 deletions.
3 changes: 0 additions & 3 deletions .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -12,9 +12,6 @@ deployments
broadcast
!/broadcast/*/1/

# Docs
docs/

# Dotenv file
.env

Expand Down
76 changes: 76 additions & 0 deletions CODE_OF_CONDUCT.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,76 @@
# Contributor Covenant Code of Conduct

## Our Pledge

In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to make participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, sex characteristics, gender identity and expression,
level of experience, education, socio-economic status, nationality, personal
appearance, race, religion, or sexual identity and orientation.

## Our Standards

Examples of behavior that contributes to creating a positive environment
include:

* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members

Examples of unacceptable behavior by participants include:

* The use of sexualized language or imagery and unwelcome sexual attention or
advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic
address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting

## Our Responsibilities

Project maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.

Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.

## Scope

This Code of Conduct applies within all project spaces, and it also applies when
an individual is representing the project or its community in public spaces.
Examples of representing a project or community include using an official
project e-mail address, posting via an official social media account, or acting
as an appointed representative at an online or offline event. Representation of
a project may be further defined and clarified by project maintainers.

## Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the project team at <[email protected]>. All
complaints will be reviewed and investigated and will result in a response that
is deemed necessary and appropriate to the circumstances. The project team is
obligated to maintain confidentiality with regard to the reporter of an incident.
Further details of specific enforcement policies may be posted separately.

Project maintainers who do not follow or enforce the Code of Conduct in good
faith may face temporary or permanent repercussions as determined by other
members of the project's leadership.

## Attribution

This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
available at <https://www.contributor-covenant.org/version/1/4/code-of-conduct.html>

[homepage]: https://www.contributor-covenant.org

For answers to common questions about this code of conduct, see
<https://www.contributor-covenant.org/faq>
201 changes: 201 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,201 @@
# Contributing

## Code of Conduct
Please make sure to read and observe our [Code of Conduct](/CODE_OF_CONDUCT.md).

## Bug Reports

* Ensure your issue [has not already been reported][1]. It may already be fixed!
* Include the steps you carried out to produce the problem.
* Include the behavior you observed along with the behavior you expected, and
why you expected it.
* Include any relevant traces or debugging output.

## Feature Requests

We welcome feedback with or without pull requests. If you have an idea for how
to improve the project, great! All we ask is that you take the time to write a
clear and concise explanation of what need you are trying to solve. If you have
thoughts on _how_ it can be solved, include those too!

The best way to see a feature added, however, is to submit a pull request.

## Pull requests

Pull requests are squash-merged to keep the `main` branch history clean. The title of the pull request becomes the commit message, so it should be written in a consistent format:

1) Begin with a capital letter.
2) Do not end with a period.
3) Write in the imperative: "Add feature X" and not "Adds feature X" or "Added feature X".

We welcome conventional commits, with prefixes the title with "fix:" or "feat:".

Work in progress pull requests should be submitted as Drafts and should **not** be prefixed with "WIP:".

Branch names don't matter, and commit messages within a pull request mostly don't matter either, although they can help the review process.

## Find something to work on

We are always in need of help, be it fixing documentation, reporting bugs or writing some code.
Look at places where you feel best coding practices aren't followed, code refactoring is needed or tests are missing.

If you have questions about the development process,
feel free to [file an issue](https://github.com/storyprotocol/protocol-periphery-v1/issues/new).

## Engineering Guidelines

### Testing

Code must be thoroughly tested with quality unit tests.

We defer to the [Foundry Best Practices](https://book.getfoundry.sh/tutorials/best-practices) and [Moloch Testing Guide](https://github.com/MolochVentures/moloch/tree/master/test#readme) for specific recommendations, though not all of it is relevant here. Note the introduction in Moloch Testing Guide:

> Tests should be written, not only to verify correctness of the target code, but to be comprehensively reviewed by other programmers. Therefore, for mission critical Solidity code, the quality of the tests are just as important (if not more so) than the code itself, and should be written with the highest standards of clarity and elegance.
Every addition or change to the code must come with relevant and comprehensive tests.

Flaky tests are not acceptable.

The test suite should run automatically for every change in the repository, and in pull requests tests must pass before merging.

The test suite coverage must be kept as close to 100% as possible, enforced in pull requests.

Test should use Foundry, unless for some reason js or hardhat are needed (for example, upgrades).

The test function names will follow

```
- test_contextCamel_descriptionOfTheTestCamel
- context = method name, contract or functionality.
```

In some cases unit tests may be insufficient and complementary techniques should be used:

1. Property-based tests (aka. fuzzing) for math-heavy code.
2. hardhat test using `hardhat-upgrades` OZ plugin to verify storage and upgradeability (until they support Foundry).
3. Fork tests for upgreadeability to new implementations for upgradeable contracts, testing against the deployed contracts.
4. E2E tests for critical (happy) paths.
5. Formal verification for state machines.

### Documentation

For contributors, project guidelines and processes must be documented publicly.

Every method and contract must have Natspec, using the `///` flavour always.

For users, features must be abundantly documented. Documentation should include answers to common questions, solutions to common problems, and recommendations for critical decisions that the user may face.

All changes to the core codebase (excluding tests, auxiliary scripts, etc.) must be documented in a changelog, except for purely cosmetic or documentation changes.

### Peer review

All changes must be submitted through pull requests and go through peer code review.

The review must be approached by the reviewer in a similar way as if it was an audit of the code in question (but importantly it is not a substitute for and should not be considered an audit).

Reviewers should enforce code and project guidelines.

External contributions must be reviewed separately by multiple maintainers.

### Automation

Automation should be used as much as possible to reduce the possibility of human error and forgetfulness.

Automations that make use of sensitive credentials must use secure secret management, and must be strengthened against attacks such as [those on GitHub Actions worklows](https://github.com/nikitastupin/pwnhub).

Some other examples of automation are:

- Looking for common security vulnerabilities or errors in our code (eg. reentrancy analysis).
- Keeping dependencies up to date and monitoring for vulnerable dependencies.

### Code style

Solidity code should be written in a consistent format enforced by a linter, following the official [Solidity Style Guide](https://docs.soliditylang.org/en/latest/style-guide.html). See below for further [Solidity Conventions](#solidity-conventions).

The code should be simple and straightforward, prioritizing readability and understandability. Consistency and predictability should be maintained across the codebase. In particular, this applies to naming, which should be systematic, clear, and concise.

Sometimes these guidelines may be broken if doing so brings significant efficiency gains, but explanatory comments should be added.

Modularity should be pursued, but not at the cost of the above priorities.

### Solidity Conventions

In addition to the official Solidity Style Guide we have a number of other conventions that must be followed.

- Minimize exposing state variables, unless they help with external systems integration or readability.

- Changes to state should be accompanied by events, and in some cases it is not correct to arbitrarily set state.

- Internal or private state variables or functions should have an underscore prefix.

```solidity
contract TestContract {
uint256 private _privateVar;
uint256 internal _internalVar;
function _testInternal() internal { ... }
function _testPrivate() private { ... }
}
```

* constant or immutable variables must be ALL_CAPS with underscores._ALL_CAPS if private or internal.

- Events should be emitted immediately after the state change that they
represent, and should be named in the past tense.

```solidity
function _burn(address who, uint256 value) internal {
super._burn(who, value);
emit TokensBurned(who, value);
}
```

Some standards (e.g. ERC20) use present tense, and in those cases the
standard specification is used.

- Interface names should have a capital I prefix.

```solidity
interface IERC777 {
```

- Group contracts by functionality within folders if possible.

- Interfaces should go inside the `interface` folder, mirroring the folder structure of the implementations

- Folder names must be lowercase, hyphen separated.

```
example-folder
```

- Contract names must be camel case, starting with uppercase letter

```
ExampleContract.sol
```

- Acronyms should be
- Uppercase all if in contract name (`UUPSUpgradeable`, `IPAsset`)
- Camelcase in properties and function names (`ipAssetId`), except if they are defined otherwise in external contracts or interfaces (`tokenURI`)

- Unchecked arithmetic blocks should contain comments explaining why overflow is guaranteed not to happen. If the reason is immediately apparent from the line above the unchecked block, the comment may be omitted.

- Interfaces should contain methods an events. Structs showing in an interface should be grouped in a library

- Function parameter names will have the **suffix** `_`

- Naming conventions

- Contract: CamelCase (adjectiveNoun)
- Struct (noun)
- Event (past-tense)
- Function Name (verb noun)
- local variable (noun / compound noun)
- Booleans (use `isXXX`)
- `isValid`
- `valid`
- Modifier (prepositionNoun)
- `onlyOwner`


[1]: https://github.com/storyprotocol/protocol-periphery-v1/issues
Loading

0 comments on commit a7bee13

Please sign in to comment.