Submitting Code for Review


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



  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}
  5. After submitting a pull request, make sure that the integrations tests pass

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


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.




  1. Merge PR
    • when merging PR, make sure the commit message corresponds to our commit style
    • eg. enhance(publish): speed up publishing by 500%
  2. Move the commit to ready to ship
    No note with name area.product.sop.ready-to-ship found in cache during parsing.
  3. Create Analytics (Private) entries in the proper release version
  4. If the change is going out in the current release, merge in any doc changes. Otherwise, create a task to merge in docs after the current release is pushed



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

  1. GitHub Actions
  2. GitHub CLI
  3. Merge Pr
  4. PR Checklist