Skip to content

Project Charter

Jump to bottom
Jean-Philippe Raynaud edited this page Nov 13, 2023 · 15 revisions

Foreword

This file contains the Mithril Project Charter, including but not limited to coding standards and best practices when contributing.

Core Team Golden Rules

  1. Systematically tag breaking change or manual-deployment Issues and/or PRs.
  2. Plan migrations: a/ with other teammates if support is needed and b/runthem locally or in a specific environment before merging.
  3. Merging code is not allowed from Monday to Thursday after 5pm CET, on Friday after 12pm CET and during the week-end.
  4. When merging a PR, a teammate must make sure that the merge is successfully deployed, and escalate with other teammates if needed.
  5. Teammates should be able to connect to the Mithril networks machines and operate runbooks processes.

Coding Standards

Rust

  • Use rustfmt to format the code before submitting a commit.

  • Use clippy to format the code before submitting a commit.

Why

It helps the team keep a clean and neat codebase and straightforward commits diffs

Git

Commit message format

Here are seven rules for great git commit messages:

  1. Separate subject from body with a blank line

  2. Limit the subject line to 50 characters (soft limit)

  3. Capitalize the subject line

  4. Do not end the subject line with a period

  5. Use the imperative mood in the subject line and suffix with ticket number if applicable

  6. Wrap the body at 72 characters (hard limit)

  7. Use the body to explain what and why vs. how

Why

Git commit messages are our only source of why something was changed the way it was changed. So we better make the readable, concise and > detailed (when required).

Thanks to the Hydra team for these Git guidelines! Hydra Wiki

Pull Request

Here are the rules we tend to apply when using PR:

  1. Name your branches properly: for example username/branch-that-does-something

  2. Prefer PR over main branch commit (they are reserved for very low impact updates and should used with parcimony)

  3. Prefer Rebase and Merge than Create a merge commit

  4. Prefer multiple atomic commits (it will facilitate the reviews)

  5. Make sure the CI is all green 🟢 and that there's no lint warnings (such as the one from clippy for Rust)

  6. Ask for reviewers (caution, they may depend on the modified directories): 1 approval is the general rule, wait for 2 or more if the impact is high

Why

Code reviews are important to share knowledge and to deliver better software quality!

Clone this wiki locally