Submitting Code for Review

Prerequisites

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

Steps

Submitting

Open up a pull request
Make sure the title of the pull request mirrors the Commit Style
If the PR contains multiple features, break it down in the description below the title (example provided below this section)
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}
```
After submitting a pull request, make sure that the integrations tests pass
- NOTE: if you see failures, see github actions troubleshooting

For Team members

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
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

From Merge Pr

Go to text →

Prerequisites

Have maintain permission in Dendron repo (everyone in Engineering (Private) gets this)
Have your PR approved by either @kevin (Private) or @jonathan (Private) and all outstanding discussions resolved

Steps

Merge PR
- when merging PR, make sure the commit message corresponds to our commit style
- eg. enhance(publish): speed up publishing by 500%
Move the commit to ready to ship
No note with name area.product.sop.ready-to-ship found in cache during parsing.
Create Analytics (Private) entries in the proper release version
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

Checklist

From PR Checklist

Go to text →

Index

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

Backlinks