Conventions

Commit message, GitHub issue, and pull request label conventions.

Commit Messages

Understanding what's happening in a repository with many contributors like this and navigating between commits is essential. Moreover, with various levels of contributors & their backgrounds, the commit messages can easily be confusing, and the structure may follow different approaches.

To overcome these issues, we adopt Git commit conventions to allow contributors to add more semantic meaning to our Git history. We use commitlint to lint the git commit messages. To enforce it, we use a Git pre-commit hook to run the commitlint upon a Git commit command. This configuration prevents committing the staged files if the commit message fails to comply with the conventions.

It's advisable to read the commit conventions briefly to understand their other benefits further. However, if you're having problems with it, you can use this tool to help.

Furthermore, please refer to the list of commit types and scopes we use to avoid adding a new scope with a similar meaning or synonym to the existing ones.

Conventional Commits

The convention specification looks like this:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Commit types

Here are what we use for the commit types:

• build
• chore
• docs
• feat
• fix
• perf
• refactor
• style
• test

Commit scopes

Here are what we use for the scopes:

• docs
• hs (homeschool)
• config
  • eslint
  • ts
• ui
• e2e
• security
• seo

Issue and Pull Request Labels

Issue labels are a tool to group issues into one or more categories. It helps us track and manage issues and pull requests.

Please open an issue on pejuang-kode/zavi.family if you have suggestions for new labels.

Type of Issue and Issue State

Topic Categories