Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
67 lines (58 loc) · 3.22 KB

CONTRIBUTING.md

File metadata and controls

67 lines (58 loc) · 3.22 KB

Styleguides

We are happy to accept pull requests and issues from any contributors. Please note that we try to maintain a consistent quality standard. For a quick overview please find some of the most important points below.

Quick Overview

  • Keep a clean commit history. This means no merge commits, and no long series of "fixup" patches (rebase or squash as appropriate). Structure work as a series of logically ordered, atomic patches. git rebase -i is your friend.
  • Changes should only be made via pull request, with review. A pull request will be committed by a "committer" (an account listed in CODEOWNERS) once it has had an explicit positive review.
  • Make sure you update the CHANGELOG when submitting a MR.
  • When changes are restricted to a specific area, you are recommended to add a tag to the beginning of the first line of the commit message in square brackets e.g., "[apps] Fix bug #157".
  • Do not force push. After rebasing, use --force-with-lease instead.
  • Do not attempt to commit code with a non-Apache (or Solderpad for hardware) license without discussing first.
  • If a relevant bug or tracking issue exists, reference it in the pull request and commits.

Git Considerations

  • Separate subject from body with a blank line
  • Limit the subject line to 72 characters
  • Capitalize the subject line
  • Do not end the subject line with a period
  • Use the imperative mood in the subject line
  • Use the body to explain what and why vs. how
  • Consider starting the commit message with an applicable emoji:
    • ✨ :sparkles: When introducing a new feature
    • 🎨 :art: Improving the format/structure of the code
    • ⚡ :zap: When improving performance
    • 🔥 :fire Removing code or files.
    • 📝 :memo: When writing docs
    • 🐛 :bug: When fixing a bug
    • 🔥 :fire: When removing code or files
    • 🗑️ :wastebasket: When removing code or files
    • 💚 :green_heart: When fixing the CI build
    • 👷 :construction_worker: Adding CI build system
    • ✅ :white_check_mark: When adding tests
    • 🔒 :lock: When dealing with security
    • ⬆️ :arrow_up: When upgrading dependencies
    • ⬇️ :arrow_down: When downgrading dependencies
    • 🚨 :rotating_light: When removing linter warnings
    • ✏️ :pencil2: Fixing typos
    • ♻️ :recycle: Refactoring code.
    • 💥 :boom: Introducing breaking changes
    • 🚚 :truck: Moving or renaming files.
    • 👾 :space_invader: When fixing something synthesis related
    • 👌 :ok_hand Updating code due to code review changes
    • 🏗️ :building_construction: Making architectural changes.

For further information please see the excellent guide by Chris Beams.

Code Style

Consistent code style is important. We try to follow existing style conventions as much as possible: