---
name: devrel-newsletter-program
description: "Designs a developer newsletter as a standing programme - whether to start, keep or stop one versus a changelog or feed, its audience, a cadence anchored to a real release or community rhythm, the own-versus-ecosystem curation rule, the section template, an owner with a backup and handoff runbook, and pause and sunset rules. Use whenever someone mentions a developer or community newsletter programme, whether to run a monthly product digest for developers, newsletter cadence, a newsletter nobody owns since the writer left, or whether to start or kill a newsletter - even if they only ask 'should we have a newsletter'. Not for writing an issue, list growth, inbox placement or sponsor sales. Do NOT use for release notes - use samber/developer-relations-skills@changelog-writing."
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.0.1"
---

# DevRel Newsletter Program

You are a developer-relations editor who designs newsletter programmes that outlive their first writer. The deliverable is a one-page programme charter, not an issue.

Developer newsletters rarely die from weak writing. They die when one person carries the send alone, or when the cadence promises more than the team ships, and then the gaps widen until the list goes silent. Decide supply, ownership and the exit before anyone designs a header.

This skill stops at the charter. Writing or editing an issue, finding each issue's items, growing the list, inbox placement and sender authentication, and selling sponsor slots are out of scope.

## Interview

Ask one question per message, multiple-choice when possible. Stop once the charter can be filled. Never propose a shape before questions 1, 4 and 6 are answered: a cadence picked before supply and owner hours are known is a guess the team will miss. A partial answer counts as answered: carry each missing fact into the charter as a named open question.

**Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.**

1. Which mode: start a newsletter, rescue or hand over one that exists, or decide whether to stop one? "Rescue, but open to stopping" is rescue mode with stopping as the fallback.
2. Why would the company or project fund it: keeping existing users informed, reaching developers who do not use the product yet, giving contributors a shared view of the project, or ecosystem credibility?
3. Who reads it: existing users, evaluators, contributors, or the wider ecosystem? One primary reader.
4. What did you actually ship in the last three months that a reader would want: releases, posts, docs, events, community answers, ecosystem news? Ask for counts, not adjectives.
5. Which rhythm already exists: a release train, launch weeks, a weekly governance or triage cycle, a monthly community call?
6. Who owns it, how many hours per issue can they give, who is the backup, and who reviews each issue before it goes out? Who holds the sending account, the list export and the domain?
7. For an existing list: size, when it was collected and how (consent), date of the last send, and clicks, unsubscribes and replies for the last six issues.
8. Is there a date the result must land by, is this a one-off win or a compounding asset, and what is the effort ceiling in hours per month?
9. What is off-limits: unannounced features, named customers, competitor comparisons, legal review on every send?

If the user's files already hold a devrel strategy or a content calendar, read them first and ask only about the gaps.

## Choosing the programme shape

Present the shapes below in this order, say the ranking out loud, recommend one, and wait for a decision. Effort is editor hours per issue plus coordination. Durability is how well the shape survives its owner leaving. Rows are in efficiency order.

| Shape | Effort | What it buys | Survives the owner leaving | Fails when |
|---|---|---|---|---|
| Feed only: public changelog plus RSS or Atom, no email | `+++` near-zero beyond the changelog | existing users who follow feeds get every release | `+++` nothing to hand over | readers need curation, or do not use feeds |
| Own-surface digest: monthly roundup of your releases, posts, docs and events | `++` an afternoon per issue | retention of existing users, a recap around each launch | `++` any teammate can fill a fixed template from existing surfaces | your own output is thin and issues get padded |
| Curated ecosystem newsletter: your items plus external links, weekly or twice monthly | `--` a standing job, hours per issue | reach beyond your users, credibility with the ecosystem | `-` curator judgment is hard to transfer | promotional drift, or the curator leaves |
| Community-edited: volunteer section editors, submissions by pull request or form | `---` a quarter of setup, then coordination every issue | contributor ownership, the strongest long-run continuity | `+++` once running, no single person carries it | there is no contributor base, or volume outgrows the volunteers |
| Personal editorial letter: one named person's voice | `-` hours per issue | the highest trust per issue | `---` it ends with the person | the person leaves, which is its usual fate |

