The changelog is for short, dated, factual notes — what shipped, what fixed, what broke. It has a precise format and a tight word budget. It works well for that, badly for everything else.

The journal is the everything-else.

What lands here

Long-form posts written by the people who write the code. Three categories so far:

• Deep-dives — how a feature actually works under the hood, when the explanation is too long for a changelog entry but too useful to live only in a PR thread.
• Opinion pieces — the why behind a choice we made, especially when the choice is to not ship something a competitor ships.
• Post-mortems — when an incident is meaningful, the public write-up lands here with the timeline, the root cause, and what changes downstream.

What does not

• No marketing puff. If a post can't survive being read by an engineer who is already a customer, it doesn't belong here.
• No newsletter. The RSS feed is the subscribe surface. Subscribe at /journal/rss.xml.
• No comments — open a GitHub discussion if a post deserves a thread.

Cadence

We post when we have something to say, not on a calendar. Expect a handful of posts a quarter, not a daily stream.

That's it. See you in the next one.