The Developer Champion Admission Standard: Admit, Probation, or Decline

This standard is for DevRel leads, engineering managers, technical founders, and sourcers with a stack of nominations for a developer champion or ambassador program who need to decide who gets in. You grade every applicant on six criteria using only public evidence, turn the grades into Admit, Probation, or Decline, and use the calibration routine at the end so a second grader reaches the same verdict on the same file. You can adopt it as written or change the thresholds, but write any changes down before you open the first application.

What Admit, Probation, and Decline mean

Admit means the applicant clears both gates and shows strong, dated public evidence. Probation means the gates clear but the evidence falls short, so the applicant joins a trial cohort and is graded again later. Decline means a gate fails or the core evidence is missing. Every verdict carries a written reason tied to a named criterion.

The six criteria come in two kinds:

• Gates are pass or fail. The conflict check and disclosure readiness are gates. Failing either one creates a brand or legal problem that no amount of good content makes up for.
• Evidence criteria are graded Pass, Partial, or Fail. Verified product use, original teaching, community help, and event record are evidence criteria.

Each verdict has a consequence the applicant can see:

• Admit. Full membership for one program cycle. Perks ship once the disclosure agreement is signed.
• Probation. A trial cohort for one cycle, with the specific shortfall named in writing. At the end of the cycle the file is graded again against the same six criteria. The result is Admit or Decline, never a second Probation.
• Decline. A polite no that names the criterion that failed and tells the applicant they can re-apply once fresh evidence exists inside a new lookback window.

After grading each criterion, the grader applies the verdict rules mechanically:

Decline beats Probation: any single Decline condition settles the verdict. The "at least two" bar mirrors CNCF's requirement that ambassador applicants take part in at least two of its listed areas of expertise. If your program is narrower, change the bar in the policy, not in a grader's head.

There is one more rule. If past sponsored posts carry an inadequate disclosure, such as a bare "#partner" tag, the verdict is capped at Probation even when every other criterion passes. The applicant fixes the pattern under supervision before getting full perks.

The six admission criteria and what each proves

Each criterion proves one specific thing about the applicant, and each one can mislead in a predictable way. A grader who knows both can grade consistently. Two terms run through the rest of this standard. The lookback window is the fixed period, here 12 months, inside which evidence counts. An artefact is a public, dated, linkable object such as a commit, an issue, an accepted answer, or a recording.

Verified product use

The strongest artefact is a commit in a public repo that changes code calling your SDK. The second strongest is an issue the applicant filed against your repos with a real reproduction. A manifest entry that names your package but has no calling code is Partial. A dependents listing on its own isn't evidence. If the applicant says their work is private, ask for a public reproduction repo. If no artefact exists even after you ask, product use is Fail.

Original teaching

Grade by reading. Original technical teaching has working code and version-specific detail: API names, version numbers, and the error a particular release actually throws. Pass requires at least one non-text artefact on the same topic, such as a recorded talk, a live reproduction, or a repo that runs. Text that reads as original but has nothing non-textual behind it is Partial. Broken code, generic summaries, or copied material is Fail. This matches AWS Community Builders, whose reviewers assess applications for educational value, authenticity, and consistency.

Community help

Count accepted answers, resolved issues, and mentoring threads dated inside the window. Read them as well as counting them. Nobody can tell from a count whether an answer solved the problem. No public program publishes a minimum count, so set yours in the policy and apply it the same way to every file. A Pass also requires the activity to be spread across the window rather than packed into its final month.

Event record

Count recorded talks, organized meetups, and workshops inside the window. CNCF's ambassador badge requires at least one year of experience organizing events, speaking, mentoring, or creating content, which is a fair outer bound. Only a recording or a public agenda counts as evidence. "Spoke at" on a profile does not.

What public champion programs require, and where they stop

The large public programs publish lookback windows, renewal cycles, and a few hard eligibility rules. None publishes a minimum activity count. Borrow their structure and write your own counts.

