Update PR docs

.github/pull_request_template.md

@@ -1,5 +1,7 @@
 # Lite PR
 
+[Tip: Review docs on the ENSNode PR process](https://ensnode.io/docs/contributing/prs)
+
 ## Summary
 
 - What changed (1-3 bullets, no essays).
@@ -29,12 +31,3 @@
 
 - [ ] This PR does not introduce significant changes and is low-risk to review quickly.
 - [ ] Relevant changesets are included (or are not required)
-
-<details>
-<summary>PR Creation Tips</summary>
-
-- If this PR introduces significant changes or is higher-risk to review use the "[Substantial PR](https://github.com/namehash/ensnode/compare/main...HEAD?template=substantial.md)" template instead.
-- [Changesets](https://ensnode.io/docs/contributing/releases/#adding-a-changeset-to-your-pr) should optimize for the narrative of the next [autogenerated release notes](https://github.com/namehash/ensnode/releases). Optimize for how the resulting release notes will read to a developer in the ENS Ecosystem. Communicate all ideas with a positive frame.
-- The "Require PR Description Checks" GitHub Action will report a failing CI check on non-draft PRs where there are unchecked checkboxes in the description. You should therefore make your PR a draft PR until it is ready for review.
-
-</details>

docs/ensnode.io/src/content/docs/docs/contributing/prs.mdx

@@ -0,0 +1,83 @@
+---
+title: Creating Pull Requests
+sidebar:
+  label: Pull Requests
+  order: 3
+---
+
+# Pull Request Templates
+
+We use pull request templates to help guide contributors through the process of creating a pull request.
+- [Lite PR](https://github.com/namehash/ensnode/blob/main/.github/pull_request_template.md)
+  - *The default PR template for non-significant or low-risk changes.*
+- [Substantial PR](https://github.com/namehash/ensnode/blob/main/.github/PULL_REQUEST_TEMPLATE/substantial.md)
+  - *Template for significant changes or PRs that are complex or higher-risk to review.*
+
+# Standard PR Process
+
+1. Apply the appropriate [Pull Request Template](#pull-request-templates) based on the nature of the changes.
+2. Create your PR as a "Draft" first until it is ready for review.
+3. Complete all of your work, self-reviews, and PR description updates on the PR.
+4. Complete all checkboxes on the PR description.
+5. Convert the PR from "Draft" to "Ready for Review".
+6. Wait for automated PR reviews from Greptile and GitHub Copilot. Resolve any of their suggestions as appropriate.
+  - After applying updates, if you want Greptile to make additional follow-up reviews, add a comment to the PR with the phrase "@greptile".
+  - GitHub Copilot will automatically re-review each push to the PR.
+7. Send a message to notify the ENSNode team that the PR is ready for manual-review.
+
+# Changesets
+
+We use [changesets](https://github.com/changesets/changesets) to manage version bumps and release notes for our monorepo's artifacts (NPM packages, Docker images, and Lambda zips).
+
+## "Logical Changes"
+
+A "logical change" is a cohesive set of related modifications that share a common narrative, even if it spans multiple apps/packages.
+
+## Changeset Criteria
+
+Changesets should not be created robotically for every "logical change" in a PR. We create changesets specifically for the purposes of managing version bumps and autogenerated release notes.
+
+Only the following types of "logical changes" should be documented in a changeset:
+- Changes that should bump versions.
+- Changes that are relevant to communicate to the ENS ecosystem in release notes.
+
+If a PR does not introduce any "logical changes" meeting the above criteria then the PR should not include a changeset.
+
+## Mapping "Logical Changes" to Changesets
+
+Ensure that each "logical change" described in a changeset is appropriately mapped to the relevant package/app.
+
+Example: assume changes A, B, and C in a PR pass the criteria for changesets, with the following applicability: change A applies only to package/app X, change B applies to both package/app X and package/app Y, and change C applies only to package/app Y. This means multiple distinct changesets should be created as follows:
+- Changeset 1: Documenting change A for package/app X
+- Changeset 2: Documenting change B for package/app X and package/app Y
+- Changeset 3: Documenting change C for package/app Y
+
+In other words, avoid attaching a changeset to a package/app that is not affected by the changes.
+
+## Adding a Changeset to Your PR
+
+When you open a PR you should include relevant changeset files that document your changes.
+
+1. Run `pnpm changeset` in the monorepo root.
+2. Select the packages/apps that the "logical change" affects using the interactive prompt.
+3. Choose the version bump type:
+  - *NOTE: At this time, we are NOT using [semantic versioning](https://semver.org/). Breaking changes are classified as "minor" rather than "major".*
+  - "major" - currently reserved only for specially approved cases
+  - "minor" - breaking changes (note: ENSNode doesn't follow standard semver where breaking = major)
+  - "patch" - non-breaking changes
+4. Write a clear description of the "logical change" - this will appear in the next autogenerated release notes.
+
+The `changesets/bot` will automatically comment on your PR to either remind you to add a changeset or confirm the version changes that will happen when your PR is merged.
+
+**Important notes:**
+- Changesets should optimize for the narrative of the next [autogenerated release notes](https://github.com/namehash/ensnode/releases). Optimize for how the resulting release notes will read to a developer in the ENS Ecosystem. Communicate all ideas with a positive frame by emphasizing benefits to users, describing fixes in terms of what now works, and using active, solution‑oriented language rather than focusing on past problems.
+- All apps and packages in the ENSNode monorepo use "fixed" versioning - they all share the same version number regardless of which app or package triggered the version bump.
+  - An exception to the above "fixed" versioning is the "fallback-ensapi" app. This is a Lambda containing logic specific to NameHash deployments of ENSNode and is therefore versioned independently.
+
+## Changesets and Release Notes
+
+Upon the publishing of a new release, your change will be included in the produced artifacts and your contributions (as described in changesets) will be referenced in the autogenerated GitHub Release notes.
+
+# PR Description Checks
+
+The GitHub Action for "Require PR Description Checks" will report a failing CI check on non-draft PRs where there are unchecked checkboxes in the description. You should therefore make your PR a draft PR until it is ready for review.

docs/ensnode.io/src/content/docs/docs/contributing/releases.mdx

@@ -1,34 +1,13 @@
 ---
-title: Contributing to Releases
+title: Creating a Release
 sidebar:
   label: Releases
-  order: 3
+  order: 4
 ---
 
 import { LinkCard } from '@astrojs/starlight/components';
 
-We use [changesets](https://github.com/changesets/changesets) to manage version bumps and release notes for our monorepo's artifacts (NPM packages, Docker images, and Lambda zips).
-
-## Adding a Changeset to Your PR
-
-When you open a PR with feature or bug fix changes, you'll need to include a changeset file that documents your changes:
-
-1. Run `changeset` or `pnpm changeset` in the repository root.
-2. Select the packages/apps your changes affect using the interactive prompt.
-3. Choose whether your changes are "major" (breaking changes), "minor" (features), or "patch" (bug fixes).
-4. Write a clear description of your changes - this will appear in the release notes.
-
-The `changesets/bot` will automatically comment on your PR to either remind you to add a changeset or confirm the version changes that will happen when your PR is merged.
-
-**Important notes:**
-- Changesets are only required for user-facing changes (features, bug fixes).
-- You don't need a changeset for documentation changes or internal refactoring.
-- All our apps and packages (with an exception as noted below) use "fixed" versioning - they all share the same version number regardless of which app or package triggered the version bump.
-- An exception to the above "fixed" versioning is the "fallback-ensapi" app. This is a Lambda containing logic specific to NameHash deployments of ENSNode and is versioned independently.
-
-# Creating a Release
-
-Upon the publishing of a new release, your change will be included in the produced artifacts and your contributions will be referenced in the GitHub Release notes. There are three different types of releases that your changes can be included in for produced artifacts.
+There are three different types of ENSNode releases: Full Release, Snapshot Release, and Preview Release.
 
 ## Full Release