The Developer-Authority Signal Reference: Talks, Writing, and Standards

This is a lookup document for reading non-code reputation signals: conference talks, technical writing, standards authorship, and community roles. It is for engineering managers, technical founders, developer-relations leads, and technical sourcers who need to decide whether a person is a genuine authority, and whether a company employs enough authorities to be a real talent magnet. Jump to the row you need. Each signal comes with what it proves, what its faked version looks like, and how long it stays valid.

Code artifacts are well covered elsewhere. What is not catalogued is everything that happens off the commit graph, where the strongest credentials live and where the fakes are easiest to buy. The core problem is that the best signals are invisible in the places people usually look.

Why bios are the wrong place to read authority

The highest-trust authority signals almost never appear in self-written headlines, so you must verify them from primary records rather than scraping them from profiles. This is not a hunch. It is measurable.

In Refolk's index of professional profiles, 0 senior US profiles and 0 senior UK profiles carry a headline that pairs "conference speaker" with "standards/RFC author." Against that, 1,529 US profiles carry an open-source maintainer-type title. The people who have shaped an RFC or delivered a reviewed talk are precisely the ones who do not brag about it in a one-line bio.

The practical consequence: if your evaluation starts and ends at the bio, you will systematically miss the strongest candidates and overweight the loudest ones. The maintainer title is self-declared often enough to be noisy. Speaking and standards work are self-declared so rarely that their absence from a headline tells you nothing, and their presence in a primary registry tells you everything.

The strongest credentials are the ones nobody puts in a headline, so the headline is not the evidence.

So the method below never trusts a claim on its face. Every signal resolves to a URL from a primary source, a role confirmed within that source, and a date.

The signal reference: what each proves and how it lies

Each non-code signal proves something specific and fails in a specific way. Read the row you need, then confirm it against the primary record named in the next section.

Two rules run through the whole table. First, association is not authorship: attending a working group, sponsoring a conference, or being thanked in a spec is not the same as writing the thing. Second, attention is not ability: stars and followers measure reach, not code quality.

CFP-reviewed talk

A call for papers, or CFP, is the open submission process a conference runs to select talks. A CFP-reviewed talk proves that independent reviewers judged the content worth a slot. It lies when the slot was purchased. Pay-to-play, in the practitioner definition, is an organization or person who writes a check and receives stage time as one of the benefits, where stage time ranges from a five-minute marketing slot to a full-session buyout. Some events go further and sell keynotes to the highest bidder. The norm among speakers is blunt: you never pay an event to speak, travel costs aside.

RFC and standards authorship

The IETF Datatracker is the public front-end to the IETF database, holding documents, working groups, meetings, agendas, and minutes. RFC authors are listed on the front page of the document and in public bibliographies. On the W3C side, only editors are listed on the /TR page or in the document header, and other contributors are relegated to an appendix. Neither body formally defines "author," which is exactly why you must read the role field yourself rather than trust a summary.

Indexed papers and identity

DBLP indexes ACM and IEEE proceedings, more than 2.1 million articles, with links to author home pages. Its risk is the name collision: two people share a name, and one gets credited with the other's work. DBLP links an ORCID, a 16-digit persistent researcher identifier, to a person record only when it has manually verified that the bibliography and the ORCID represent the same person. Use those confirmed links, not auto-harvested ones.

Where to verify each signal

Every signal in this reference resolves to one of a small set of primary registries. Use the registry, not a self-report or a secondary summary.

DBLP's disambiguation is strong but not perfect: it reports a 0.952 K-metric and 0.96 Pairwise F1 on author-name disambiguation, and it has linked 115,843 ORCID identifiers to 707,137 author-name instances. That gap between identifiers and instances is the reason to prefer a confirmed ORCID over a bare name match every time.

Refolk sits between the top and bottom of that stack: you ask for the people you want in plain English, and it resolves them across GitHub, LinkedIn, and the open web so you can jump straight to the primary record instead of hunting for who to check.

The procedure: verifying one signal end to end

Run these seven steps in order for any single signal, whether you are grading a person or building a company view one authority at a time. The whole pass takes under 90 minutes for a person.

Sources disagree on ordering at the company level. Recruiter guides put community reputation-building first, as a 12 to 24 month effort. Hiring guides start from the individual artifact. For evaluation rather than brand-building, start from the artifact: it is the checkable unit.

The pay-to-play filter as a document check

Whether a talk was earned or bought is a binary you can settle from documents, not a judgment you form from watching it. Because pay-to-play is defined as stage time exchanged for a check, the presence or absence of two documents decides the question: an open CFP, and a sponsorship line naming the speaker's employer.

Read the CFP first. Practitioners advise it because the CFP governs both selection and how, or whether, a speaker is compensated. A strict education-only event and one that sells keynotes to the highest bidder produce visually identical talks; the CFP and sponsor list are what separate them.

Three outcomes: CFP-reviewed means reviewers chose it; invited means organizers named the speaker without a payment; purchased means the slot came with money attached. Only the first two are authority signals. The third tells you the company had marketing budget.

How long a signal stays valid

