# The Maintainer Outreach Send Standard: Grade a Draft Before You Send

*You will be able to grade any draft outreach to an open-source maintainer as send, fix, or kill against explicit criteria that two reviewers apply the same way.*

- Canonical URL: https://www.refolk.ai/guides/maintainer-outreach-send-standard
- Pillar: Engineering and open source
- Format: Standard
- Published: 2026-08-01
- Last reviewed: 2026-08-01
- Reading time: 15 min

Deciding whether a message to an open-source maintainer is ready to send is a grading job, not a writing job. This standard is for technical sourcers, engineering managers, and developer-relations leads who need to judge a specific draft before it goes out, and it gives you explicit pass or fail criteria so two reviewers reach the same verdict. Adopt it as team policy and a bad draft gets caught before it burns a contact you cannot easily replace.

Most pages on this topic argue about why developers ignore recruiters. This one instead tells you how to grade a draft as **send**, **fix**, or **kill** against documented community norms and the reply-rate evidence behind them. The output is a checklist you can hand to a second reviewer.

## Why maintainer outreach needs a definition of done

Maintainer outreach needs a gradeable standard because the audience is scarce, reads the etiquette guides you are supposed to follow, and blocks first. A generic message does not just underperform; it removes a near-irreplaceable contact from your reach.

The scarcity is measurable. In Refolk's index of professional profiles, there are roughly 21,038 US technical recruiters and sourcers against about 1,402 people who self-identify as open-source maintainers. That is roughly 15 recruiters chasing every maintainer. Narrow to a specific skill and the pool collapses: filtering US maintainers to those with Rust skill returns only about 4 profiles.

**~15 - US technical recruiters and sourcers per self-identified US maintainer, in Refolk's index**

Derived from ~21,038 recruiters against ~1,402 maintainers; the ratio is why a generic blast is expensive.

When the contact is that rare, precision is not a nicety. A single mis-sent message can close a channel you will not find another way into. That economics forces the one-shot discipline this standard encodes: you get the draft right, or you do not send it.

There is a second reason the standard has to be explicit. Maintainers read the same community guides that define good and bad contact. When you break a documented norm, you are not just annoying one person; you are signalling to someone fluent in those norms that you ignored them. The penalty is a block, and word travels in small communities.

> When there are fifteen recruiters per maintainer, a generic message does not underperform. It removes the contact.

## The three inputs that decide send, fix, or kill

Three inputs decide the verdict: whether you used a channel the maintainer designated, whether that channel and address are legitimate rather than scraped, and whether the message carries one specific signal the person did not expect you to know. Miss any one and the draft is not ready.

No published, gradeable send-hold-kill rubric for maintainer outreach exists, so the checklist here is the novel contribution. But every criterion in it rests on documented norms, not opinion. The three load-bearing inputs break down like this.

**Channel.** GitHub supports a defined set of community health files that projects use to route contact: CONTRIBUTING, SUPPORT, CODE_OF_CONDUCT, ISSUE_TEMPLATE(S), and PULL_REQUEST_TEMPLATE(S). A maintainer who wants inbound routes it through one of these or through a personal channel they list. Using anything they did not designate fails the channel test.

**Legitimacy.** The address must be one the person published about themselves. Commit-log emails decay because contributors rotate them and often mask them with the `username@users.noreply.github.com` format. An address that parses fine but exists only in git history is not legitimate contact.

**Signal.** The content must contain something specific the person did not expect you to know. First-name insertion does not qualify. Personalization earns a reply when it grounds the message in a project they led, a contribution they shipped, or a move they just made.

#### The three inputs, outermost gate first

1. **Channel** - Did the maintainer designate this route for inbound
2. **Legitimacy** - Is the address one they published, not scraped from commits
3. **Signal** - Does the message name something specific they did not expect you to know

*A draft must clear the outer gate before the inner ones matter; a right channel with no signal still fails.*

## The personalization evidence behind the signal criterion

The signal criterion exists because reply rate roughly doubles with each layer of personalization, making a single real signal the highest-leverage edit on any draft. Moving from a template to a specific trigger is a five-to-ten-times swing on the same send effort.