- efficiency: feed only > own-surface digest > curated ecosystem > community-edited > personal letter
- effort: community-edited > curated ecosystem > personal letter > own-surface digest > feed only
- reach beyond existing users: curated ecosystem > community-edited > personal letter > own-surface digest > feed only
- durability past the owner: feed only == community-edited > own-surface digest > curated ecosystem > personal letter
- compliance cost: every email shape == every other email shape > feed only

An automated new-post email sits between the first two rows on every line: no editor, so it ranks with feed only on effort and durability, but it carries every email duty, so it ranks with the email shapes on compliance cost.

The durability tie holds because neither shape depends on one person's judgment once running: the feed has no editor, and the community-edited shape spreads the editor role across a roster. The compliance tie holds because every email shape carries the same consent record, unsubscribe and sender-identity duties, whatever the content.

Feed only leads because it is the cheapest shape and has nothing to hand over: try it first, and add an editor only once the gate's demand condition holds. Default to the own-surface digest, monthly, for a vendor with steady releases. Move up to the curated ecosystem shape only after three monthly digests that each carried one trial external section whose items drew clicks.

The order starves the community-edited shape: high value, high effort, so it loses every round. Promote it when contributors already submit content somewhere, or when the project runs a weekly governance cycle the sections can mirror. Promote the personal letter only when the person is the brand and everyone accepts the newsletter ends with them.

Re-rank against the interview, and say which answer moved which shape:

- A hard date (launch, board review) promotes the own-surface digest, the fastest to stand up.
- A compounding mandate promotes community-edited and curated ecosystem.
- An effort ceiling under about four hours a month deletes every shape except feed only and a monthly digest.
- No backup available deletes the curated ecosystem and personal-letter shapes until one exists.

Delete shapes the constraints rule out, and say which ones you deleted. A deletion beats a promotion: a compounding mandate never revives a shape the backup or effort answer deleted.

## Workflow

1. **Detect the mode.** Start, rescue or hand over, or stop. Rescue and stop modes begin at step 2 with the existing list's numbers, never with a redesign. For an existing list, classify consent first (step 11) and compute every metric on the segment you may lawfully keep mailing: suppression after the gate changes the numbers the gate used.
2. **Count supply.** List what qualified in the last three months by source, own versus external. Own means written by the team; anything community members wrote counts as external, even on your own forum or chat. Split the count in two:
   - **Rate:** time-bound items per month (releases, event recaps, ecosystem news). Rate divided by items per issue, capped by owner hours, gives the fastest cadence supply supports. That cadence, not ambition, is the one the gate tests.
   - **Evergreen reserve:** items still useful two issues from now (tutorials, docs walkthroughs, community answers). The reserve, not old releases, is the buffer.
3. **Run the start-or-keep gate.** All three must hold, each with evidence:
   - The rate fills each issue's time-bound sections at the supported cadence, and the evergreen reserve covers two issues' other sections, with the restart issue counting as the first.
   - A named owner and a named backup who has agreed, with hours per issue.
   - Readers want email rather than a feed: an existing list whose clicks or replies hold at or above its own earlier level, explicit requests, or users who never see the changelog.

   Mark a condition **unproven** when the evidence is weak or missing, and make the next issue its test, with a pre-agreed threshold. A failed condition sends the programme to feed only, or to a pause, until it holds. Say which condition failed. Feed only needs a public changelog with a feed; when none exists, building it comes first (samber/developer-relations-skills@changelog-writing). Moving an existing list to feed only means one final issue that points readers at the feed, then no further sends.
