Dotcom Release Crew

Dotcom release crew

Identify who contributed critical fixes or significant features to this week's dotcom release (the commits on main that are not yet on production) and post a short summary to the #development Discord channel.

The goal is a very tight list of people to involve in the release — 2–3 people at most, not a changelog and not the whole engineering team. Only exceed 3 in extraordinary weeks where more than three people each own a genuinely critical, release-risky change.

Inputs

• DISCORD_RELEASE_WEBHOOK_URL — environment variable holding the Discord webhook that posts to #development. Required. If it is unset, stop and tell the user to set it (do not hardcode a webhook URL — this repo is public).
• GH_TOKEN — used by gh. Present automatically in CI; locally, ensure gh auth status works.

Workflow

1. Fetch the commit range

Get every commit on main that is not on production, with its author and subject line. --paginate handles ranges larger than 250 commits.

gh api repos/tldraw/tldraw/compare/production...main --paginate \
  --jq '.commits[] | [ (.author.login // .commit.author.name), (.commit.author.name), (.commit.message | split("\n")[0]) ] | @tsv'

Each row is: login\tdisplay name\tsubject. tldraw squash-merges PRs, so the commit author is the PR author and the subject is the PR title (usually a conventional commit like feat(editor): ... with a trailing (#1234)).

Also capture the human-readable diff URL for the message: https://github.com/tldraw/tldraw/compare/production...main.

If there are zero commits, post a brief note that there are no changes to release this week and stop.

2. Select the critical contributors

Read the subject lines and keep only commits that a release manager would want a human on hand for. Group the kept commits by author.

Include (judgment, not just prefix):

• feat — significant features, especially scoped to dotcom, editor, sync, sync-core, store, tlschema, state.
• fix — meaningful correctness, data-integrity, sync, or crash fixes.
• perf — performance changes that affect users.
• Anything touching multiplayer sync, persistence/migrations, or auth/billing, even if small.

Exclude:

• docs, test, chore, style, ci, build, and dependency bumps (dependabot, "Bump versions", [skip ci]).
• Trivial fixes (typos, comments, lint, flaky-test pins, snapshot updates).
• Reverts that cancel out another commit in the same range.

Then rank the authors by how critical and release-risky their change is, and keep only the top 2–3. When unsure whether a change is "critical", lean toward excluding it — the point is a very short, high-signal list. It is completely fine to surface just 1–2 people, and normal to have some kept-but-not-listed commits.

Only go above 3 people in extraordinary weeks — for example a large migration plus an unrelated sync fix plus an auth change all landing together, where each genuinely needs its own owner on hand. If you do, briefly justify the extra names to yourself before including them.

3. Compose the message

Keep it under 2000 characters (Discord's limit). One bullet per person; if someone has multiple notable changes, list them under one bullet.

Mention each person with their Discord user ID from the table below, written as <@ID> — Discord renders that as a real @ mention and pings them. If a GitHub login is not in the table, fall back to the plain GitHub login (no <@…>), since a wrong ID would ping the wrong person.

| GitHub login | Name | Discord username | Discord user ID |

| ----------------- | ----------------- | ----------------- | --------------------- |

| angrycaptain19 | Tim | trg1379 | 1197197068045910087 |

| AniKrisn | Ani Krishnan | anikrisn | 1348594738927767612 |

| audrey17leo | Audrey | dreiiz | 617346760385495060 |

| danieljamesross | Dan Ross | djrdjrdjr | 1494628009896837203 |

| driev | Niall | driev_ | 1338934372992159786 |

| frolic | Kevin Ingersoll | frolic | 79416844720537600 |

| jsscclr | Jessica Edwards | jsscclr | 1382308873276358766 |

| kaneel | Guillaume Richard | guillaumetldraw | 1519303217840656522 |

| kostyafarber | Kostya Farber | kostyafarber | 327278771541377034 |

| m31-galaxy | Andy (Andromeda) | m31_galaxy | 650459420635168769 |

| max-drake | Max Drake | max__drake | 177565795973464065 |

| meg-an31 | Megan Walker | megelia | 813347618083045393 |

| mimecuvalo | Mime Čuvalo | mimecuvalo | 1193847824350199881 |

| MitjaBezensek | Mitja Bezenšek | mitja_bezensek | 559094482470174720 |

| nattofu | Leo | nattotofu | 168686397941743617 |

| steveruizok | Steve Ruiz | steveruizok | 414943707662385154 |

Format:

🚀 **dotcom release — people to involve this week**
Critical changes on production...main:

• **Mime Čuvalo** (<@1193847824350199881>) — fix(release): don't cut a new SDK version for docs-only patches
• **Kevin Ingersoll** (<@79416844720537600>) — feat(editor): finer, coarse-pointer-aware hit-testing

N critical changes from M contributors · https://github.com/tldraw/tldraw/compare/production...main

If nothing critical was selected but there were commits, say so briefly (e.g. "No critical changes flagged this week — release looks routine.") and still include the diff link.

4. Post to Discord

Post the message as the webhook's content. Build the JSON safely (do not string-interpolate the message into the JSON by hand — use jq so newlines and quotes are escaped):

jq -n --arg content "$MESSAGE" '{content: $content, allowed_mentions: {parse: ["users"]}}' \
  | curl -sS -X POST -H "Content-Type: application/json" -d @- "$DISCORD_RELEASE_WEBHOOK_URL"

allowed_mentions.parse: ["users"] lets the <@ID> mentions actually ping people while making sure @everyone/@here/role mentions can never fire from this message.

A successful post returns HTTP 204 with an empty body. Report to the user what was posted (or that the post failed, with the curl output).

Notes

• Do not commit or echo the full webhook URL anywhere.
• This skill only reads git history and posts a message; it never modifies the repo.
• production...main assumes the normal weekly flow where the dotcom release is the main → production promotion, so this range is exactly what's about to ship. During SDK freeze weeks — when production ships cherry-picked hotfixes while main keeps moving — the range is less precise (it can miss production-only hotfix authors and include main work that isn't releasing yet). That's fine: freeze weeks are all-hands anyway, so a perfectly tailored crew list matters less then.