The aggregated benchmark bands make the gradient concrete. These figures are not maintainer-specific, and the dossier is explicit that no equivalent numbers for open-source maintainers are publicly established, so treat them as planning bands rather than promises.

| Personalization level | Reply rate |
| --- | --- |
| No personalization | 1-3% |
| Basic (name/company/title) | 5-9% |
| Advanced (pain points/recent news) | 9-15% |
| Signal-based (specific trigger) | 15-25% |

A separate benchmark reports high-volume cold campaigns averaging around 2.1% replies against close to 5.8% for smaller, more targeted sends, a two-to-three-times gap on the same effort budget. Named research from interviewing.io reports one to two orders of magnitude more responses from cold outreach to hiring managers than from online applying alone. The direction is consistent even where the exact numbers vary by source.

> **Rule:** A signal is a fact, not a compliment
>
> The message must name a specific pull request, issue, or release the person authored. "Love your work" is flattery and reads as scraped. If you cannot cite something concrete, the draft is a fix, not a send.

What none of these sources establish is the effect of specific missing elements, such as an unstated salary or the wrong stack, on developer replies in particular. Where the standard requires salary and stack in the message, that is a norm this document adopts to reduce friction, not a figure the dossier proves. State it as policy and say so.

## The procedure: grade a draft in seven steps

Grade a draft by working the channel and legitimacy checks first, gathering one signal, then submitting the message to a second reviewer who reaches the same verdict blind. The whole pass takes about 40 minutes and ends with a scheduled follow-up ceiling.

#### From blank draft to sent, or killed

1. **Locate the designated channel** - Check SUPPORT.md, CONTRIBUTING.md, the README, then the profile bio or linked site, in that order. Done when you have a channel the maintainer published for inbound.
2. **Confirm the channel permits your message type** - Read CODE_OF_CONDUCT and CONTRIBUTING for scope limits, and route recruiting to a listed personal email or LinkedIn, never the issue tracker. Done when no rule forbids your message type.
3. **Verify the contact is current, not scraped** - Prefer a profile, bio, or MAINTAINERS-file address over any commit-log email. Done when the address is one the person published about themselves.
4. **Gather one specific signal** - Read a real merged pull request, issue, or release the person authored. Done when you can name a specific contribution without flattery.
5. **Draft against the checklist** - Include one company-specific observation, one concrete credential, salary and stack, and one low-friction ask. Done when every pass criterion is met.
6. **Get a second-reviewer verdict** - A second person grades the same draft blind. Done when both reviewers reach the same send, fix, or kill verdict.
7. **Set the follow-up ceiling before sending** - Schedule at most one brief follow-up. Done when the sequence is capped at the initial message plus one follow-up.

The second-reviewer step is what makes this a standard rather than a habit. If two people grade the same draft and disagree, the criteria were applied loosely, and the draft goes back regardless of which reviewer preferred to send. Agreement is the deliverable.

The hard part of steps one through four is finding a legitimate, current contact and a real signal without scraping. That is exactly the search Refolk is built for: you describe the person and the evidence you need in plain English instead of stitching together commit logs and stale exports.

