Submitting Code for Review

Summary

The Dendron code review process

Prerequisites

We recommend using the github cli to work on pull requests (not required but helpful). More details on the setup here

Steps

Submitting

  1. Open up a pull request
  2. Make sure the title of the pull request mirrors the Commit Style
  3. If the PR contains multiple features, break it down in the description below the title (example provided below this section)
  4. If you are a team member, you can copy the full checklist from Dendron Extended PR Checklist - Markdown, otherwise, follow the instructions in the pull request template
{feat}({structure}): {updated hierarchies, added new note-traits}

{feat}({structure}): {updated hierarchies}
{feat}({structure}): {added new note-traits}

For Team members

  1. When an area of the checklist (eg. Instrumentation), does not apply to your PR, you can remove the checkboxes and just add NA for not applicable
  2. Similarly, if a specific check does not apply, you can use the [~] to mark it as such

Correspondence

A conversation should only be resolved when the comment has been addressed and is reflected in the pull request. At that point, the conversation should be resolved by the person that made the pull request.

Merging

See Merge Pr

Checklist

Reference

Commit Style

We follow conventional commits.

This means top level commits have the following format:

{category}({scope}): {title}

{additional details}

An example commit:

enhance(publish): speed up publishing by 500%

Use cached version of notes to generate metadata instead of building from scratch
  • To figure out the category for a commit, see Assign Category to Task
  • To figure out the scope, see Assign Scope to Feature
  • When writing the title, follow the Pull Request title
  • When applicable, include any unique testing steps taken in the commit message. This will help future people looking back at this PR understand how to test similar changes.

Pull Request title

  • When writing the pull request title, write it from the users point of view. What tangible benefit will the user have after this commit is shipped?
    • bad: talks about work done vs result achieved
      Update engine to cache notes on read
      
    • good: directly talks about benefit to end users
      Improved performance when using lookup to read notes
      
  • Write the title in lowercase
    • bad: any word in the title starts with an uppercase letter
      Improved Performance When Using Lookup to Read Notes
      Improved performance when using lookup to read notes
      
    • good: every word in the title starts with a lowercase letter
      improved performance when using lookup to read notes
      

Children
  1. GitHub CLI
  2. Merge Pr
  3. PR Checklist
  4. Sop

Backlinks