zed/docs/src/development/release-notes.md
morgankrey 6daa541e77
docs: Apply documentation standards across all docs (#49177)
## Summary

Comprehensive remediation of 146 documentation files to align with Zed's
documentation conventions and brand voice guidelines.

## Changes

### YAML Frontmatter
- Added `title` and `description` frontmatter to all docs missing it

### Settings UI Pattern
- Updated 48+ files to show Settings Editor before JSON examples
- Pattern: `Configure X in Settings ({#kb zed::OpenSettings}), or add to
your settings file:`
- Added `([how to edit](./configuring-zed.md#settings-files))` links for
JSON-only settings

### Brand Voice Fixes
- Removed exclamation points (command-palette, key-bindings, repl,
privacy-and-security, etc.)
- Simplified em dash chains to parentheticals (environment,
troubleshooting, agent-panel, etc.)
- Fixed marketing language (yarn.md intro, development/linux.md)

### Terminology Alignment
- `settings UI` -> `Settings Editor`
- `sidebar` -> specific panel names (Project Panel, Collab Panel)
- `directory` -> `folder` in non-technical contexts
- `workspace` -> `project` in non-LSP contexts
- `Command Palette` -> `command palette` (lowercase)

### Callout Standardization
- Converted various callout formats to standard `> **Note:**` pattern

## Related

Depends on conventions established in #49176.

Release Notes:

- N/A
2026-02-17 20:58:17 -06:00

2.1 KiB

title description
Release Notes Guide to release notes for Zed development.

Release Notes

Whenever you open a pull request, the body is automatically populated based on this pull request template.

...

Release Notes:

- N/A _or_ Added/Fixed/Improved ...

On Wednesdays, we run get-preview-channel-changes, which collects Release Notes lines from pull requests landing in preview, as described in the Release docs.

The script outputs everything below the Release Notes line, including metadata such as the pull request author (if they are not a Zed team member) and a link to the pull request. If you use N/A, the script skips your pull request entirely.

Guidelines for crafting your Release Notes line(s)

  • A Release Notes line should only be written if the user can see or feel the difference in Zed.
  • A Release Notes line should be written such that a Zed user can understand what the change is. Don't assume a user knows technical editor developer lingo; phrase your change in language they understand as a user of a text editor.
  • If you want to include technical details about your pull request for other team members to see, do so above the Release Notes line.
  • Changes to docs should be labeled as N/A.
  • If your pull request adds/changes a setting or a keybinding, always mention that setting or keybinding. Don't make the user dig into docs or the pull request to find this information (although it should be included in docs as well).
  • For pull requests that are reverts:
    • If the item being reverted has already been shipped, include a Release Notes line explaining why we reverted, as this is a breaking change.
  • If the item being reverted hasn't been shipped, edit the original PR's Release Notes line to N/A; otherwise, it will still be included and the release notes compiler may not know to skip it.