I ran this search: `Rust maintainers in the US who merged pull requests in the last 90 days and list a contact email in their profile` - [see the full result list](https://www.refolk.ai/s/42ps3mra00).

*Returns maintainers with recent, verifiable activity and a self-published contact, so steps three and four are already satisfied before you draft.*

Using [Refolk](/) at the front of the procedure means the address you get is one the person listed and the activity you cite is real and recent, which removes the two most common ways a draft fails legitimacy and signal at once.

## How this goes wrong: the failure modes

Most rejected drafts fail on one of seven predictable errors, and the dangerous ones are the false positives, where a broken draft looks correct. Learn to spot the check that catches each and your send rate rises without any change to volume.

The first and most common trap is the wrong channel passing as public. A sourcer posts a recruiting pitch as a GitHub issue because the norm says "keep it public." But that norm covers project questions, not job offers. Maintainer guidance is explicit: resist the temptation to communicate about your project in private, and direct people to a designated public channel. That governs support requests. Recruiting is inherently one-to-one, so it belongs in the maintainer's listed personal email or LinkedIn, never the issue tracker.

> **Watch out:** "Keep it public" does not mean post your job pitch publicly
>
> The public-channel norm exists so support traffic does not drown a maintainer's inbox. Applied to recruiting it backfires: a job offer in an issue tracker is worse than a private note, not better. Ask whether the channel is for the project or for the person.

The table below is the full set of failure modes with the check that catches each and the verdict it produces.

| Failure mode | The check | Verdict if it fails |
| --- | --- | --- |
| Recruiting pitch posted as a public issue | Is this channel for the project or the person | Kill |
| Address found only in the git log | Did the person publish this address themselves | Kill |
| @-mention added to force a reply | Remove every handle aimed at pressuring | Fix |
| First-name merge sold as personalization | Delete the name token; anything project-specific left | Kill if nothing remains |
| Flattery instead of a real signal | Can you cite a specific PR, issue, or release | Fix |
| Second follow-up scheduled | Is the sequence capped at one follow-up | Kill |

Two of these deserve extra weight. The scraped commit email is structurally unreliable, not merely impolite: contributors deliberately mask addresses and rotate them, so the address decays over time. The kernel's own get_maintainer.pl derives contacts from commit history and still surfaces invalid addresses. If an address appears only in git log, kill the draft and find a published one.

The @-mention trap catches people who think tagging is helpful escalation. GitHub's contribution docs are direct: do not directly mention the handles of maintainers. The same guidance tells contributors chasing a pull request to follow up with a polite comment rather than mentioning handles. Remove every @handle whose only purpose is to prompt a reply.

The first-name merge is the false positive that fools the most disciplined teams, because the message looks personalized. The test is mechanical: delete the name token. If nothing project-specific remains, it is a template, and templates sit in the 1-to-3-percent band. That is a kill, not a fix.

## The follow-up ceiling and why it is one

The follow-up ceiling is one message, and it is a hard rule rather than a preference because your audience wrote the etiquette. The professional standard is an initial email plus one brief follow-up; a third message to the same person usually reads as pressure.

This ceiling matters more for maintainers than for a general candidate list. Maintainers read the same community guides that call a persistent sequence pushy, so a third touch does not just risk a non-reply. It confirms to someone fluent in those norms that you ignored them. The cost compounds with the scarcity: you do not have fifteen more Rust maintainers to spend on a sequence.

> **Rule:** A scheduled second follow-up is an automatic kill
>
> Cap every sequence at the initial message plus one follow-up. If your tool has a second follow-up queued, the draft does not pass this standard until you remove it. This is not negotiable per campaign.

Set the ceiling before you send, not after the first message goes quiet. Deciding in the moment, when a maintainer has not replied and you want the seat filled, is exactly when the discipline slips.

## A copy-pasteable draft and the rubric to grade it

A passing draft carries one company-specific observation, one concrete credential of the person's, salary and stack stated, and a single low-friction ask. The template below is the skeleton; the rubric after it is what your second reviewer scores against.

**Maintainer outreach skeleton**

```
Subject: Your work on [project] and a role that maps to it

Hi [first name],

I read your merge of [specific PR or release, by number] on [project]
and the way you handled [specific detail you could only know by reading it].

I'm hiring for [role] at [company]. The stack is [languages/tools],
and the range is [salary band]. The part that maps to your work is
[the concrete overlap].

If it's worth a look, I can send the full brief. No pressure either way,
and I won't chase this beyond one follow-up.

[name]
[the channel they designated]
```

*Replace the bracketed signal with a real PR, issue, or release you actually read. If you cannot, the draft is not ready.*

The salary and stack lines are policy this standard adopts to cut friction, not a figure the dossier proves changes developer reply rates. State them anyway. A message that hides the range asks the maintainer to spend effort finding out whether the role is even in their band.

#### Send, fix, or kill on two axes

Horizontal axis runs from Wrong or scraped channel to Designated, legitimate channel. Vertical axis runs from No real signal to One specific signal.

| Quadrant | What it means |
| --- | --- |
| Fix the channel first | Right message, wrong route; move it to the listed contact before sending |
| Kill | No signal and no legitimate route; nothing to salvage |
| Send | Legitimate channel and a real signal; grade with the checklist and go |
| Fix the content | Right route, but flattery or a name merge; add a real signal |

*A draft is only a send when the channel is legitimate and the message carries a real signal.*

#### Before you hit send

- [ ] The channel is one the maintainer designated in SUPPORT, CONTRIBUTING, README, or their profile
- [ ] Recruiting is routed to a personal email or LinkedIn, not the issue tracker
- [ ] The address is one the person published, not one found only in the commit log
- [ ] No @-mention of any maintainer handle appears anywhere in the message
- [ ] The message cites a specific PR, issue, or release, not flattery or a first-name merge
- [ ] Salary band and stack are stated in the message
- [ ] There is exactly one low-friction ask
- [ ] The sequence is capped at the initial message plus one follow-up
- [ ] A second reviewer graded the draft blind and reached the same verdict

## Keeping the standard current on your team

Keep this standard useful by re-checking two things periodically: whether GitHub's designated community health files have changed, and whether your team's actual reply rates track the planning bands. Both are mechanisms you can verify locally rather than numbers to trust forever.

The channel rules rest on GitHub's community health file set and its explicit guidance against mentioning maintainer handles or contacting them privately. These conventions change slowly, but they do change. Re-read the current community health files documentation and the contribution guide before adopting the checklist as written, and update the channel step if the recognized file set has shifted.

The reply-rate bands are aggregated benchmarks, not maintainer-specific figures, and the dossier is explicit that maintainer-specific numbers are not publicly established. The right move is to instrument your own sends: tag each message by personalization depth, measure the reply rate per band over a quarter, and compare against the 1-to-3, 5-to-9, 9-to-15, and 15-to-25 planning bands. If your signal-based sends do not clear your basic sends by a wide margin, the problem is usually that your signals are flattery in disguise. Re-run the name-token deletion test on a sample.

| Segment | Count in index |
| --- | --- |
| All self-identified US maintainers | ~1,402 |
| US maintainers with Rust skill | ~4 |
| Rust share of maintainers (derived) | ~0.3% |

Let that scarcity set your posture. With roughly 15 US recruiters per maintainer and a skill filter that can leave you a handful of names, this is not a channel where volume compensates for care. The standard exists so that every message you send to a maintainer is one you would be comfortable defending to the person who wrote the etiquette they read. Grade every draft, keep the follow-up ceiling firm, and let the second-reviewer verdict be the thing that decides, not the pressure to fill the seat.

## Frequently asked questions

### Is it OK to open a GitHub issue to reach a maintainer about a job?

No. The public-channel norm on GitHub covers project questions and support requests, not solicitation. A recruiting pitch posted as an issue lands job traffic in a tracker built for the project, which reads as norm-breaking rather than respectful. Route recruiting to the maintainer's listed personal email or LinkedIn, which is the correct private channel for one-to-one contact. Keep the issue tracker for the project.

### Can I use the email from someone's git commit history?

Only if the same address appears somewhere the person published about themselves, such as a profile, bio, or MAINTAINERS file. Commit-log addresses decay because contributors rotate emails and often mask them with the username@users.noreply.github.com format. Kernel maintainers built get_maintainer.pl from commit history and still surface invalid addresses. If an address exists only in the git log, treat it as a kill.

### What counts as real personalization versus a template?

Real personalization grounds the message in something specific the person did not expect you to know: a project they led, a pull request they merged, a release they shipped. First-name insertion does not qualify. The test is simple: delete the name token, and if nothing project-specific remains, it is a template. Benchmark bands put signal-based outreach at 15 to 25 percent reply rate against 1 to 3 percent for no personalization.

### How many follow-ups are acceptable?

One. The professional standard is an initial message plus one brief follow-up. A third message to the same person usually reads as pressure. This ceiling is firm because maintainers read the same community guides that call a persistent sequence pushy, so ignoring it signals you disregarded their norms. A scheduled second follow-up is an automatic kill under this standard.

### Should I @-mention a maintainer to get their attention?

No. GitHub's own contribution docs state plainly: do not directly mention the handles of maintainers. Tagging feels like helpful escalation but reads as pressure. Remove every @handle aimed at prompting a reply before sending. This applies to follow-ups on pull requests as much as to any outreach.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/maintainer-outreach-send-standard*