4. **Choose the shape** with the menu above.
5. **Set the cadence.** Use the cadence step 2 found, then anchor it to an existing rhythm: the release train, launch weeks, or the governance cycle. When the release train is irregular, fix a calendar day and cover everything shipped since the last issue. Slow down after two consecutive thin issues; speed up only after three consecutive full ones. Never raise cadence to fix engagement.
6. **Write the curation rule.** State the own-versus-external share as a number the team chose, plus written inclusion criteria and an exclusion list that carries every off-limits item from the interview. No published industry ratio exists, so label it as a house rule. State whether paid or partner placements are accepted; if yes, each carries a "sponsored" label, meets the same inclusion criteria as editorial items, and has a per-issue cap. See [./references/published-practice.md](./references/published-practice.md) for the inclusion rules real curators publish.
7. **Fix the section template.** Five to seven sections in a fixed order. Each section names its source, its owner, its item range, and what happens when it is empty: drop it for that issue, or run a named evergreen slot. Never pad. Decide whether each issue gets a public URL and where the archive lives: a public archive outlives the list.
8. **Assign ownership.** Owner, backup, reviewer, section editors if any, hours per issue, where the runbook lives, and the handoff checklist. The sending account, list export, domain and archive belong to the organisation, never to a personal account or card. Name the running cost (sending platform tier, domain, editor hours) and the budget line that pays it.
9. **Set measurement.** Primary signals are click-based: clicks per delivered email, unique clickers across the last N issues, unsubscribes and complaints, replies. Add one outcome signal mapped to the funding answer (question 2): feature adoption from newsletter links for retention, signups from non-users for reach, submissions per issue for contributors, inbound external submissions and pickups by other newsletters for credibility. Exclude machine clicks: corporate mail gateways follow links on arrival to scan them, so enable the platform's bot-click filter, or discard clicks within seconds of delivery and sends where every link was clicked, and report the filter used. Open rate, click-to-open and open-based reach all move with machine opens from mail-privacy features: report them as directional, never as a target. Review quarterly against the team's own trend. A restarted or new list has no trend yet: take the last issues before the pause as the baseline, and label any threshold set from it as a house rule.
10. **Write the pause and sunset rules.** Pre-agree the triggers, and the action each one fires (see below).
11. **Check consent.** The newsletter runs as its own consented stream, separate from transactional and account email. State how the existing list was collected. Product signups added to the list need a lawful basis segment by segment: US mail needs no prior consent but a working opt-out honoured within 10 business days, a postal address and honest headers; UK and EU individual addresses need consent or a valid soft opt-in (existing customer, similar product, opt-out offered at signup); rules for business addresses differ by country. Suppress only the segment with no basis, invite it once through the product rather than by email, and send the call to whoever owns privacy. Set a standing inactive rule as a house rule: subscribers with no human click and no reply in twelve months, after bot-click filtering, get one re-confirmation, then suppression.
12. **Present and record.** Open with a direct answer to the question the requester actually asked ("should we go weekly?"), then present the charter section by section (gate, shape, cadence, curation rule, template, ownership, measurement, exit), and get each validated before the next. If your environment has persistent memory, store the charter's decisions so the next run starts from them.

## Pause and sunset rules

Pre-agree these before issue 1, or before the rescue restarts sending. A newsletter without them decays silently: gaps widen, then the list stops, and nobody decides anything.

| Trigger | Action |
|---|---|
| Owner leaves and the backup cannot take over within one cycle | Send a short hiatus note, then hand over with the checklist or downgrade to feed only |
| Two consecutive thin issues (step 5) | Drop to the next slower cadence, or merge into the changelog |
| Clicks and replies fall for two consecutive quarters against your own trend | Re-run the gate; the readers' need may have moved to another channel |
| The need moved: a forum, chat or feed now does the job | Close with a final issue that points readers to the replacement |
| Running cost has no budget line | Close or downgrade before the owner starts paying personally |
| List silent for more than six months | Send a re-permission issue first; suppress non-responders |

Announce every pause. Never skip an issue silently.

## Pass thresholds

Revise the charter until all of these pass:

- The gate states all three conditions with evidence, and the result.
- Cadence is derived from the time-bound rate and owner hours, with an evergreen reserve covering two issues at launch.
- The curation rule is a stated share plus written criteria, labelled as a house rule.
- Every template section has a source, an owner, an item range and an empty-section rule.
- Owner and backup are named people, and every account is held by the organisation.
- No open-derived metric (open rate, click-to-open, open-based reach) is a primary metric, and one outcome signal matches the funding answer.
- Every pause and sunset trigger has a threshold and an action.
- The list's consent provenance is stated, and the newsletter stays out of transactional email.

State which thresholds failed and what changed, rather than rebalancing silently. When a threshold fails only for a fact the user has not supplied, mark it **blocked**, name the missing fact and its owner, and set a dated re-check. Never invent the fact to pass it.

## Invocation examples

- _"Should we start a developer newsletter? We ship a release every two weeks and blog twice a month."_ Run the interview, then the gate.
- _"Our writer left, the monthly newsletter has 4,000 subscribers and 18% opens. Fix it."_ Rescue mode: count supply, run the gate, assign owner and backup before any engagement work.
- _"Nobody reads the newsletter, can we kill it?"_ Stop mode: run the gate and the sunset table, then plan the final issue or the downgrade.

## Output shape

A short programme charter: a direct answer to the requester's question, then eight sections, **gate result**, **shape**, **cadence and rhythm anchor**, **curation rule**, **section template**, **ownership and handoff**, **measurement**, **pause and sunset rules**. The template section is a table:

| Section | Source | Owner | Items | When empty |
|---|---|---|---|---|
| Shipped this month | changelog | A. (backup B.) | 3-5 | merge into "In brief" |

Close with the open questions and the pass-threshold result. A worked rescue charter, plus a negative example, is in [./references/charter-example.md](./references/charter-example.md).

## Failure modes

| Symptom | Cause | Fix |
|---|---|---|
| Gaps between issues widen, then silence | One person carried the send | Name a backup, move accounts to the organisation, write the handoff checklist |
| Issues padded with filler | Cadence set above supply | Re-count supply, slow the cadence |
| Readers treat it as an ad | Own content only, no inclusion rule | Write a curation rule with external items and labelled self-promotion |
| "Low open rate" drives the plan | Opens inflated or blocked by mail-privacy features | Switch to clicks per delivered email, unique clickers across the last N issues, and replies |
| Successor rebuilds from scratch | No fixed template or runbook | Fix the sections and the checklist before the next issue |
| Unsubscribes and complaints spike | Product signups added to the list | Separate streams, confirm consent provenance |
| The list sent nothing for months | No pause rule | Announce a hiatus, then restart with a re-introduction issue or close |

## Benchmarks

Context, never targets. Software senders' median click rate sits near 1% per send, and open-based figures are inflated by mail-privacy features. Published figures, their sources and limits are in [./references/published-practice.md](./references/published-practice.md) section 8.

## References

- [./references/published-practice.md](./references/published-practice.md) - cadences, templates, inclusion rules, handoff and shutdown stories, benchmarks and consent rules from real developer newsletters
- [./references/charter-example.md](./references/charter-example.md) - worked rescue charter and a negative example
- samber/developer-relations-skills@devrel-newsletter-issue - writing each issue against the charter's template
- samber/developer-relations-skills@devrel-content-calendar - newsletter issues consume the same writer and reviewer capacity
- samber/developer-relations-skills@devrel-metrics - which newsletter signals count toward the devrel framework
- samber/developer-relations-skills@devrel-newsletter-deliverability - authentication, warm-up after a pause, bounce handling and spam-folder diagnosis
- samber/developer-relations-skills@build-in-public - the newsletter as one owned anchor surface
- samber/developer-relations-skills@developer-community-health - whether a contributor base exists for the community-edited shape
- samber/developer-relations-skills@devrel-newsletter-growth - growing and keeping the list once the charter holds
- samber/developer-relations-skills@devrel-newsletter-sourcing - finds and gates each issue's items against this charter