Skip to content

docs: add voice guidelines to the contributing page - #38705

Merged
alii merged 2 commits into
mainfrom
farm/955b1777/docs-voice-guidelines
Aug 14, 2026
Merged

docs: add voice guidelines to the contributing page#38705
alii merged 2 commits into
mainfrom
farm/955b1777/docs-voice-guidelines

Conversation

@robobun

@robobun robobun commented Aug 14, 2026

Copy link
Copy Markdown
Collaborator

Problem

Fix

  • Adds a "Contributing to the docs" section to docs/project/contributing.mdx with a "Voice" subsection: short sentences, plain words, active voice with the actor named, present tense, second person, name the subject instead of a bare "this", no "easy"/"simple"/"just"/"quick", say what to do rather than what to avoid, gender-neutral wording, descriptive link text, run every example. Adapted from the Next.js docs contribution guide, which is credited in the text.
  • docs/README.md points at the section, and its Mintlify "Development" section is removed (it now says only that bun.com/docs is built from this directory).
  • Verified: prettier --check on both files; the link targets in the new section (/pm/cli/install, the Next.js URL) resolve.

Related

@coderabbitai

coderabbitai Bot commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

Warning

Review limit reached

@robobun, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 16 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 1d3d945d-ed21-449a-97f0-2d516a102e34

📥 Commits

Reviewing files that changed from the base of the PR and between c04101b and ab635bc.

📒 Files selected for processing (2)
  • docs/README.md
  • docs/project/contributing.mdx

Comment @coderabbitai help to get the list of available commands.

@robobun

robobun commented Aug 14, 2026

Copy link
Copy Markdown
Collaborator Author

Status: merged. Docs-only (docs/project/contributing.mdx, docs/README.md).

Related:

