Dendron Extended PR Checklist

Code

Basics

  • code should follow Code Conventions
  • sticking to existing conventions instead of creating new ones

Extended

  • General
    • check whether code be simplified
    • check if similar function already exist in the codebase. if so, can it be re-used?
    • check if this change adversely impact performance
  • Operations
    • when shipping this change, will it just work or will it introduce additional operational overhead due to complicated interface or known bugs?
  • Architecture
    • check if code is introducing changes on a foundational class or interface. if so, call for design review if needed

Instrumentation

Basics

  • if you are adding analytics related changes, make sure you Document (Private) changes in airtable

Extended

Tests

Basics

Extended

  • If you are adding a new language feature (graphically visible in VS Code/preview/publishing), an example is included in the test workspace

  • CSS

    • display is correct for following dimensions
      • sm: screen ≥ 576px, eg. iphonex, (375x812)
      • lg: screen ≥ 992px
      • xxl: screen ≥ 1600px eg. mac (1600x900)
    • display is correct for following browsers (across the various dimensions)
      • safari
      • firefox
      • chrome

Docs

Basics

  • if your change reflects documentation changes, also submit a PR to dendron-site and mention the doc PR link in your current PR (NOTE: submit the PR against the dev branch of the dendron-site repo)

Basics

  • does this change introduce a new or better way of doing things that others need to be aware of? if so, an async should be created and a process added in Development or Packages

Close the Loop

Basics

Extended

  • is this a developer BREAKING change? if another person cloning from this branch will need to adjust their dependencies or mental model of the architecture, then it is. if this is the case, make sure this is communicated according to Close Loop