There are four things worth taking from these programs:

• The 12-month window. Microsoft MVP counts only contributions from the past 12 months, and each one needs a verifiable link. This standard uses the same window and the same link rule.
• Explicit exclusions. MVP eligibility requires that the person is not a Microsoft employee and not a contractor currently working for Microsoft. This standard's conflict gate generalizes that rule.
• Annual renewal. AWS Community Builders runs in one-year intervals, and CNCF requires an annual signature on its ambassador standards. Membership that never expires is never checked again.
• Score-based screens and their limits. CNCF requires a minimum DevStats score of 20. DevStats is CNCF's contribution-activity dashboard. CNCF itself notes that even commenting on GitHub issues can raise the score, so treat it as a screen, not as proof.

There is also a gap. One secondary account of AWS Community Builders says there is no specific acceptance criterion. The common public advice on how to choose developer champions stops at "look at your top contributors" and an application form. That gap is the reason for this standard.

How to grade an applicant file, step by step

Grade one file at a time in the order below. The evidence criteria come first so the gates are checked on a file you already understand, and both gates close before anything ships. The program owner does step 1 once per cycle. Everything else is per file.

Rough time budget: setting the window takes about an hour once per cycle, the product-use check takes 20 to 30 minutes per file, and the teaching check takes about 30 minutes. The product-use check is the slowest part because the evidence is spread across repos the applicant may never have listed. Refolk cuts this down. You ask for engineers whose public repos import your SDK and who also answer questions about it, and you get a short list of people and repos to read instead of a blind search.

Public sources disagree on the order. CNCF screens on contribution score first, and AWS reviews by specialty area. I couldn't find any source that says to run the conflict check before perks go out. I put it there anyway because that's where liability lands: once swag has shipped to a competitor's employee, the damage is done.

How to run the conflict check without trusting headlines

Confirm employment and program membership against employment history and official program rosters, never against a headline or bio. Headlines are the weakest conflict signal there is, because people who work for a vendor often put that vendor's program name in their own profile.

In Refolk's index of professional profiles, 1,484 US profiles carry "Microsoft MVP" in the headline. In a sample of 25 of them, Microsoft was the most common current employer, with 7 profiles. The most common titles included Corporate Vice President and CTO. Microsoft employees are explicitly ineligible for the MVP award, so a roster built by keyword-matching that headline would be wrong about the people most likely to be conflicted.

The same index shows that how risky conflicts are depends on the market:

DevRel titles here means profiles titled Developer Advocate or Developer Relations. The US pool is about 8.8 times the size of Germany's. Titles are also less reliable in the smaller market: 23 of 25 US sample profiles were on-title (92%), against 19 of 25 in Germany (76%). When two vendors account for a fifth of a small market's sample, an applicant from that market is more likely to work for someone you compete with. In concentrated markets, check employment more carefully.

A headline is a claim the applicant made about themselves; a roster is a claim the program made about them.

The check itself has four parts:

1. Your own employment and contracts. Search for current employment or a current contract with your company. Either one fails the gate, the same way MVP excludes Microsoft employees and contractors.
2. Competitor employment. Read current employment history, not just the headline title. Current employment at a direct competitor fails the gate.
3. Competitor program rosters. Check official directories where they exist. AWS publishes a Community Builders Directory. Sitecore's MVP directory can reportedly be filtered by year, but the only source for that is a secondary one flagged as needing a better citation, so verify it before relying on it. Current membership in a direct competitor's champion program fails the gate. Lapsed membership is noted but doesn't fail.
4. Record what you checked. List every roster and employment source on the grading sheet. A conflict check with no sources listed counts as not done.

Checking employment history against public rosters for a whole stack of applicants is the most tedious part of vetting community ambassador applicants. Refolk handles the cross-reference in plain English, and the prompt below is a complete example you can run as-is.

Disclosure readiness: the gate before perks ship

An applicant is ready for disclosure when their past sponsored content says plainly what they received and they have signed your standards agreement. Perks are material connections under the FTC Endorsement Guides, and the program can be liable even when the champion is not.

The rule is in 16 CFR 255.5. If a connection between the endorser and the seller could materially affect how much weight or credibility the audience gives the endorsement, and the audience wouldn't reasonably expect that connection, it has to be disclosed clearly and conspicuously. The revised wording adds that disclosure is needed when a significant minority of the audience doesn't understand or expect the connection. A disclosure doesn't need to give every detail. It does need to communicate the nature of the connection clearly enough that people can judge its significance.

What this means for champion perks:

• Swag and free credits. The Guides cover monetary payment and free or discounted products, including products unrelated to the one endorsed. Swag and credits fit that description.
• Early access and event passes. The sources I reviewed don't name these. Treat them as connections to disclose, and have counsel confirm against the current text.
• Program liability. An advertiser can be liable for a deceptive endorsement even when the endorser is not. Your program carries the risk of a champion's undisclosed post.
• Re-check the source. The Guides include examples of adequate and inadequate disclosure. Pull them from the current eCFR text of Part 255 when you draft the agreement, rather than relying on a summary.

To grade this gate, read the applicant's past sponsored or gifted posts. A disclosure that names a connection without explaining it, such as "#partner" or "thanks to the team", doesn't communicate its nature. That caps the verdict at Probation. A refusal to sign the agreement fails the gate outright.

As a member of the [Program name] run by [Company], I receive [list every perk, for example: free product credits, swag, event passes, early access].

Whenever I post, speak, or write about [Company] products, I will state this connection in the content itself, in plain words that say what I received. A tag on its own is not enough.

Acceptable: "I'm a member of [Company]'s [Program name] and receive free [product] credits and swag from them."
Not acceptable on its own: "#partner", "#ambassador", "thanks to [Company]".

I will add this disclosure to any post about [Company] made since I joined that lacks it.
I will re-sign this agreement at the start of every program cycle.

Name: [full name]
Date: [date]

How this goes wrong: failure modes and false positives

Most bad admissions come from treating a convenient proxy as proof: a headline, a count, a score. Each failure mode below says what the proxy shows, why it misleads, and the check that catches it.

1. Keyword roster match. A search for "Microsoft MVP" in headlines returns Microsoft employees, who are ineligible for the award: 28% of the sample in Refolk's index. Check: confirm membership against the official directory, never the headline.
2. Dependents count as proof of use. GitHub's dependency graph lists dependents only for public repositories, and its counts are approximate, so they may not match the dependents it lists. The "Used by" sidebar appears only past 100 dependents, so most individual applicants never show up in it. One study found manifest and lock files matched the dependency graph for only 28.28% of repositories, and found the graph wrong for roughly 20% of dependencies. A forked starter template with an untouched manifest is a classic false positive. Check: look for commits that change code calling the SDK.
3. AI-detector score as evidence. Detectors flag non-native English writers as machine-written at very high rates. Graders who trust them will reject real people, unevenly by language. Check: ask for a reproduction or a recorded talk on the same topic.
4. Volume over window. Many posts packed into the month before applying look like a strong record in a count and like gaming in a timeline. Check: plot activity dates across the 12-month window.
5. Score inflation. Contribution scores reward activity, not substance. CNCF itself notes that even commenting on GitHub issues raises the DevStats score. Check: read what the contributions actually say, not just the score.
6. High percent agreement, low kappa. If most files are Declines, two graders who both default to Decline agree often without agreeing on anything hard. Check: report both numbers, and spread the anchor files across all three verdicts.
7. Disclosure that names a connection without explaining it. A bare "#partner" tells the audience that something exists, not what it is. Check: does the wording state what the applicant received?

The detector failure has a known mechanism, which is why this standard bans the scores outright instead of down-weighting them. Detectors that score text by perplexity, meaning how predictable each word is, read simple, regular phrasing as machine-made. Clear technical writing by a second-language author is exactly that kind of text. One commercial detector claims a false-positive rate below 1%, but that is the vendor's own claim, not an independent measurement. The tension shows up beyond champion programs too. Stack Overflow's policy text sanctions users believed to have used generative AI even when the posts would otherwise be acceptable, and the company later restricted moderators from acting on suspected AI posts over false-positive concerns, which set off a moderator strike.

How to make two graders reach the same verdict

Two graders score a pilot batch independently, then compute percent agreement and Cohen's kappa. The standard is adopted only when kappa clears the bar you set in advance. Cohen's kappa is a measure of agreement between two raters that subtracts the agreement expected by chance.

What the numbers mean and where they stop:

• The conventional bands. Landis and Koch label 0.61 to 0.80 as substantial and 0.81 to 1 as almost perfect agreement. They gave no evidence for these bands and based them on personal opinion.
• The floor. McHugh treats any kappa below 0.60 as inadequate. This standard adopts when kappa is 0.61 or higher and revises the criteria wording otherwise. Write your own bar into the policy if you choose differently.
• The paradox. When verdicts are lopsided, raw agreement can be 80% while kappa is only 0.375. Always report both numbers.
• No published DevRel procedure. I found no published method for calibrating a DevRel rubric with anchor files. The routine below is a reasonable default, not an established method, so check your own pilot results before trusting it.

An anchor file is a past or mock applicant file with an agreed verdict, used to test whether graders apply the criteria the same way. Pick anchors that cover Admit, Probation, and Decline, with several Probation files, because Probation is where graders disagree most often.

When graders disagree, the cause is almost always a criterion worded loosely enough to read two ways. Rewrite the Pass definition for that criterion, not the verdict table. After adoption, keep grading every file twice. Where the two graders disagree, the program owner resolves it, and the resolved file becomes a new anchor.

Applicant:
Grader:
Window: [start date] to [end date] (12 months)

1. Verified product use: Pass / Partial / Fail
   Artefact URL(s):
   Type: commit calling SDK / issue filed / manifest only / none
2. Original teaching: Pass / Partial / Fail
   Sample URL(s):
   Non-text artefact (talk or reproduction) URL:
3. Community help: Pass / Partial / Fail
   Count in window: ___ (policy minimum: [N])
   Packed into final month? Y / N
4. Event record: Pass / Partial / Fail
   Recording or agenda URL(s):
5. Conflict check (gate): Pass / Fail
   Employment sources checked:
   Rosters checked:
6. Disclosure readiness (gate): Pass / Fail
   Past sponsored posts reviewed (URLs):
   Inadequate disclosure found (caps at Probation)? Y / N
   Agreement signed? Y / N

Verdict: Admit / Probation / Decline
Deciding row of the verdict table:
One-sentence reason for the applicant:

Keeping the standard current

Run this standard on a fixed cycle. Re-check the public sources it borrows from, grade Probation members again against the same criteria, and require every member to re-sign the disclosure agreement each year. A standard that is never reviewed slowly turns into individual graders' judgment.

What to do every cycle:

• Re-check the program rules table. CNCF's bar has already changed from three criteria to two. Open each program's current FAQ or application page and update the table if anything moved.
• Re-check the Endorsement Guides. Read the current eCFR text of 16 CFR Part 255 and its examples before re-issuing the agreement.
• Grade Probation members again. Use the same sheet and the same window length. The outcome is Admit or Decline.
• Track your own renewal rate. No public program publishes a one-year retention or renewal share, so your own numbers are the only benchmark you'll have. Record how many Admits and Probations renew each cycle.
• Recalibrate after staffing changes. A new grader scores the anchor set before grading live files.

When the nomination stack is thin, use the same six criteria to go looking for candidates rather than waiting for applications. Refolk can surface people whose public footprint already shows the evidence, for example Python developers who blog about LangChain and have spoken at PyCon, so outreach starts with people likely to pass.