@claude claude Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM — docs-only change writing down editorial conventions that prior passes (#28788, #33112, #38686) already applied by hand.

What was reviewed:

  • Verified the internal link target /pm/cli/install exists (docs/pm/cli/install.mdx).
  • Checked the Mintlify preview instructions match the existing ones in docs/README.md.
  • Confirmed the .claude/docs/landing-prs.md bullet slots into the existing "Docs, types, and comments" section without disturbing neighboring bullets.
  • The new prose follows its own voice rules (active, present-tense, second-person, no "simple"/"just").
Extended reasoning...

Overview

This PR adds a "Contributing to the docs" section to docs/project/contributing.mdx with a "Voice" subsection codifying the editorial rules that have been applied in repeated docs-wide cleanup PRs. It also adds a pointer from docs/README.md and a one-line summary bullet in .claude/docs/landing-prs.md next to the existing docs-verification guidance. Three files touched, all Markdown/MDX, ~30 net added lines.

Security risks

None. Pure documentation prose; no code, no config, no build changes, no executable snippets beyond bun install -g mint / mint dev, which mirror the existing instructions already in docs/README.md.

Level of scrutiny

Low. This is contributor-facing documentation about writing style. It touches no runtime code, no tests, no CI config, and no type declarations. The only correctness surface is markdown rendering and link validity — the fenced code block is balanced, headings nest correctly (## then ###), and the one internal link (/pm/cli/install) resolves to an existing page.

Other factors

  • The content is consistent with the repo's existing review guidance: the "run every code example" and "check option names against main" bullets restate the adjacent "Verify every documentation claim you publish" rule already in landing-prs.md.
  • The Mintlify preview commands duplicate what docs/README.md already documents, so no new tooling assumption is introduced.
  • No prior reviews or outstanding comments on the thread beyond bot noise.
  • The PR description states the link targets and prettier formatting were verified; I independently confirmed the internal link target exists.

Distills the rules the last few docs-wide editorial passes applied by hand
(short sentences, active voice, present tense, second person, no easy/simple/
just, positive framing) into a Voice section on the contributing page, adapted
from the Next.js docs contribution guide. docs/README.md points at it.
@robobun
robobun force-pushed the farm/955b1777/docs-voice-guidelines branch from 5fb29a3 to 4ec2b14 Compare August 14, 2026 22:40
@robobun

robobun commented Aug 14, 2026

Copy link
Copy Markdown
Collaborator Author
Updated 3:53 PM PT - Aug 14th, 2026

@robobun, your commit ab635bc3e5de9288e40b9f867dfc4732fed5cf4c passed in Build #96770! 🎉


🧪   To try this PR locally:

bunx bun-pr 38705

That installs a local version of the PR into your bun-38705 executable, so you can run:

bun-38705 --bun

@claude claude Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM — docs-only addition of voice guidelines. The inline nit about the missing .claude/docs/landing-prs.md hunk (or the PR-description claim referencing it) is worth resolving before merge, but it doesn't block the substance.

Extended reasoning...

Overview

This PR adds a "Contributing to the docs" section with a "Voice" subsection to docs/project/contributing.mdx (11 bullet points on writing style: short sentences, active voice, present tense, second person, no "easy/simple/just", descriptive link text, run examples, etc.), and adds a two-sentence pointer to it in docs/README.md. Total: +28 lines across two Markdown/MDX files. No source code, tests, config, or generated files are touched.

Security risks

None. This is prose in documentation files with no executable content beyond a three-line bash example (bun install -g mint, cd docs, mint dev) that already appears verbatim in docs/README.md.

Level of scrutiny

Low. Docs-only change with no behavioral impact and green CI. I checked that the internal link target /pm/cli/install exists (docs/pm/cli/install.mdx), that the new section's own prose follows the rules it introduces, that the ### Voice heading produces the #voice anchor referenced from docs/README.md, and that no CODEOWNERS entry covers docs/. The guidelines codify existing practice from prior editorial passes (#28788, #33112, #38686) rather than introduce new policy, so this is not a design decision requiring maintainer sign-off.

Other factors

The bug-hunting system flagged one nit: the PR description says .claude/docs/landing-prs.md gets a one-line summary, but that file is not in the diff. This is a real discrepancy between the description and what lands, but it is auxiliary — the canonical guidelines land correctly in contributing.mdx and the docs/README.md pointer is present. The fix is trivial (add the one-liner or drop the description bullet), and the inline comment already surfaces it, so it does not need to block approval.

Comment thread docs/project/contributing.mdx
@alii
alii merged commit 0125363 into main Aug 14, 2026
5 checks passed
@alii
alii deleted the farm/955b1777/docs-voice-guidelines branch August 14, 2026 22:56
alii pushed a commit that referenced this pull request Aug 14, 2026
…page (#38718)

### Problem
- `.claude/docs/landing-prs.md` ("Docs, types, and comments") covers
verifying docs claims but says nothing about prose style, so docs PRs
keep reintroducing the patterns that #28788, #33112 and #38686 removed
(run-on sentences, passive voice, "will", tutorial "we",
"easy"/"simple"/"just").

### Fix
- Adds one bullet to that section summarizing the voice rules and
pointing at the "Voice" section that #38705 adds to
`docs/project/contributing.mdx`.
- Split out from #38705 because a PR whose files are all under `docs/`
skips the test pipeline (`.buildkite/ci.mjs`, the "PR is only docs"
check), and this file is outside `docs/`. Keeping it separate lets
#38705 and the docs-wide pass stay docs-only.
- Markdown only; nothing to run. The file is outside the paths `bun run
prettier` formats, so the existing formatting of neighboring lines is
left as is.

## Contributing to the docs

The docs are the MDX files in `docs/` in the Bun repository. [bun.com/docs](https://bun.com/docs) is built from them.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 The description says this section covers "how to preview them", but the landed text only says where the docs live — and commit ab635bc in this PR deletes the ## Development (Mintlify mint dev) block from docs/README.md without mentioning it in the description, so contributors now have no documented way to preview docs locally. Either add (or point to) the replacement preview workflow here, or drop "how to preview them" from the description and mention the README ## Development removal so the squash message matches the diff.

Extended reasoning...

What's mismatched

The PR description's Fix bullet says:

Adds a "Contributing to the docs" section to docs/project/contributing.mdx (where the docs live, how to preview them) with a "Voice" subsection…

The section that actually landed at contributing.mdx:383 is one sentence:

The docs are the MDX files in docs/ in the Bun repository. bun.com/docs is built from them.

That covers where the docs live, but there is no preview workflow.

The unmentioned removal

At the same time, this PR's second commit — ab635bc "drop the Mintlify preview instructions; bun.com/docs has its own generator" — deletes the entire ## Development block from docs/README.md:

-## Development
-
-Install the [Mintlify CLI](https://www.npmjs.com/package/mint) to preview the documentation locally:
-
-```bash
-bun install -g mint
-```
-
-Run the development server:
-
-```bash
-mint dev
-```
-
-The site is served at `http://localhost:3000`.

That block was the only documented local-preview workflow anywhere in the repo. The PR description says only "docs/README.md points at the section" — it doesn't mention the removal. The description was already updated once during review (see the resolved thread about landing-prs.md moving to #38718), so keeping it accurate is clearly in scope.

Why it matters (a little)

After merge, contributors have no documented way to preview docs locally, while:

  • .claude/docs/landing-prs.md:55 (which CLAUDE.md tells docs authors to read) still instructs them to "preview rendered markdown (an unbalanced fence swallows everything after it)"
  • docs/docs.json:2 still declares "$schema": "https://mintlify.com/docs.json", so it isn't obvious to a contributor that Mintlify is no longer the way to preview

So the guidance says "preview before committing", the description says "this section tells you how", and the section doesn't. The commit message for ab635bc ("bun.com/docs has its own generator") confirms the removal was intentional, which makes the description's "how to preview them" claim doubly stale.

Per .claude/docs/landing-prs.md (PR process): "The PR description is the permanent squash-commit message — keep it true" and "Every file in the diff must be explainable from the PR's stated purpose."

Step-by-step

  1. Contributor wants to edit docs; CLAUDE.md → reads Docs, types, and comments in .claude/docs/landing-prs.md.
  2. That section says: preview rendered markdown before committing.
  3. Contributor looks in docs/README.md — before this PR: bun install -g mint / mint dev / localhost:3000. After this PR: only a pointer to contributing.mdx#voice.
  4. Contributor follows the pointer to contributing.mdx § Contributing to the docs — no preview instructions there either.
  5. Contributor greps docs/ for "preview" / "mint" — only docs.json's Mintlify $schema and an unrelated font-CDN URL remain, which is more confusing than nothing.

Fix

Either of:

  • Add the intended preview line to contributing.mdx § Contributing to the docs (whatever replaced Mintlify — the ab635bc commit message says "bun.com/docs has its own generator", so presumably a command from that generator, or a note that there is no local preview and to check the deploy preview on the PR).
  • Or, drop "how to preview them" from the description's parenthetical and add a line mentioning that docs/README.md's ## Development (Mintlify) block was removed, so the squash-commit message matches what actually lands.

Why this is only a nit

Nothing breaks at runtime — this is a docs/contributor-workflow gap plus a stale squash-message claim. The Voice section (the substance of this PR) lands correctly. The fix is a one-line description edit or a one-sentence addition to the new section.

alii pushed a commit that referenced this pull request Aug 15, 2026
### Problem
- The docs still contain a lot of prose that breaks the voice rules
#38705 added to the contributing page: passive sentences with no actor
("coverage is merged by the coordinator"), sentences that chain four or
five clauses with commas and dashes, "will" for present behavior, bare
"This ..." sentences whose referent is unclear, tutorial "we", and
"easy"/"simple"/"just". #38686 fixed this for the pages added last week;
this PR does the same for the rest of `docs/`.

### Fix
- Wording-only pass over every page in `docs/` (332 files read, 179
changed, 845 hunks, +1011/-966). Each hunk is one of: name the actor
(Bun, the bundler, the test coordinator, you), split a run-on sentence
or turn an enumeration into a list, present tense, name the subject of a
bare "this"/"it", "you" instead of "we", or drop a subjective word. Net
80 fewer em dashes; no new ones.
- Nothing but prose changed. Checked mechanically for every changed file
against `main`: fenced code blocks byte-identical, headings identical,
frontmatter identical, link targets identical (same multiset), MDX
component tags identical, same number of table rows, and no inline code
span added or removed. `prettier --check docs` is clean.
- No claim about Bun's behavior was added, removed or changed. Every
hunk got a second read specifically for that (20 hunks were tightened
and 28 reverted as a result, which is why two of the 181 files touched
ended up unchanged). The 37 hunks where a qualifier word (not, only,
unless, except, default, ...) disappeared from the old text were checked
individually; in each the condition is still stated in the new wording
(for example "the next fire is not scheduled until it settles" became
"Bun schedules the next fire only once it settles").
- Docs-only, so CI skips the test pipeline for this PR. This will
conflict with open docs PRs that touch the same lines; the edits are
sentence-level, so rebasing either side is mechanical.

### Background
- The rules applied here are the ones on [the contributing
page](https://bun.com/docs/project/contributing#voice) (#38705), adapted
from the Next.js docs guide. Two earlier passes (#28788, #33112) removed
the grep-able cases (future tense, "Note that", filler); what was left
is mostly passive voice and sentence structure, which is why most hunks
here rephrase a whole sentence rather than delete a word.
- Things that looked factually wrong or internally inconsistent were
deliberately left alone, since fixing them needs someone who knows the
feature; they are listed below for follow-up.

<details>
<summary>Example hunks</summary>

`docs/test/parallel.mdx`:

> \- Coverage, JUnit XML and snapshot writes are merged by the
coordinator, so ...
> \+ The coordinator merges coverage, JUnit XML and snapshot writes, so
...

> \- `--timings` can be passed more than once; the files are read as one
table (paths that don't exist yet are skipped), and `--update-timings`
writes to the **first** path.
> \+ You can pass `--timings` more than once. Bun reads the files as one
table and skips paths that don't exist yet. `--update-timings` writes to
the **first** path.

`docs/guides/process/os-signals.mdx`: one sentence carrying two events,
two links and two conditions became a two-item list.

`docs/project/building-windows.mdx`: the four things `--lto=on` does
became a four-item list; the two reasons there is no LTO for arm64 and
`--baseline` became two sentences.

`docs/runtime/sqlite.mdx`:

> \- Using a statement that was finalized by `close()` throws `Database
has closed`, except `toString()`, which returns an empty string, and
`finalize()`, which stays safe to call.
> \+ Using a statement that `close()` finalized throws `Database has
closed`. Two exceptions: `toString()` returns an empty string, and
`finalize()` stays safe to call.

</details>

<!-- factual-issues -->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants