CONTRIBUTING.md

Contributing guide

Table of contents

1. Issue guide
2. Coding style guide
3. Documentation style guide
4. Git workflow

Issue guide

As an open source project, you are free to open issues and work on issues. Please comment on the issue discussion if you are thinking of contributing or picking something up, so as to not overlap on any work.

Finding an issue to work on

If you are looking for a good issue to start with, look for issues tagged with "good first issue".

Opening a new issue

If you are opening a new issue, try to be descriptive as possible. Also please check if an existing issue already exists for it already.

Coding style guide

Source code comments

Follow the NatSpec format for documenting smart contract source code. Please adhere to a few additional standards:

• Choose /** */ over /// for multi-line NatSpec comments, to save column space
• Omit the usage of @notice, this will be automatically picked up so it will save column space and improve readability
• Take advantage of inheritance for docs (such as documenting the interface), if you need to specify inherited docs use @inheritdoc

Git standards

Commits

Try to specify the scope of your change via a conventional commit (eg. enhance(docs): improve some section) or specifying the scope in brackets (eg. [docs] improve some section).

Documentation style guide

Document types

Group documentation under one of the four categories:

• Tutorials
• Guides
• Concepts
• Reference

Philosophy

• Aim for "better" instead of "perfect" -- any enhancement is a worthwhile improvement.
• Create the minimum viable documentation.
• Don't repeat yourself, use links to existing documentation or inherit it.
• Generate documentation automatically from source code whenever possible.
• Keep your comments as close as possible to the actual source code it is describing.

Standards

Tone and content

• Use descriptive link text.
• Write accessibly.
• Write for a global audience.

Language and grammar

• Use second person: "you" rather than "we".
• Use active voice: make clear who's performing the action.
• Put conditional clauses before instructions, not after.

Formatting, punctuation, and organization

• Use sentence case for document titles and section headings.
• Use numbered lists for sequences.
• Use bulleted lists for most other lists.
• Use description lists for pairs of related pieces of data.
• Use serial commas.
• Use unambiguous date formatting.

Images

• Use SVG files or crushed PNG images.
• Provide alt text.

Code blocks

• Do not use $ in shell blocks.

  Incorrect ❌:

  $ echo "this is worse for copy paste"

  Correct ✅:

  echo "this is better for copy paste"

• Escape new lines.

  Incorrect ❌:

  echo "going to pretend that this"
  && echo "is some really long command"

  Correct ✅:

  echo "at least the command" \
  && echo "looks good when copy pastad"

Git workflow

Submitting a PR

Please make sure to use a conventional commit in your PR title (eg. feat(scope): description of feature). This will be squashed and merged into the main branch.

GitHub Actions

Each commit will automatically trigger the GitHub Actions to run. If any commit message in your push or the HEAD commit of your PR contains the strings [skip ci], [ci skip], [no ci], [skip actions], or [actions skip] workflows triggered on the push or pull_request events will be skipped.

References

• Diátaxis
• Google dev docs highlights
• Google docs styleguide