The Maintainer Outreach Acceptability Standard: Send, Revise, or Hold

Before you send a message to an open-source maintainer, you need to know whether it will be read or reported. This standard is for engineering managers, technical founders, developer-relations leads, and technical sourcers who draft outreach to maintainers and want a fixed bar for what is acceptable to send. It converts scattered, maintainer-stated norms into a gradeable checklist that returns one of three verdicts - Send, Revise, or Hold - that two teammates reach independently.

The published library already covers how to find maintainer contacts and how cold cadence works. This document covers the one thing those do not: whether a specific drafted message clears community norms before it leaves your outbox. The goal is a verdict two graders agree on, not a vibe.

Why a maintainer message needs its own acceptability bar

A maintainer message needs a fixed bar because the cost of getting it wrong is not a low reply rate - it is a block, a flag, or a repository interaction limit that removes your access entirely. Generic "be nice" advice does not tell you where the line is, and it does not let two people grade the same draft the same way.

The scarcity that drives every rule here is attention, not politeness. One full-time maintainer reports fielding more than 200 notifications every 12 hours, all expected to be answered. A private message does not save that person time; it jumps the public queue and moves triage cost onto one individual who, in 60% of cases per the Tidelift 2024 survey, is not paid for the work at all.

There is a second, newer reason the bar has moved. After the xz-utils incident, 66% of maintainers report trusting pull requests from non-maintainers less. An unsolicited private message paired with code now pattern-matches to a social-engineering approach, whether you intend that or not. Public, low-ask engagement first is no longer just polite; it is the pattern that reads as legitimate.

The channel priority order maintainers actually publish

Contact routes through repository files, not the maintainer's inbox, and public channels always beat private ones. GitHub's own guidance names four documents to read before you contact anyone: the README for project overview, the Code of Conduct for behavior standards, CONTRIBUTING for contributor guidelines, and the project's designated communication channels for where to ask for help.

No single ranked ordering is published anywhere, so treat the following as the de facto order assembled from the sources. The SUPPORT file is the designated help-routing document; it works like CONTRIBUTING, can live in the repo root, .github/, or docs/, and is shown above the new-issue form to point users to forums, FAQs, or corporate support.

The Open Source Guides are explicit that public wins: wherever possible, do not take conversations to private channels, including contacting maintainers directly, because keeping communication public means everybody benefits. Note a practical detail if you are reading CONTRIBUTING: when multiple files exist, GitHub shows the one chosen in order of the .github directory, then root, then docs. Read the one that renders.

The named behaviors that get a message flagged

Five behaviors are documented by maintainers as unacceptable, and each is a specific, checkable fail rather than a matter of taste. Learn them as fail conditions, because they are what convert a hopeful message into a reported one.

Each of these has a lie to watch for. A bump can disguise itself as a question - "Any update?" adds no new information, so it fails even though it ends in a question mark. An @-ping justifies itself as "just looping them in" while pinging a top committer who never engaged that exact thread. If the mention is not for someone who previously engaged that issue, remove it.

The enforcement side is real and fast. A maintainer can block you, which denies access to their activity and repositories and stops your notifications reaching them. Anyone visiting your profile can select Block or Report, choose Spam or Harassment, and route it to GitHub's Trust and Safety team. Owners, collaborators, prior contributors, and people with write access can report issues, pull requests, discussions, and comments. Maintainers can also pre-empt you entirely by limiting repository Interactions to existing users or collaborators only.

Why you cannot source maintainers by job title

You cannot find maintainers by searching for the title, because almost nobody holds it. Maintaining is unpaid side-work attached to repo activity, not a line on a resume, so it lives in commit history rather than in headlines.

The gap is stark in Refolk's index of professional profiles. Only a handful of people anywhere carry a Maintainer-type title while listing Open Source as a skill, even though the skill itself is common.

Set that against the population that actually lists the skill. In Refolk's index, 3,583 senior and 5,037 entry-level US professionals list Open Source as a skill, a combined 8,620 across the two bands. The nine US maintainer-titled profiles are roughly 0.10% of that group.

number: ~0.10%
label: Share of US Open Source-skilled professionals with a Maintainer title
note: In Refolk's index, 9 maintainer-titled profiles against 8,620 across the senior and entry bands.