How we curate

Every listing on devrel.directory is reviewed by a person before it goes live, re-checked by automation on a schedule afterwards, and removed when it stops being true. This page states those rules as they are actually enforced, so you can judge how much weight to give what you find here.

What gets a listing

The directory lists tools, communities, newsletters, podcasts, and agencies. Three things have to hold:

• Relevant to DevRel practitioners. The entry has to be something a person doing Developer Relations work would reach for: running a program, a community, docs, content, events, or measurement. General-purpose products with no specific DevRel use do not qualify, however good they are.
• Live and operating. The link must resolve to an operating product or community, and it must keep resolving: the same bar is re-checked automatically for as long as the listing exists.
• Hand-reviewed. Every listing goes live only after the maintainer has looked at the product and written or edited the entry. Nothing is auto-imported.

A listing cannot be bought, and submitting is free. New listings only ever arrive through submissions and the maintainer's own research; the automated pipeline described below is structurally unable to add one - it can only update or remove what a person already accepted.

The health pipeline

Once a week, an automated run re-checks every listing in the directory:

• Link health. Each listing's URL is fetched. A dead link (HTTP errors, network failures), a parked domain (matched against registrar-lander fingerprints), and a redirect to an unrelated domain are each recorded. Rate limiting is deliberately not held against a listing: an HTTP 429 proves a live origin.
• A strike, not an instant removal. A dead or parked observation is a strike. Removal is only proposed after two separate weekly runs observed the problem, so a one-day outage can never delete a listing. A listing that recovers has its strike cleared.
• Drift review. For pages that answer, the live page's own title and description are compared against the stored description. A description the product has outgrown gets a proposed rewrite; a product that pivoted into something else gets a removal proposal.
• Moved sites. A redirect to a domain that is recognizably the same project becomes a proposed URL update; anything else is flagged for human review instead of silently rewritten.
• A human reviews every change. The run's entire proposal - updates, removals, and flags - lands as one pull request that the maintainer reads and either merges or rejects. Nothing the pipeline decides reaches the site without that review.

The Verified badge on a listing shows the month this pipeline most recently confirmed the link resolved to a live product page. A listing without the badge has simply not been confirmed by a run yet; a listing that keeps failing the check leaves the directory.

Jobs rules

The job board follows the same discipline with sharper deadlines:

• DevRel-family roles only. Candidates scraped from the public job boards of watched companies pass a DevRel title filter and an automated triage before the maintainer reviews them; submitted and paid postings are added by hand and held to the same bar. Adjacent engineering roles do not qualify.
• Every posting expires. A job listing runs for at most 60 days from its posting date, no exceptions, so a stale opening cannot linger.
• Twice-weekly liveness checks. Listed jobs are re-checked against the company's own board twice a week; a posting that has closed is proposed for removal in that run's pull request.
• Salaries are verbatim or absent. Stated pay is carried straight from the posting (a range may render in compact form, like $128k-187k); a posting that states no pay shows none. Figures are never estimated, inferred, or filled in from market data.

Money and editorial judgment

The two never touch:

• Directory placement is never paid. There is no price at which a listing, a description, a tag, or a position in the directory can be bought.
• Featured job posts are the only paid product, and the label travels with the pin. A featured post is pinned to the top of the job list on every surface that carries it: highlighted and tagged "Featured" on the job board, labeled a paid placement in the machine-readable corpus, and flagged featured by the MCP server. Payment buys that placement for 30 days - nothing about the posting's content, and nothing in the directory.
• Editorial verdicts are never sold. Descriptions, removals, alternatives, and any "Our take" note reflect the maintainer's judgment of the product, dated so you can tell how current that judgment is. No part of that judgment is available for sponsorship.

Corrections and submissions

If a listing is wrong, out of date, or missing, contributing explains how to submit a fix, a new entry, a job, or an event - every submission lands in the same review process described above.