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.

Salary figures

A single posting shows the pay it states, as above. The aggregate figures - the median band on the job board, the figures on DevRel salary data, and the salary block the MCP server returns - are derived from those stated numbers by these rules, and nothing else:

• USD only, never blended. A role counts toward the figures only if it states pay in USD; a stated amount with no currency is read as USD. Roles quoted in other currencies are left out rather than converted, so no exchange rate ever enters the numbers.
• Live postings only. The sample is the roles active on the board that day. Because every posting expires within 60 days, the figures move as the board turns over - they describe what is open now, not a market history.
• The median is taken over per-role midpoints. A role stating a range contributes the midpoint of that range; a role stating a single bound ("$150k+", "up to $90k") contributes that bound. The quoted minimum and maximum are the lowest and highest bounds any role in the sample states.
• The sample size travels with the figure. Every aggregate carries n, the number of roles disclosing pay. Below 20 the job board drops its salary headline entirely rather than caveat it, because the sample is senior-skewed and the median swings by double digits when one posting enters or leaves. The MCP server still returns the figures at lower n, flagged as a small sample, so an agent can see them and judge for itself.

These rules cover how the numbers are computed. What the sample is drawn from, what it leaves out, and why an advertised range is not the same thing as pay are set out in full on the salary page's methodology, which is the published statement the aggregate figures point at.

Talks: works, not persons

The talks index records conference talks, and it is built so that it cannot quietly become a database of people.

• We index works, not persons. There is no speaker field in the data, no speaker page, no speaker filter, and no way to query the index by person. A conference publishes a talk under a title that usually names its speaker, so attribution survives inside the title exactly as the conference wrote it - but nothing here turns that into a separate, sortable record of an individual.
• This is enforced, not just promised. The data checks that run on every change fail the build if a person-identifying field is added to a talk, if a talk's identifier is derived from its title rather than its video, or if any route on the site is keyed by a person.
• Every row is checked against the publisher. A talk enters the index only after it has been matched against the conference's own published playlist and confirmed still available at the publisher's own link. Titles are stored verbatim, typos included, so each row still matches the source it quotes.
• We host nothing. Every talk links out to the video on the conference's channel. This is an index with links, the way a bibliography is.

Removal takes three business days at most, usually the same day. If you spoke at an indexed talk and would rather not appear, mail the address on our privacy page. No reason is needed and none will be asked for. Removed talks are recorded in a suppression list that fails the build if the same talk is ever re-added, so a later bulk import cannot quietly undo a removal. That list is a backstop for this site only - it does not, and cannot, remove anything from the conference's own channel.

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.