No standards body publishes a signal-specific shelf life, so set expiry from skill half-life. The half-life of technical knowledge has collapsed over a century, and that collapse is the mechanism behind every re-verify-by date you attach.

A flagship talk on a stack that has since turned over is a historical credential, not evidence of current authority. Set the expiry to the shorter end for fast-moving fields. For AI work, treat a signal older than about two years as needing a fresh artifact before you rely on it; for general backend or infrastructure work, 2.5 to 5 years is defensible.

The date-stamp is not bureaucracy. It is what stops a five-year-old credential from carrying a hire decision it can no longer support. Every row in your evaluation should read: what proves it, the URL, verified on, re-verify by.

Aggregating to a company: real magnet or rented logos

A company is a talent magnet when it employs several distinct verified authorities in communities relevant to its stack, not when one famous name is on the payroll. The single-star company is the most common false positive at this level, and it is easy to catch.

Count distinct verified authorities. In Refolk's index, 1,529 US profiles carry an open-source maintainer-type title, with employers in that set including Akuity, Okta, Red Hat, Ericsson, and Exabeam. A concentration of verified authorities at one employer is a real signal; a single maintainer surrounded by unverified claims is not.

Magnetism also compounds slowly, which makes it hard to fake. Community credibility takes 2 to 4 weeks to seed and shows results in 4 to 8 weeks, but an open-source reputation is a 12 to 24 month investment. A company that appears to have authorities without that history is likely renting logos rather than employing maintainers.

The one input the buyer figures cannot supply is the direct question of whether engineers pick employers by thought leadership. The published Edelman-LinkedIn research measures buying behavior: 9 in 10 decision-makers say they are more receptive to outreach from consistent producers of high-quality thought leadership. That is a buyer figure, not an employer-choice figure. Secondary aggregators claim 75% of tech talent check a company's website before deciding on a job, but the precise "technical decision-makers use thought leadership to choose employers" figure is not publicly established. Use the sample sizes below to weight the sources, and do not present the buyer figure as a hiring figure.

How this goes wrong: false positives to check for

Most bad calls come from a small set of repeatable errors. Each has a specific check that catches it. Read this section before you sign off on any evaluation.

• Sponsored slot read as merit. A "speaker at BigConf" who bought an exhibitor package that bundled a talk. Check: find the open CFP and whether the company was a sponsor that year.
• Contributor mistaken for author or editor. A name in a W3C appendix or RFC acknowledgements presented as "wrote the standard." Check: is the name on the /TR page or the RFC header as editor or author?
• ORCID or DBLP name collision. A homonym's papers credited to your person. Check: use a DBLP-confirmed, manually verified ORCID, not an auto-harvested one.
• Vanity metrics as seniority. High star or follower counts on trivial or meme repos. Check: inspect merged pull requests, review activity, and whether the project is load-bearing, such as Kubernetes versus a sub-1k-stars library.
• Docs or typo commits counted as core authority. A large commit count that is mostly formatting. Check: read the diffs for architectural versus cosmetic change.
• Stale signal treated as current. A five-year-old flagship talk on a now-obsolete stack. Check: apply the 2.5 to 5 year half-life and look for recent artifacts.
• Company magnet inflated by one star. One famous maintainer masking a thin bench. Check: count distinct verified authorities, not headcount claims.

The thread connecting all seven is that each error substitutes an easy proxy for a harder verification. Stars stand in for review activity. A name near a document stands in for a name on it. An old talk stands in for current relevance. The fix in every case is to read the primary record.

What to verify before you call it done

Run this before you attach a verdict to a person or a company. If any item is unchecked, the verdict is not defensible yet.

Keeping the evaluation current

An authority evaluation is a dated document, not a permanent verdict, because the signals inside it expire on the stack's half-life. Re-run the seven-step procedure on a schedule tied to that half-life: roughly every two years for AI and fast-moving fields, every 2.5 to 5 years for general engineering.

Between full re-runs, watch for two cheap early warnings. A person's most recent artifact is the clock: if the latest verified talk, RFC, or release is aging past its window, flag the row for a fresh check even if the profile still reads as senior. At the company level, watch join dates on the authorities you counted, since a cluster of recent arrivals with no prior community history is the rented-logo pattern rather than a genuine magnet.

The re-check is fast because the hard work is already recorded. You have the primary URLs and the roles; you only need to confirm they still hold and add any new artifacts. Keep the template below at the top of every evaluation file so the next reviewer inherits the evidence instead of rebuilding it.

Person / Company:
Signal type: [ CFP talk | RFC/standard | paper | maintainership | community role ]
Primary URL:
Role confirmed: [ author | editor | maintainer | contributor | attendee ]
Pay-to-play check: [ CFP-reviewed | invited | purchased | n/a ]
Vanity metric excluded: [ yes ]
Verified on:
Re-verify by:
Verdict: [ authority | weak | not established ]

Where the evidence is thin, say so on the row. A signal you could not resolve to a primary record is "not established," not a quiet pass. That honesty is the difference between a reference you can defend in a hiring debrief and a wall of logos that falls apart under one question.