Skip to content

Latest commit

 

History

History
26 lines (17 loc) · 2.29 KB

CONTRIBUTING.md

File metadata and controls

26 lines (17 loc) · 2.29 KB
Raw

Contributing to Maru

Welcome 🦄 to Maru! If you'd like to contribute, please reach out to one of the CODEOWNERS and we'll be happy to get you started!

Below are some notes on our core software design philosophies that should help guide contributors.

Code Quality and Standards

Fundamentally, software engineering is a communication problem; we write code for each other, not a computer. When working on this project (or any project!) keep your fellow humans in mind and write clearly and concisely. Below are some general guidelines for code quality and standards that make Maru ✨

  • Write tests that give confidence: Unless there is a technical blocker, every new feature and bug fix should be tested in the project's automated test suite. Although many of our tests are E2E, unit and integration-style tests are also welcomed. Note that unit tests can live in a *_test.go file alongside the source code, and E2E tests live in src/test/e2e

  • Prefer readability over being clever: We have a strong preference for code readability in Maru. Specifically, this means things like: naming variables appropriately, keeping functions to a reasonable size and avoiding complicated solutions when simple ones exist.

  • User experience is paramount: Maru doesn't have a pretty UI (yet), but the core user-centered design principles that apply when building a frontend also apply to this CLI tool. First and foremost, features in Maru should enhance workflows and make life easier for end users; if a feature doesn't accomplish this, it will be dropped.

Pre-Commit Hooks and Linting

In this repo you can optionally use pre-commit hooks for automated validation and linting, but if not CI will run these checks for you.

Continuous Delivery

Continuous Delivery is core to our development philosophy. Check out https://minimumcd.org for a good baseline agreement on what that means.

Specifically:

  • We do trunk-based development (main) with short-lived feature branches that originate from the trunk, get merged into the trunk, and are deleted after the merge
  • We don't merge code into main that isn't releasable
  • We perform automated testing on all changes before they get merged to main
  • We create immutable release artifacts