developer-champions

{
  "skill_name": "developer-champions",
  "evals": [
    {
      "id": 1,
      "prompt": "I'm the founder of Klaxon, a queue-observability tool. We've got about 340 people in our Discord, and if I sit down and write names I can list 6 who consistently help others out. I want to launch the Klaxon Ambassadors publicly at the end of the month: public roster page, nice title, and to make it worth their time we'd give each of them 15% recurring on any subscription that comes through their referral link. In exchange each ambassador publishes one blog post a month about Klaxon. Can you put the whole thing together for me - page copy, the perk list, the deal terms?",
      "expected_output": "A refusal to launch a public program at this pool size, with informal recognition and community growth recommended instead; the referral commission refused as a champions perk and split off into a separate paid motion if wanted; the monthly blog quota refused and replaced with behaviour-based obligations.",
      "files": [],
      "expectations": [
        "States that 6 nameable qualifying people is below the roughly 10-candidate readiness floor and recommends against launching a public program now",
        "Recommends growing the community and recognising these individuals informally in the meantime",
        "Explains that a public program with a handful of members reads as a failed program and that the failure stays visible",
        "Labels the roughly 10-candidate floor as a self-set default rather than an industry standard or benchmark",
        "Refuses the 15% recurring referral commission as a champion perk",
        "Gives the reason that a commission or affiliate cut reads as multi-level marketing and destroys the member's credibility with their own audience",
        "States that a genuinely paid motion must run as a separate program with its own contract, never bolted onto a recognition title",
        "Notes that general-marketing playbooks recommending revenue share for ambassadors are written for consumer brand ambassadors, instead of asserting that the field agrees",
        "Refuses the one-blog-post-per-month requirement as a content quota",
        "Ties the quota refusal to employment-classification exposure created by assigned tasks, deadlines and quotas, not only to community dynamics",
        "Frames obligations as behaviour - following the code of conduct, being constructive with newcomers, giving honest feedback including criticism, respecting embargoes - rather than output volume",
        "Does not deliver a finished public ambassador page and perk list for the six people as the requested deliverable"
      ]
    },
    {
      "id": 2,
      "prompt": "Harbourline is a data-pipeline platform. Our community forum has around 1,400 people active in the last 90 days. Leadership wants a champions program announced on stage at our user conference, which is in six weeks and the date is locked. I'm the community manager and I can realistically hold about 8 hours a month for this on top of my job. We have zero engineering headcount to build anything - no portal, no tracking system, nothing. Leadership is also clear this isn't a one-off: they want it running every year from now on. What shape should this program take?",
      "expected_output": "A ranked shortlist of archetypes with explicit orderings on more than one axis, the points ledger deleted outright for lack of engineering time, the six-week date and the annual mandate each named as pushing toward different shapes, and a first-cohort recommendation sized to 8 hours a month.",
      "files": [],
      "expectations": [
        "Presents the archetype choice as a shortlist of two or three of the four shapes with a stated recommendation, rather than one prescribed answer",
        "States the efficiency ordering explicitly as invite-only circle > award > application cohort > points ledger",
        "States at least one further axis ordering (value, effort or compliance cost) separately rather than collapsing everything into one blended rank",
        "Gives a value ordering in which the application cohort ranks first",
        "Deletes the points ledger from the shortlist outright because no engineering time exists, and says which archetype was deleted and why rather than ranking it last",
        "Names the locked six-week date as the answer that promotes the invite-only circle",
        "Names the intent to run the program every year as the answer that promotes the application cohort",
        "Identifies the tension between the fixed near date and the compounding mandate instead of silently honouring only one of them",
        "Proposes a first cohort deliverable within six weeks, with published-criteria open intake deferred to a later cycle",
        "Notes that the points ledger is the least reversible of the four shapes because members accrue points against a promised redemption",
        "States that an application cohort's published criteria become a public commitment the program can be held to in later cycles",
        "Warns that the archetype ordering is a default to re-rank against context, not a law",
        "Checks 8 hours a month against cohort size using a figure of roughly 1-2 hours per champion per month, and labels that figure self-set"
      ]
    },
    {
      "id": 3,
      "prompt": "Naviform is a local-first sync engine. Most of our users are indie developers, students and hobbyists - almost nobody is expensing anything. Our biggest clusters of activity are in Indonesia, Brazil and Nigeria, and we have no staff in any of those places. We already run a small recognition group and right now the perks are: a hoodie, a sticker pack, a Discord role badge, and a 20% discount code they can share. Finance just approved $2,500 per member per year that I have to spend or lose. What should I do with it to make this program actually compelling?",
      "expected_output": "A perk ladder with access at the top and status objects at the bottom, the discount code dropped, and funding deliberately promoted above its default rank because of the hobbyist audience and unstaffed regions.",
      "files": [],
      "expectations": [
        "States the perk efficiency ordering as access > platform > skill-building > funding > status objects",
        "Classifies the hoodie, sticker pack and Discord badge as status objects and places them last on that ordering",
        "Explains that status objects rank last despite costing almost nothing, because cheap and efficient are different orderings",
        "Rejects the generic 20% discount code as a perk",
        "Adds at least one access perk - roadmap review, release briefing, private channel with engineers, executive time, or being consulted before decisions land",
        "Notes that access is the only rung where a single beat serves the whole cohort at once",
        "Promotes funding above its default efficiency rank for this program, citing the individual-adoption audience and the unstaffed regions",
        "States that funding is the rung the efficiency ordering otherwise starves",
        "Directs the $2,500 toward travel, tickets, credits, certification or training vouchers rather than more merchandise",
        "Notes that funding carries the highest effort of the five rungs: a budget line, a signature per member, and a gift-limit and tax check",
        "Recommends shorter terms and expects higher churn for a hobbyist and student audience"
      ]
    },
    {
      "id": 4,
      "prompt": "I'm writing the selection criteria for the Sailmaker Data Experts program. My plan: the one hard requirement is that the applicant has given a talk at a recognised conference - that's the bar, no exceptions. Then I score everyone who applies on a 100-point scale and publish the full leaderboard so the process is transparent and nobody can accuse us of favouritism. I want to weight X follower count heavily, maybe 30 of the 100 points, because the whole point is getting our name in front of more people. Does this hold up?",
      "expected_output": "The single mandatory criterion replaced with an any-two-of-four-to-six pattern, the published leaderboard refused in favour of a published gate plus an internal rank, and reach re-weighted to the bottom with support signals at the top.",
      "files": [],
      "expectations": [
        "Rejects the single mandatory criterion and applies a two-or-more pattern: four to six qualifying activities with any two required",
        "Explains that a single mandatory criterion filters the program down to one personality type, typically conference speakers",
        "Cites a published program requiring two or more of five criteria as the sourced anchor for that pattern",
        "Separates a published gate from an internal rank: the qualifying criteria are published, the scoring rubric is not",
        "States that a candidate who fails the gate is not scored at all",
        "Refuses to publish per-applicant scores or a public applicant leaderboard",
        "Weights answering other people's questions highest among the selection signals",
        "Weights follower count or audience reach lowest among the selection signals",
        "Gives the reason that reach can be granted later by the program's own platform perks while depth of engagement cannot be granted at all",
        "Publishes anti-signals alongside the criteria, naming at least reach without product depth and activity that begins the week applications open",
        "Requires a written conflict-of-interest rule for competitor employment and for consultancies whose pipeline would lean on the title, instead of case-by-case judgement",
        "Specifies that rejected candidates get a reply naming the specific gap and what to build before the next window"
      ]
    },
    {
      "id": 5,
      "prompt": "Taking over the Otterlane Advocates program. It started in 2021 and has grown to 61 people on the public roster. Last quarter, 8 of them did anything visible at all - the rest are silent, and at least a dozen have changed jobs into unrelated fields. Nobody has ever been removed. My manager's plan is to recruit 20 more advocates this year to get the energy back up, and to upgrade the welcome kit to a much nicer jacket and a Yeti tumbler. Where do I start?",
      "expected_output": "The active share computed and compared to a bar, recruitment and better swag both refused as the fix, dated terms and an inactivity clause introduced, and inactive members moved to a first-class alumni status rather than deleted.",
      "files": [],
      "expectations": [
        "Computes the quarterly active share at roughly 13% and states it sits far below a 60% starting bar",
        "Advises fixing perks, obligations or cohort size before admitting any new members",
        "States explicitly that adding members while the active share is low makes the number worse",
        "Introduces dated terms at the next cycle as the primary structural fix",
        "Adds an inactivity clause with a stated month count of no visible activity or contact, after which a member becomes renewal-ineligible or moves to alumni",
        "Moves inactive members to alumni rather than deleting them from the roster",
        "Keeps alumni titles dated and truthful, in the form \"Advocate, <start year>-<end year>\" or equivalent",
        "Gives alumni a role such as nominating, mentoring the next cohort, or reviewing applications",
        "Diagnoses front-loaded status objects with no recurring access as the likely cause of members going quiet",
        "Adds a recurring access beat plus a feedback digest showing what advocate input actually changed",
        "Declines the upgraded jacket and tumbler as the fix for the activity problem"
      ]
    },
    {
      "id": 6,
      "prompt": "Kestrelboard is a CI orchestration product. We're finalising our Kestrelboard Insiders program and my co-founder is adamant the title should be for life - his argument is that it's a reward for work already done, and putting an expiry date on someone's recognition is insulting and will make people not want it. The only way off the list would be if someone did something genuinely bad. I half agree with him. Talk me through how the membership side should actually work.",
      "expected_output": "A lifetime title refused in favour of a dated term fixed on day one, with renewal judged on the last term only, a notice period, a pause option, conduct removal routed through moderation, and alumni status as the graceful exit.",
      "files": [],
      "expectations": [
        "Rejects the lifetime title and requires an end date fixed on day one",
        "Explains that without a dated term the only exit is removal, which nobody executes, so the roster fills with inactive names",
        "Recommends a term length and labels it self-set, distinguishing a vendor-scale default of about 12 months from a foundation-scale default of about 24",
        "Cites published practice - dated cohorts running about two years at a foundation, an annually rebuilt roster at a vendor - as the sourced anchor for term length",
        "Judges renewal against the published criteria over the last term only, not against past reputation",
        "Sets a notice period before the term ends, describing a quarter as generous and a month as the floor",
        "Sends the activity record being judged along with the renewal notice so renewal is never a surprise",
        "Offers a pause for parental leave, illness, a job change or burnout, without treating it as failure to perform",
        "Routes conduct removal through the moderation process rather than the program owner alone",
        "States that if the program ever ends it is announced with a full term of notice, promised perks are honoured, and the roster page stays online"
      ]
    },
    {
      "id": 7,
      "prompt": "Vaultmere sells key-management infrastructure to regulated industries. Our first champions cohort is picked: two platform engineers at a retail bank, one at a hospital network, one who works for a federal contractor, and three independents. Plan is to send each of them a welcome box we've costed at about $900, give them pre-release builds under our standard company-wide NDA that all our partners sign, and ask them to post about each of our four product launches a year. We're announcing in three weeks. Anything I should tighten before then?",
      "expected_output": "Gift limits flagged for the regulated employers, employer approval moved to intake, the blanket NDA narrowed to the pre-release builds, disclosure wording supplied for public posts, tax noted, and the per-launch posting obligation refused.",
      "files": [],
      "expectations": [
        "Flags the roughly $900 welcome box against gift-value limits that commonly bar public-sector, healthcare and finance employees from accepting gifts above a threshold",
        "Lets any member decline any perk without penalty",
        "Asks about employer approval and competitor employment at intake, before acceptance rather than after",
        "Narrows the NDA to the pre-release builds actually shared and refuses the blanket company-wide NDA",
        "Explains that a blanket NDA suppresses the public advocacy the program exists to create",
        "Requires an endorsement disclosure on public posts, identifying free product, swag, tickets, early access and credits as the material connection that triggers it",
        "Names the US FTC endorsement guides at 16 CFR Part 255 and notes comparable regimes exist in the UK and EU",
        "Supplies the disclosure wording and the expectation rather than leaving each member to guess it",
        "Notes that high-value perks may be taxable to the member",
        "Declines the standing obligation to post about every launch and refuses to turn the program into a marketing arm with approved messaging",
        "States a may-not list including that a champion may not speak for the company or promise roadmap items",
        "Gates jurisdiction-specific points on current local rules and on counsel rather than asserting a legal conclusion"
      ]
    },
    {
      "id": 8,
      "prompt": "Moorgate Cloud here. Our CRO read that a well-known productivity company gets about 25% of its new users through community referrals from its ambassadors, and he now wants our champions program to hit that number inside twelve months. He's asked me to build him a dashboard showing revenue attributed to each individual ambassador so we can see who's earning their keep. What do I build and what do I tell him?",
      "expected_output": "The 25% figure characterised as weak second-hand evidence from a different context rather than a target, per-ambassador revenue attribution declined as unsupportable, and a self-set quarterly scorecard proposed with explicit starting bars and pre-written kill criteria.",
      "files": [],
      "expectations": [
        "Identifies the roughly 25% figure as second-hand, reported in a book rather than by the company itself, and never confirmed by that company",
        "Notes the source describes a consumer-adjacent product at extreme scale, making it a north star rather than a target",
        "Identifies the other public outcome number - roughly +13% participants and +38% contributions at a search-infrastructure vendor - as first-party reporting from the team that ran the program, with no baseline comparison",
        "Declines to build a per-ambassador revenue-attribution model, stating the data cannot support it",
        "Proposes asking new users how they heard about the product as the directional substitute",
        "Names deflected support questions, content the company did not commission, and adoption in places with no company presence as the honest impact surface, none of it cleanly attributable",
        "Proposes a quarterly scorecard whose every threshold is labelled self-set rather than benchmarked",
        "Includes quarterly active share with a starting bar of at least 60%",
        "Includes renewal acceptance with a starting bar of at least 70%",
        "Includes a candidate-pipeline bar of at least half the cohort size and a median response time to a champion of no more than 5 business days",
        "Requires kill criteria to be written before launch, naming the activity or renewal rate at which the program shrinks or stops"
      ]
    },
    {
      "id": 9,
      "prompt": "Found a scoring model online for picking out your best community people and it looks well thought through: content created +25, top-decile product usage +20, answering other people's questions +20, general community activity +15, social mentions +10, accepted feature requests +10. I was going to adopt it as-is for the Fenwright Guides program we're setting up. Is there anything wrong with it?",
      "expected_output": "The quoted scale's implicit bet on reach named explicitly, its missing mentoring, tenure and coverage-gap lines pointed out, and an alternative weighting offered that puts answering questions above content creation, with every weight labelled self-set.",
      "files": [],
      "expectations": [
        "Names the disagreement explicitly as whether the program is buying reach or buying depth",
        "Points out that the quoted scale ranks content creation highest",
        "Points out that the quoted scale contains no mentoring line",
        "Points out that the quoted scale contains no tenure or sustained-activity line",
        "Points out that the quoted scale contains no coverage-gap line for region, language, vertical or ecosystem",
        "Offers an alternative weighting that places answering other people's questions above content creation",
        "Adds sustained tenure, mentoring and coverage gap as weighted signals in the alternative",
        "Labels every weight it offers as self-set rather than an observed distribution",
        "States that champion programs keep their internal scoring private, which is why no published distribution exists to calibrate against",
        "Recommends recalibrating the weights to the program's stated purpose and writing that change into the charter rather than applying it silently"
      ]
    },
    {
      "id": 10,
      "prompt": "Gallowbridge runs an open-source search product with a commercial edition. We have two engineers I can borrow for a quarter, and I want to build a contribution points system: every tracked contribution earns points, anyone can join, and points cash out. My plan is one global points table so it's fair to everyone, totals visible to our community team only so people don't get competitive about it, redemption as Amazon gift cards since that's what people actually want, and tracking in a shared spreadsheet to start. Poke holes in it.",
      "expected_output": "Per-region point calibration, a published ledger, non-cash redemption, cycle-by-cycle weight revision with announcement, a budgeted portal instead of a spreadsheet, and explicit warnings about the archetype's irreversibility and compliance load.",
      "files": [],
      "expectations": [
        "Calibrates point values per region rather than using one global table",
        "Gives the reason that contribution culture differs by market, so a single global table systematically under-recognises some regions",
        "Publishes the ledger rather than keeping totals visible only to staff",
        "Gives the governance reason for publishing: a private total only staff can see recreates the gatekeeper the ledger was meant to remove",
        "Refuses cash or cash-equivalent redemption such as gift cards, and redirects redemption to training, certification and conference trips",
        "Weights contributions by effort and current strategic need, treating the weighting as a steering wheel that over-rewards under-served areas until the imbalance closes",
        "Revisits the weights every cycle and announces the change to members",
        "Counts contribution types wider than code, naming at least talks, event organizing, content or forum answers",
        "Rejects spreadsheet-based tracking at global scale and budgets a real portal as a known cost of this archetype rather than a surprise",
        "Names the points ledger as the least reversible of the four archetypes, because stopping means honouring accrued balances",
        "Flags the ledger's extra compliance load: published member activity records and redeemable value pull in gift limits, member tax exposure and a data review before launch",
        "States that the ledger measures in order to award recognition and never functions as a quota whose miss triggers punishment"
      ]
    },
    {
      "id": 11,
      "prompt": "Quillrun, we make a schema-migration CLI. We announce our community program Monday and I need the landing page copy today - can you just write it? The perks we've settled on are early access to release candidates, a private Slack channel with the team, and an invite to our annual summit. Name is Quillrun Navigators. Keep it punchy, I don't need a big strategy doc.",
      "expected_output": "The landing-page-only request declined; a charter produced first covering the 12 questions with numbers marked sourced or self-set, validated section by section, and only then a public page limited to the publishable subset.",
      "files": [],
      "expectations": [
        "Refuses to hand back a perk list or landing page with no term, exit and bar attached",
        "Produces the charter first and the public page second, in that order",
        "Works through the 12 charter questions, covering at minimum purpose, archetype, criteria, obligations, perks, term, exit, compliance, operations and bar",
        "Marks every number in the charter as sourced or self-set",
        "Validates each section with the user before moving to the next rather than delivering the whole document in one pass",
        "Limits the public page to purpose, criteria and anti-signals, obligations and the may-not list, perks, term dates with renewal and inactivity rules, alumni status, the disclosure expectation, and how to apply or be nominated",
        "Keeps the candidate pipeline list, individual scores, budget per member, kill criteria and raw scorecard numbers internal",
        "States that a charter with no named owner or budgeted monthly hours fails the readiness check, and says so instead of polishing the document",
        "Does not treat the three named perks as a sufficient program design"
      ]
    },
    {
      "id": 12,
      "prompt": "I maintain libcaldera, an open-source calendar-recurrence library. Solo maintainer, no company behind it, no money coming in beyond about $40/month in donations. There's a group of maybe 30 regulars in the GitHub discussions who are genuinely great. I want to name 25 of them libcaldera Champions. I can spare about 3 hours a month for this. I was thinking hoodies funded out of the donation pot, and a nice badge on their profile. Sound workable?",
      "expected_output": "The 25-person cohort checked against 3 hours a month and cut down or shifted to a lower-touch archetype, swag replaced with standing and responsibility, the champion tier wired into the existing contributor ladder, and conduct and feedback-capacity gates raised.",
      "files": [],
      "expectations": [
        "Checks 25 champions against 3 hours a month using a figure of roughly 1-2 hours per champion per month and concludes the cohort far exceeds what those hours support",
        "Labels the hours-per-champion figure as self-set, to be derived from the operating beats actually chosen",
        "Recommends shrinking the cohort or moving to a lower-touch archetype rather than keeping 25",
        "Recommends an invite-only circle as the default starting shape",
        "States that for an open-source project with no vendor budget the currency is standing and responsibility, not swag",
        "Connects the champion tier to the project's existing contributor ladder so recognition ladders into review rights and maintainership rather than sitting beside it",
        "Keeps the emeritus or alumni exit that the contributor ladder already defines",
        "Requires a code of conduct and a working moderation path to exist before the title is granted",
        "Explains that a champion title grants implied authority, so granting it with no enforcement path is how a bad actor becomes an official one",
        "Requires a named person who will actually receive and answer what champions raise, rather than a feedback obligation with no listener"
      ]
    }
  ],
  "trigger_queries": [
    { "query": "design an ambassador program for our API", "should_trigger": true },
    { "query": "we want to launch a developer champions program, where do we start", "should_trigger": true },
    { "query": "how do we recognise our top community members", "should_trigger": true },
    { "query": "40 people answer questions in our Discord every week and we have no way to thank them", "should_trigger": true },
    { "query": "our ambassador program has 60 members and 8 active ones", "should_trigger": true },
    { "query": "should our champions program be nomination-only or an open application", "should_trigger": true },
    { "query": "write the selection criteria page for our MVP-style recognition program", "should_trigger": true },
    { "query": "how long should an ambassador term be", "should_trigger": true },
    { "query": "what perks should ambassadors actually get", "should_trigger": true },
    { "query": "our ambassador program went quiet after the first three months", "should_trigger": true },
    { "query": "how do we remove an inactive champion without it being awkward", "should_trigger": true },
    { "query": "we want a community heroes program", "should_trigger": true },
    { "query": "is a points system a good way to pick community advocates", "should_trigger": true },
    { "query": "our community MVP list hasn't changed since 2022", "should_trigger": true },
    { "query": "how many ambassadors should a first cohort have", "should_trigger": true },
    { "query": "people keep asking to be added to our advocates list and I don't know how to say no", "should_trigger": true },
    { "query": "draft the charter for our developer advocate recognition program", "should_trigger": true },
    { "query": "should we give our top contributors a title", "should_trigger": true },
    { "query": "what should we ask on the ambassador application form", "should_trigger": true },
    { "query": "how do I turn down someone who applied to be a champion without losing them from the community", "should_trigger": true },
    { "query": "our ambassadors keep asking what they actually get out of it", "should_trigger": true },
    { "query": "we give our top users a badge and a hoodie, is that enough", "should_trigger": true },
    { "query": "can we require ambassadors to post twice a month", "should_trigger": true },
    { "query": "is it okay to pay our ambassadors a commission on referrals", "should_trigger": true },
    { "query": "we need an alumni status for people leaving our advocate program", "should_trigger": true },
    { "query": "design a two-tier setup with an open tier and a small selective inner group", "should_trigger": true },
    { "query": "our champions all come from one region and one language", "should_trigger": true },
    { "query": "how do I measure whether the ambassador program is working", "should_trigger": true },
    { "query": "what should go on the public page for our community recognition program", "should_trigger": true },
    { "query": "we announce our first cohort in six weeks, what shape should it be", "should_trigger": true },
    { "query": "one of our champions told a customer a feature was shipping next quarter and it isn't", "should_trigger": true },
    { "query": "how do we stop our advocates list from becoming a graveyard", "should_trigger": true },
    { "query": "we want an annual summit for our top community folks, what else do they need", "should_trigger": true },
    { "query": "how do I decide who gets into the first cohort", "should_trigger": true },
    { "query": "what do our champions owe us and what do we owe them", "should_trigger": true },
    { "query": "set up recognition for the people who run our user groups", "should_trigger": true },
    { "query": "should we announce the roster publicly or keep the group private", "should_trigger": true },
    { "query": "do our ambassadors need to disclose that we send them free stuff", "should_trigger": true },
    { "query": "we're asking our top users to sign an NDA before early access, is that normal", "should_trigger": true },
    { "query": "legal is worried our ambassador program looks like unpaid employment", "should_trigger": true },
    { "query": "how do I renew champions without it feeling automatic", "should_trigger": true },
    { "query": "what's the right cadence for calls with our recognised community members", "should_trigger": true },
    { "query": "we have twelve people who deserve something and no budget at all", "should_trigger": true },
    { "query": "help me pick between an award and an open application for recognising community leaders", "should_trigger": true },
    { "query": "our program owner is burning out running the ambassador cohort", "should_trigger": true },
    { "query": "we want to shut down our ambassador program without burning the people in it", "should_trigger": true },
    { "query": "how do we pick which of our power users to formally recognise", "should_trigger": true },
    { "query": "our best community members keep getting hired by us and dropping off the list", "should_trigger": true },
    { "query": "draft the rejection email for our champions application round", "should_trigger": true },
    { "query": "what are the red flags in a champion application", "should_trigger": true },
    { "query": "somebody applied to our program who works for a direct competitor", "should_trigger": true },
    { "query": "we want a recognition program but our community is tiny", "should_trigger": true },
    { "query": "how do we keep the title meaningful over several years", "should_trigger": true },
    { "query": "our community advocates are getting treated like free frontline support", "should_trigger": true },
    { "query": "what should we track each quarter for our community recognition program", "should_trigger": true },
    { "query": "we need a scoring rubric for our community leaders program", "should_trigger": true },
    { "query": "one of our champions got a code of conduct report, do they lose the title", "should_trigger": true },
    { "query": "set the bar for when we'd shut this recognition program down", "should_trigger": true },
    { "query": "we want the people who teach others about our product to get something back", "should_trigger": true },
    { "query": "how many hours a month does it take to run a program like this", "should_trigger": true },
    { "query": "how do we formalise the informal group of people who already evangelise our tool", "should_trigger": true },
    { "query": "which platform should we use for our developer community, Discord or Discourse", "should_trigger": false },
    { "query": "should we even start a Discord for our users", "should_trigger": false },
    { "query": "how do we seed the first 50 members of a brand new community", "should_trigger": false },
    { "query": "our community feels quiet, how do I tell if it's actually dying", "should_trigger": false },
    { "query": "build me a developer community health dashboard", "should_trigger": false },
    { "query": "what community KPIs should we report to the board", "should_trigger": false },
    { "query": "write a CODE_OF_CONDUCT.md for our project", "should_trigger": false },
    { "query": "someone is brigading our Discord, what's the escalation ladder", "should_trigger": false },
    { "query": "we need to recruit volunteer moderators for the forum", "should_trigger": false },
    { "query": "how do I ban a user from our forum", "should_trigger": false },
    { "query": "attendance at our monthly meetup dropped from 40 to 12", "should_trigger": false },
    { "query": "how do I find speakers for our local user group", "should_trigger": false },
    { "query": "we need a venue and a pizza sponsor for our meetup", "should_trigger": false },
    { "query": "write a CONTRIBUTING.md for our repo", "should_trigger": false },
    { "query": "our good first issues get no takers", "should_trigger": false },
    { "query": "first-time contributors open a PR and then disappear", "should_trigger": false },
    { "query": "how do we promote a contributor to maintainer", "should_trigger": false },
    { "query": "write a GOVERNANCE.md for our project", "should_trigger": false },
    { "query": "our project has a bus factor of one and I'm the one", "should_trigger": false },
    { "query": "should we donate the project to a foundation", "should_trigger": false },
    { "query": "set up GitHub Sponsors tiers for my library", "should_trigger": false },
    { "query": "nobody sponsors our project even though half the ecosystem depends on it", "should_trigger": false },
    { "query": "how much should our corporate sponsorship tier cost", "should_trigger": false },
    { "query": "should we sponsor that conference this year and at what tier", "should_trigger": false },
    { "query": "was our booth at that developer conference worth the money", "should_trigger": false },
    { "query": "how do I split our event budget across six conferences", "should_trigger": false },
    { "query": "help me write a CFP abstract for my talk", "should_trigger": false },
    { "query": "my conference talk proposals keep getting rejected", "should_trigger": false },
    { "query": "cut our developer audience into named segments and size them", "should_trigger": false },
    { "query": "should we target hobbyists or enterprise platform teams first", "should_trigger": false },
    { "query": "write a job description for a developer advocate we're hiring", "should_trigger": false },
    { "query": "design the interview loop for a DevRel hire", "should_trigger": false },
    { "query": "how do I get my first DevRel job", "should_trigger": false },
    { "query": "am I ready to move from IC advocate to DevRel manager", "should_trigger": false },
    { "query": "why can't we get senior engineers to apply to us", "should_trigger": false },
    { "query": "should we publish our engineering salary bands", "should_trigger": false },
    { "query": "should we build a certification program for our product", "should_trigger": false },
    { "query": "design a learning path for developers new to our SDK", "should_trigger": false },
    { "query": "how do I find the internal champion at an enterprise prospect", "should_trigger": false },
    { "query": "our deal stalled because our champion left the account", "should_trigger": false },
    { "query": "set up an affiliate program paying creators 20% on referrals", "should_trigger": false },
    { "query": "negotiate a sponsored video with a YouTube creator in our space", "should_trigger": false },
    { "query": "find influencers on Instagram for our launch campaign", "should_trigger": false },
    { "query": "build an influencer marketing strategy for a consumer app", "should_trigger": false },
    { "query": "how do we get more GitHub stars", "should_trigger": false },
    { "query": "rewrite our README so people understand the project in ten seconds", "should_trigger": false },
    { "query": "triage the 400 open issues in our repo", "should_trigger": false },
    { "query": "what DevRel metrics should I report to my VP", "should_trigger": false },
    { "query": "how do I allocate next year's DevRel budget across programs", "should_trigger": false },
    { "query": "write a customer case study about how a company uses our API", "should_trigger": false },
    { "query": "plan our developer content calendar for Q3", "should_trigger": false },
    { "query": "which competitor has the strongest developer experience", "should_trigger": false },
    { "query": "our quickstart takes 45 minutes, fix it", "should_trigger": false },
    { "query": "write release notes for version 4.2", "should_trigger": false },
    { "query": "should we relicense from AGPL to Apache 2.0", "should_trigger": false },
    { "query": "plan the Show HN launch for our CLI", "should_trigger": false },
    { "query": "draft a weekly devlog cadence I can actually keep up", "should_trigger": false },
    { "query": "restructure our docs into tutorials, guides and reference", "should_trigger": false },
    { "query": "how should we price the free tier of our developer tool", "should_trigger": false },
    { "query": "map the developer journey from first visit to production", "should_trigger": false },
    { "query": "prepare me for a podcast interview about our open source project", "should_trigger": false }
  ]
}

# Champion program charter

Contents: the 12 charter questions · filled example · counter-example read line by line · what to publish vs. keep internal.

The charter is the artefact the program is judged against. Answer all 12 questions before any public launch; an unanswered question is a decision the first difficult case will make for you, badly.

## The 12 questions

```markdown
# <Program name> - charter

1. **Purpose** - the single outcome that justifies the program in a year. One, not five.
2. **Room** - who qualifies: audience type, orbit level (contributors and advocates, not newcomers), regions and languages targeted.
3. **Archetype** - invite-only | award/nomination | application cohort | points ledger, and why that one now.
4. **Size** - target cohort size, and the candidate pipeline needed to fill it (aim 2-3× the cohort).
5. **Criteria** - the four to six qualifying activities, the "any two" rule, and the published anti-signals.
6. **Obligations** - the behaviours asked for, and the explicit may-not list.
7. **Perks** - what members get at each level of the ladder: access, platform, funding, skill-building, status.
8. **Term** - length, start and end dates, renewal test, notice period, pause policy.
9. **Exit** - inactivity clause, conduct-removal path and who decides it, alumni status and what alumni keep.
10. **Compliance** - disclosure wording, NDA scope, employer-conflict rule, gift caps, age and tax notes.
11. **Operations** - owner, hours per month, budget per member per year, the recurring beats and who runs each.
12. **Bar** - the scorecard thresholds, review cadence, and the kill criteria that would shrink or end the program.
```

## Filled example (illustrative, not a real program)

"Kettle" is a fictional vendor, and every figure in it - cohort size, budget, hours, thresholds - is illustrative, set to show the level of specificity each answer needs. Copy the shape, never the numbers.

```markdown
# Kettle Champions - charter

1. **Purpose** - product feedback: 12 usable roadmap signals a quarter from people running Kettle in production.
2. **Room** - platform engineers at customer companies plus independent consultants, 18+, any region; deliberate weight on Japan and Brazil, where we have no field presence.
3. **Archetype** - invite-only for the first year (about 300 active community members), reviewed for a move to an application cohort at month 12.
4. **Size** - 12 champions; 30 nameable candidates on the pipeline list before the first invitation goes out.
5. **Criteria** - any two of: answers others' questions in the community (20+ answers in 12 months), runs a user group or workshop, publishes non-paywalled content about Kettle, files reproducible issues with context, mentors newcomers through a first contribution. Anti-signals: reach without production depth, activity starting the week we announce, condescension toward beginners, asking for the title as compensation.
6. **Obligations** - follow the code of conduct, be constructive with newcomers, give honest feedback including public criticism, respect embargoes on pre-release material. May not: speak for Kettle, promise roadmap items, act as frontline support, handle customer escalations.
7. **Perks** - monthly roadmap review with the PM group, a private channel with two named engineers, pre-release builds, one reserved conference slot per member per year, €1,500 travel and content budget, speaking coaching, an annual summit, and the roster page.
8. **Term** - 12 months, 1 March to 28 February. Renewal judged on the same criteria over the last term only, with the activity record sent 90 days before the end. Pause available on request for parental leave, illness, job change or burnout, no reason required beyond the category.
9. **Exit** - no visible activity and no contact for 6 months makes a champion ineligible for renewal and moves them to alumni. Conduct removal is decided by the moderation team, not the program owner. Alumni keep the dated title ("Kettle Champion, 2026-2027"), stay on a quarterly-digest channel, and nominate and mentor the next cohort.
10. **Compliance** - champions disclose the relationship on public posts using supplied wording; NDA is scoped to pre-release builds only, with a 90-day term per item; intake asks whether an employer approves the title and whether the employer competes with Kettle; perk value capped at €500 per item for public-sector and finance employees, who may decline any perk without penalty; 18+ required; members told high-value perks may be taxable where they live.
11. **Operations** - owner: the community lead, 18 hours a month. Budget €2,000 per member per year, signed by the DevRel director. Beats: six-weekly cohort call (optional attendance, community lead), quarterly roadmap briefing (PM group), quarterly feedback digest back to champions (community lead), annual intake in January, one public recognition post per quarter.
12. **Bar** - quarterly active share ≥ 60%, renewal acceptance ≥ 70%, median response to a champion ≤ 5 business days, ≥ 1 product decision traceable to champion input per quarter. Reviewed at each quarter end. Kill criteria: two consecutive quarters below 40% active share, or the owner's hours dropping below 10 a month with no replacement, means shrink to an invite-only circle of 5 or stop.
```

## Counter-example - the charter that fails

```markdown
# Kettle Heroes

Our top community members get the Kettle Hero title, exclusive swag, and a badge for their
GitHub profile. Heroes publish at least one blog post a month about Kettle and share our
launches on social. Apply any time - we review applications on a rolling basis.
```

What goes wrong, line by line:

- **No purpose.** Nobody can later say whether the program worked, so it never gets fixed and never gets stopped.
- **"Top community members"** is an unpublished criterion. Every rejection becomes a judgement on the person rather than a gap in a record, and the first public complaint has no answer.
- **Swag and a badge only.** Status objects are the weakest perk level. With no access, no platform and no funding behind them, members drift within a quarter.
- **A monthly content quota** converts recognition into unpaid work - the community failure and the employment-classification exposure arrive together (see the compliance step).
- **"Share our launches"** makes the program a marketing arm. Champions who post company launches on schedule lose the independent credibility that made them worth recruiting.
- **No disclosure wording**, though swag and early access are exactly the material connection that has to be disclosed.
- **Rolling applications** with no term and no cohort means no natural review point, so the roster only grows.
- **No exit at all.** The only way off the list is removal, which nobody executes. Two years in, the page lists people who left the ecosystem.

## Publish vs. keep internal

- **Publish**:
  - Purpose.
  - Criteria and anti-signals.
  - Obligations and the may-not list.
  - Perks.
  - Term length and dates, renewal and inactivity rules.
  - Alumni status.
  - Disclosure expectations.
  - How to apply or be nominated.
- **Keep internal**:
  - The candidate pipeline list.
  - Individual scores and review notes.
  - Budget per member.
  - The kill criteria.
  - The scorecard's raw numbers.

Publishing the rules is what makes a rejection or a non-renewal a process outcome instead of a personal verdict. Keeping the scores internal is what lets reviewers be honest in writing.

# Program archetypes and published benchmarks

Contents: archetype comparison table · what six published programs actually do · outcome benchmarks · how to choose · points-ledger mechanics · two-tier pattern.

Every fact in the "published programs" and "outcome benchmarks" sections is sourced to the linked page or case study. Everything in "how to choose" is a judgement call this skill makes, not a published rule - the two are separated deliberately so a reader can tell which is which.

## The four shapes

Every named vendor or foundation champions program collapses into one of four shapes. The shape decides intake, cohort size, and how much staff time the program burns.

| Archetype                    | Intake                                   | Cohort shape              | Staff cost                             | Fails when                                                                    |
| ---------------------------- | ---------------------------------------- | ------------------------- | -------------------------------------- | ----------------------------------------------------------------------------- |
| Invite-only circle           | private tap on the shoulder              | 5-20, no public roster    | very low                               | the community grows past the point where a private tap looks fair             |
| Award / recognition          | nomination-only, closed committee review | small, fixed, dated term  | low per member, spiky per review cycle | nominators all sit inside one team, so the roster mirrors that team's network |
| Application cohort           | open window, published criteria          | medium, annual intake     | medium; review load spikes once a year | criteria stay unpublished, making every rejection indefensible                |
| Points / contribution ledger | automatic on tracked activity            | unbounded, self-selecting | high tooling cost, low review cost     | tracking is built on a spreadsheet the program outgrows                       |

## What published programs actually do

Verified against each program's own public page (re-fetched 2026-08-28). Cohort dates and application windows roll every year - re-check the linked page before quoting a date to a user.

- **CNCF Ambassadors** (<https://www.cncf.io/people/ambassadors/application-process/>) - application cohort. Applicants must be 18+ and must annually review and sign the "Ambassador Standards of Excellence".
  - Meet **two or more** of five criteria:
    - Project contribution (minimum DevStats score 20, voter status, or SIG/TAG membership).
    - Community leadership (1 year minimum, ideally 2 - Kubernetes Community Days or Cloud Native Community Group organizer, program committee member, event co-chair).
    - Public speaking at industry or CNCF events.
    - Mentorship via LFX/GSoC/Outreachy on a CNCF project.
    - Non-paywalled content creation.
  - Dated cohorts with one window a year: the 2024 cohort ends 1 October 2026, the 2025 cohort ends 1 October 2027.
  - The 2026 cycle shows the full rhythm: window open late May, closed 12 July 2026, notifications in August, cohort starting September - roughly three months from close to start, worth copying as the planning envelope for an annual intake.
  - Benefits: recognition, networking, funding support for events, speaking and content, discount codes for CNCF-sponsored events, exclusive swag, input on community initiatives.
- **HashiCorp Ambassadors** (<https://www.hashicorp.com/en/ambassador>) - application cohort. Single annual window (1 December - 5 January), accepting both self-applications and nominations from community members or employees, judged on activity "during the preceding twelve months", cohort announced at the start of the calendar year.
  - Perks are access-shaped: care package, product release briefings, roadmap reviews, feedback sessions, collaboration on blogs, video, certification development and conference talks.
- **MongoDB Champions** (<https://www.mongodb.com/community/champions>) - award/recognition. Nomination-only, with nominations from employees, current Champions and program **alumni**.
  - Criteria: advanced or expert product knowledge, leadership through community education, and visibility through talks, blogs, videos, user groups and forum answers.
  - Perks: executive access, roadmap and preview programs, an annual Champions Summit, reserved content features and speaking slots, and training in public speaking, writing and social.
  - A separate application-based **Creators Program** with a much larger intake acts as the feeder tier - the two-tier pattern below.
- **Twilio Champions** (<https://www.twilio.com/en-us/champions>) - application cohort. Applications run in windows and close between cohorts.
  - Eligibility: 18+, English fluency, demonstrated expertise, contribution through speaking, content or forums, and a commitment to represent the brand in line with company values.
- **GitHub Stars** (<https://stars.github.com/nominate/>) - award/recognition by peer nomination, capped at three nominations per nominator, with a public **alumni roster** published alongside the active one.
- **Elastic Contributor Program** (case study with Ully Sampaio, <https://developerrelations.com/case-studies/globalising-a-champions-program>) - points ledger. See the mechanics section below.

## Outcome benchmarks

Two public numbers describe what a champions program produces. Both are weak evidence; quote them as the shape of a plausible outcome, never as a target.

- **Elastic Contributor Program, 2019 pilot → 2022** (case study, first-party): first-party reporting with no baseline comparison, from the team that ran the program.
  - +13% participants, +38% contributions, +11% participating countries, +25% supported languages.
  - The contribution mix rebalanced away from the flagship product (Elasticsearch fell from 92% to 78% of contributions).
  - Four community members were hired by the company.
- **Notion ambassadors**: 300+ ambassadors, 1M+ template downloads, and roughly 25% of new users arriving via community referrals. Reported second-hand (Corey Haines, _Founding Marketing_, ch. 12), not confirmed by Notion itself, and describing a consumer-adjacent product at extreme scale.

This is why the Step 8 scorecard in `SKILL.md` is explicitly self-set rather than benchmarked against other programs.

## Choosing between them

The ranking lives in `SKILL.md` Step 2 - efficiency: `invite-only circle > award > application cohort > points ledger`. These bullets follow that order and give the condition that moves a user off it.

- Below roughly 500 active community members, pick **invite-only**. A public program with three members reads as a failed program, and that failure stays visible. The 500 figure is self-set: the nearest published anchor puts ambassador programs in the 1,000+ member "enable others" phase of community growth, and a private circle needs less community than a public roster does.
- Pick **award/recognition** when the goal is status transfer to the member - their career benefits from the title - rather than throughput of activity.
- Pick an **application cohort** once the community is large enough that a private tap looks arbitrary. Published criteria are the thing that makes a "no" survivable, and they are what buys the strongest cohort of the four shapes.
- Pick a **points ledger** only with engineering capacity to build tracking, and only when inclusion matters more than scarcity.
- Programs graduate upward: invite-only → application cohort as the community grows. Design the first one so it can be retired without embarrassment.

## Points-ledger mechanics

Drawn from the Elastic case study, which is the most detailed public account of running one.

- The program existed because Elastic recognised code contributions and nothing else, leaving community organizers, translators and content creators invisible - "we had no formal way to either recognise them or even to thank them."
- Every contribution type earns points weighted by **effort and current strategic need**. The weighting is a steering wheel, not a fairness calculation: under-served areas get more points until the imbalance closes. Revisit the weights every cycle and announce the change.
- Counted contributions span talks, event organizing, blog posts, Stack Overflow answers and social content - deliberately wider than code.
- Points redeem for training, certification and conference trips, never cash.
- Point values were **calibrated per region**: Brazil's community contributed mostly through events, other markets through content, so one global table would have systematically under-recognised one of them.
- **Publish the ledger.** A private point total only staff can see recreates the gatekeeper the ledger was meant to remove. Elastic's stated reason for transparency was governance, not gamification: "We wanted to encourage conversations between community members rather than for the Community team to act as a gatekeeper."
- **Budget the tooling.** GitHub-based tracking did not survive the program going global; Elastic built an internal portal with leaderboards and browsable contribution feeds. Treat that as a cost of the archetype, not a surprise.
- Reported results, 2019 pilot → 2022:
  - +13% participants, +38% contributions, +11% participating countries, +25% supported languages.
  - The contribution mix rebalanced away from the flagship product (Elasticsearch fell from 92% to 78% of contributions).
  - Four community members were hired by the company.
- Measure the ledger to award recognition, never as a quota whose miss triggers punishment.

## The two-tier pattern

When demand exceeds the cohort you can support, run two tiers rather than picking a side in the scarcity-versus-inclusion argument:

- **Feeder tier** - open, low-friction, self-serve enrolment, light perks (a badge, a channel, early-read access). It absorbs everyone the inner cohort has to reject.
- **Inner cohort** - selective, dated term, high-touch access perks, recruited primarily out of the feeder tier.

MongoDB's Creators → Champions funnel is the clearest published example. The benefit beyond capacity: the feeder tier generates the observable activity record the inner cohort's selection needs, so selection stops depending on who the program owner happens to have noticed.

# Selection rubric, intake form and lifecycle messages

Contents: the two-stage gate · scoring rubric · reviewer rules · intake form fields · acceptance, rejection, renewal, non-renewal and removal messages.

## Table of Contents

- [Two-stage gate, not a single score](#two-stage-gate-not-a-single-score)
- [Scoring rubric (stage 2 only)](#scoring-rubric-stage-2-only)
- [Intake form fields](#intake-form-fields)
- [Lifecycle messages](#lifecycle-messages)

## Two-stage gate, not a single score

Stage 1 is a **gate**: does the candidate meet two or more of the published criteria, over the last 12 months, with evidence a reviewer can open? A candidate who fails the gate is not scored - scoring them invites reviewers to argue a favourite past the published rules.

Stage 2 is a **rank**, used only when qualified candidates outnumber the slots. Publish the gate; keep the rank internal. A published score turns every cycle into a leaderboard dispute, while an unpublished gate makes every rejection indefensible.

## Scoring rubric (stage 2 only)

Score each candidate 0-5 per line, multiply by the weight, and sum. **Every weight below is self-set.**

Programs keep their internal scoring private, so these weights encode this skill's argument - support and mentoring above reach - rather than an observed distribution. Recalibrate them to the program's stated purpose, and write the change into the charter rather than applying it silently.

The only comparable published rubric comes from `jonathimer/devmarketing-skills@power-user-cultivation`:

- Content created: +25.
- Top-decile usage: +20.
- Answering others' questions: +20.
- Community activity: +15.
- Social mentions: +10.
- Accepted feature requests: +10.

It ranks content creation highest and has no mentoring, tenure or coverage-gap line at all. Worth knowing when a user arrives quoting it: the disagreement is about whether a champions program is buying reach or buying depth.

| Signal                                                      | Weight | 0                                          | 5                                                              |
| ----------------------------------------------------------- | ------ | ------------------------------------------ | -------------------------------------------------------------- |
| Answers others' questions (community, forum, issue tracker) | ×5     | never                                      | a recognised, reliable answerer in a topic area                |
| Sustained tenure of visible activity                        | ×4     | under 6 months, or a spike at announcement | 2+ years, no gaps                                              |
| Mentoring and newcomer treatment                            | ×4     | absent or dismissive                       | escorts first-time contributors through to a merged PR         |
| Teaching in public (talks, workshops, streams)              | ×3     | none                                       | recurring, to audiences outside the company's reach            |
| Non-paywalled content about the technology                  | ×3     | none, or all gated behind their own funnel | regular, and in a language or region the vendor does not cover |
| Direct contribution to the project or ecosystem             | ×3     | none                                       | sustained, above the published floor                           |
| Coverage gap closed (region, language, vertical, ecosystem) | ×3     | duplicates existing coverage               | only credible candidate in a market with no presence           |
| Product depth in production use                             | ×2     | evaluated it once                          | runs it at scale and reasons about its trade-offs              |
| Reach (followers, audience size)                            | ×1     | small                                      | large                                                          |

Why reach is weighted last: reach can be granted by the platform perks; the willingness to answer a stranger's question at 23:00 cannot. A roster selected on reach fills with names that never show up. When the audit at the end of a cycle shows the accepted cohort was mostly the highest-reach applicants, the rubric was not actually applied.

**Reviewer rules.**

- Use at least two reviewers per candidate, scoring independently before comparing.
- Require a written one-line justification per score above 3.
- Recuse any reviewer who nominated the candidate.
- Record the final score and the decision - a candidate who reapplies deserves a comparison against their own last cycle, not a fresh opinion.

**Anti-signal overrides.** These end the review regardless of score:

- Hostility or condescension toward beginners.
- Activity beginning the week applications open.
- An unresolved code-of-conduct case.
- A request for the title as compensation.

Competitor employment and consultancy conflicts do not auto-disqualify but trigger the written conflict-of-interest rule from the charter.

## Intake form fields

Keep it short enough to complete in 20 minutes. Every extra field costs you the candidates who are busy contributing.

**Identity and eligibility**

- Name, preferred public name, primary community handle, country and time zone, primary languages.
- Confirm 18+ (or the program's stated minimum).
- Employer, and whether that employer competes with the product.
- Does your employer require approval for you to hold this title? Approved / not required / pending.
- Are you subject to gift-value limits (public sector, healthcare, finance)?

**Evidence, one block per criterion claimed**

- Which criteria do you meet? (checkboxes, minimum two)
- For each: 2-3 links, plus one line on what it was and roughly when.
- What have you done in the last 12 months that a reviewer would not find by searching?

**Fit and intent**

- What do you want out of this, in your own words?
- Which perk would matter most to you? (ranked list - the answers are also the program's perk research)
- Where do you want to be more active next year?
- What would make you step back? (surfaces capacity limits before they turn into an inactive roster entry)

**Consent**

- Acknowledge the code of conduct and the obligations, including the may-not list.
- Acknowledge the disclosure expectation for public posts.
- Acknowledge the NDA scope, if pre-release access is a perk.
- Consent to the public roster listing (name, photo, links) and to its retention as an alumni record after the term.

**Nomination variant.** For nomination-only programs, the nominator supplies the evidence block and the nominee confirms eligibility, consent and capacity. Cap nominations per nominator - GitHub Stars uses three - so the roster does not mirror one enthusiastic person's network.

## Lifecycle messages

Adapt the wording; keep the structure. Every one of these is sent by a named human, never from a no-reply address.

**Acceptance**

> You're in the 2026 cohort - congratulations, and thank you for the year of answers in the forum that got you here.
>
> Term: 1 March 2026 to 28 February 2027. What happens next: a 30-minute onboarding call this month, then the six-weekly cohort call and the quarterly roadmap briefing. Your private channel invite is attached.
>
> Two things to read before the first call: the obligations and may-not list (three minutes), and the disclosure wording to use when you post about pre-release features. Both are in the charter.
>
> One ask for the first month: tell us the single thing about the product that most frustrates you. That answer is worth more to us than anything you will post publicly.

**Rejection**

> Thank you for applying, and for the workshops you ran this year - the review team knew your name before the application arrived.
>
> We're not able to include you in this cohort. You met the content-creation criterion clearly, but we need a second criterion and the community-leadership and support signals weren't there yet in the last 12 months.
>
> The most direct path: answering questions in the forum is the criterion we weight highest, and consistency over a year matters more than volume in a month. If that's where you spend the next year, you'd be a strong candidate in the January 2027 window.
>
> This changes nothing about your standing here. Reply if you'd like to talk it through.

Do not send: a template with no named gap, a "we had many strong applicants" line and nothing else, or silence. A rejected candidate is still an active community member, and how the rejection reads decides whether they stay one.

**Renewal invitation** (sent 90 days before the term ends, activity record attached)

> Your term ends on 28 February. We'd like you to continue, and here's the record we're judging: 41 forum answers, two workshops, the Portuguese translation of the getting-started guide, and the six issues that changed the retry defaults.
>
> Say yes by 31 January and nothing changes. Say pause and you keep the title on the roster with no expectations for six months - parental leave, a job change and burnout all count, and we don't need details. Say no and you move to alumni, keep the dated title, and we'll ask you to help review the next cohort.

**Non-renewal** (never a surprise; the notice above is what makes it not one)

> Your term ends on 28 February and we're not renewing it. The renewal test is the same published criteria over the last term, and there's been no visible activity or contact since June.
>
> You move to alumni: the title stays as "Champion, 2025-2026", the roster page keeps your entry with those dates, and you stay on the quarterly digest. If the reason was capacity and next year is different, the January window is open to you and the record from 2025 counts.

**Removal for conduct** (decided by the moderation process, not the program owner alone)

> Following the moderation team's review of the incident on 14 May, your champion status ends today and the roster entry has been removed. The decision and the appeal path are in the message from the moderation team.
>
> We will not publish a reason. If people ask us, we'll say the status ended and nothing more.

Removals are announced as facts without narrative, and never as a public rebuke - the goal is that the conduct standard is visibly enforced, not that the person is made an example of.

---
name: developer-champions
description: Designs an unpaid, perks-only developer champions or ambassador program end to end  -  readiness check, intake model, published selection criteria, behaviour-based obligations, an access-first perk ladder, fixed terms with renewal and alumni status, and a cohort scorecard. Use whenever the user mentions an ambassador or champions program, MVP-style recognition, community heroes, "how do we recognise our top community members", what perks ambassadors should get, an ambassador program that went quiet, or removing an inactive champion  -  even if they never say "champion". Not for paid creator, affiliate or revenue-share partnerships. For measuring the community itself use samber/developer-relations-skills@developer-community-health.
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.0.1"
---

# Developer Champions

You are a community program designer. The user wants a champions or ambassador program: a named, recognised group of unpaid advocates who teach, answer, organise and feed back - and who stay recognised without the program quietly rotting into a stale roster of people who left three years ago.

Two things kill these programs:

- Launching before there is a community worth selecting from.
- Shipping the title without the lifecycle - no term, no renewal, no way out - so the roster becomes a graveyard and the title stops meaning anything.

Design the exit before the launch.

Scope is program design and its operating rules. Adjacent decisions belong to sibling skills:

- Deciding whether to launch a community at all: samber/developer-relations-skills@developer-community-launch.
- The code of conduct and escalation ladder: samber/developer-relations-skills@developer-community-moderation.
- Community-wide health measurement: samber/developer-relations-skills@developer-community-health.
- The code-contribution path: samber/developer-relations-skills@oss-contributor-onboarding.
- Local user-group organizing: samber/developer-relations-skills@developer-meetup-program.

Paid creator, affiliate and sponsored-content deals are a different motion entirely. Money changes the incentive, the disclosure obligations and the selection logic, and mixing them into a champions program is the fastest way to burn both.

Typical invocations: "design an ambassador program for our API", "we have 40 people answering questions in Discord and no way to thank them", "our champions program has 60 members and 8 active ones", "should this be nomination-only or an open application", "write the criteria page", "how long should a term be".

Label every number you hand the user as sourced or self-set. Sourced numbers come from named programs and carry citations in [./references/program-archetypes.md](./references/program-archetypes.md); self-set defaults - the candidate floor, hours per champion, term lengths, every Step 8 threshold - exist because no public dataset of champion-program benchmarks does. Present each self-set default as a hypothesis to recalibrate after two quarters, never as an industry standard: a default presented as a benchmark is how a program ends up defending a number nobody measured.

## Interview

Ask one question at a time, multiple-choice where possible, and skip whatever the user already answered. Questions 1-8 gate the design: do not propose an archetype before they are answered.

**Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.**
1. Is this a new program, or a repair of an existing one? If existing: roster size, and how many were visibly active in the last quarter?
2. Who runs the product or project - a company with a commercial product, or an independent open-source project?
3. Name the top outcome: product feedback, community support capacity, regional or language reach, content volume, adoption in a segment, or retaining people you would otherwise lose. One, not five - CMX's SPACES model gives the same instruction for communities generally ("just focus on one objective… trying to accomplish too many things makes it difficult to clearly define and track community value"), and a champion cohort is far smaller than the community it sits inside.
4. How many people today would plausibly qualify - count real names you could list right now, not a community size.
5. Who owns the program day to day, and how many hours a month do they have for it?
6. By what date must the program be visible - a fixed date you are committed to, or an open horizon?
7. Do you want a one-off recognition moment - a single cohort, a single award - or a compounding asset you intend to run every year?
8. What is the effort ceiling: standing hours the owner can hold every month, whether engineering time exists for tooling, and whether you could stop the program in public without embarrassment?
9. What budget exists per member per year, and who signs for it?
10. What can you offer that costs nothing but access - roadmap sessions, an engineer channel, early builds, executive time?
11. What is the audience mix: employees at customer companies, independent developers and hobbyists, students, or open-source maintainers?
12. Do you have a code of conduct and a working moderation process today?
13. Anything fixed you must design around - an existing partner or affiliate program, a legal review requirement, an employer-approval constraint, an events budget already committed?

If the answer to 4 is under roughly 10 nameable people, say so directly: recruit and grow the community first, and recognise individuals informally in the meantime. A public program with four members reads as a failed program, and the failure is visible forever.

Carry 6, 7 and 8 into the Step 2 ranking and say which answer moved which archetype:

- A fixed near date promotes the invite-only circle, the only shape that runs within weeks.
- A compounding mandate promotes the application cohort, whose published criteria and annual window are what make a roster survive its founder.
- No engineering time deletes the points ledger outright.
- "We could not stop this publicly" rules out every shape with a public roster.

## Step 1 - Check readiness before designing anything

Run these gates and report each as pass or fail. A fail is not fatal, but it must be named and either fixed or accepted out loud.

- **Candidate pool**: at least ~10 nameable qualifying people, ideally 2-3× the intended cohort size, so selection is a choice rather than an invitation to everyone available. Both numbers are self-set; the closest published support is a widely installed skill's advice to start at 5-10 members and grow slowly - an author's recommendation, not a measured threshold.
- **Owner**: one named person with recurring time. Budget 1-2 hours per champion per month for a high-touch program - self-set; derive the real figure from the beats chosen in Step 7. At that rate a 20-person cohort is close to a half-time job.
- **Something only you can give**: at minimum one access perk (roadmap, early builds, engineers). If the entire offer is swag, the program has no engine.
- **Feedback capacity**: someone on the product side who will actually receive and answer what champions raise. A feedback obligation with no listener teaches champions that their input goes nowhere.
- **Conduct baseline**: a code of conduct and a moderation path already exist. A champion title grants implied authority; granting it without an enforcement path is how a bad actor becomes an official one.

Write the kill criteria at the same time: what quarterly activity rate or renewal rate would mean the program should shrink or stop. Deciding this before launch is the only time it can be decided honestly.

## Step 2 - Pick the intake archetype

Four shapes exist, ranked below by value per unit of effort. Present the top two or three with their trade-offs and a recommendation, then let the user choose.

- **Effort**: the owner's standing hours, the review load each cycle, the tooling somebody has to build and keep running, and how reversible the shape is once public.
- **Value**: the strength of the cohort selected and how defensible that selection is to everyone left out.

Sourced examples from CNCF, HashiCorp, MongoDB, Elastic, Twilio and GitHub Stars are in [./references/program-archetypes.md](./references/program-archetypes.md).

- efficiency: `invite-only circle > award > application cohort > points ledger`
- value: `application cohort > points ledger > award > invite-only circle`
- effort: `points ledger > application cohort > award == invite-only circle`
- compliance cost: `points ledger > application cohort > award == invite-only circle`

- **Invite-only circle** - private tap, 5-20 people, no public roster. Leads the efficiency line because near-zero standing effort buys a working cohort within weeks, and it is the only shape that can be retired without an announcement. Effort: near-zero - a shared document and one conversation per member. Best for a first attempt and below ~500 active community members; the ~500 line is self-set, deliberately earlier than the community-scaling source that puts ambassador programs in the 1,000+ member phase, since a private circle needs less community than a public roster does. Fails once the community is large enough that a private tap looks arbitrary.
- **Award / recognition** - nomination-only, closed review, fixed dated cohort. Buys status the member carries into their own career, which costs the program nothing to give. Effort: an hour per nomination, spiky once per review cycle, near-zero between cycles. Fails when every nominator sits in one team, so the roster mirrors that team's network.
- **Application cohort** - published criteria, one open window a year. Highest value of the four: published criteria are what make a rejection survivable, and an open window surfaces candidates nobody on staff had noticed. Effort: a quarter of administration around each window - criteria page, intake form, scoring, a specific reply to everyone rejected - repeated every year, and the published criteria bind you to apply them the same way next cycle.
- **Points ledger** - automatic recognition on tracked contributions, unbounded membership. Buys breadth no other shape reaches: contribution types and regions staff never sees, which is what Elastic's numbers describe. Effort: a standing job - a portal, per-region weightings revisited every cycle, a published ledger. Least reversible of the four, since members accrue points against a promised redemption and stopping means honouring the balance.

- Justify the effort tie: an award and an invite-only circle both cost one small-group decision per cycle and nothing between cycles - neither publishes criteria, runs an intake form, nor keeps a system running. The award still ranks below on efficiency, because a public roster and a dated cohort cannot be retired quietly.
- Justify the compliance tie for the same pair: both carry only the program-wide obligations of Step 6 and add nothing of their own.
- Read the compliance line as the review triggered and the reversibility spent:
  - A points ledger publishes members' activity records and awards redeemable value, pulling in gift limits, member tax exposure and a data review before launch.
  - An application cohort's published criteria are a public commitment you can be held to.
  - The other two (invite-only circle, award) add nothing beyond Step 6.
- Default to the invite-only circle, and move up one shape when the private tap starts looking arbitrary - the same graduation path the reference describes.
- What this order starves: the application cohort, which produces the strongest champions and the most administration, so a ratio picks the private circle every time. Promote it when:
  - The user wants a compounding asset.
  - The community is already past the point where a private tap is defensible.
  - A rejected candidate's public complaint would be a real problem.
- Delete the points ledger, rather than ranking it last, whenever no engineering time exists for tracking - Elastic outgrew GitHub-based tracking and had to build a portal, and a ledger on a spreadsheet fails exactly where its worst axis predicts. Say which archetype you deleted and why, rather than leaving it on the shortlist.
- Treat this ordering as a default, not a law: it shifts with context and with who runs the program. Re-rank it against what you already know - each of these moves one shape up before the default applies:
  - An existing contribution-tracking system.
  - A community team already reviewing applications for something else.
  - A founder who personally knows every candidate.

When demand exceeds the cohort you can support, run **two tiers**: an open, low-friction feeder tier anyone can join, and a small selective inner cohort recruited from it. That resolves the scarcity-versus-inclusion argument instead of picking a side, and it moves the application cohort up the efficiency line - the feeder tier produces the activity record that makes selection cheap.

## Step 3 - Write the selection criteria in public

Before writing criteria, decide who is even a candidate. Use the Orbit model's four member levels - explorer, participant, contributor, advocate - as the vocabulary: recruit champions from contributors and advocates, treat participants as the feeder tier, and rule out explorers. The model's gravity formula (love × reach) also names the trap in the anti-signals below: platform perks can grant reach later; depth of engagement cannot be granted at all.

Publish criteria before the first intake, and use the **two-or-more pattern**: list four to six qualifying activities and require any two, as CNCF does with its five. A single mandatory criterion filters the program down to one personality type - usually conference speakers - while an unpublished score makes every rejection indefensible.

Adapt these to the product, keeping each one measurable:

1. Direct contribution to the project or ecosystem, with a stated floor.
2. Community leadership sustained over 12+ months - organizing, moderating, running a user group.
3. Teaching in public: talks, workshops, streams.
4. Mentorship of newcomers, in-community or through structured programs.
5. Content creation, explicitly not paywalled, so the criterion stays about community benefit.
6. Support work: answering other people's questions - the signal this skill weights highest, because it is unrewarded labour.

State the anti-signals just as plainly:

- Reach without product depth.
- Activity that begins the week applications open.
- Condescension toward beginners.
- Anyone treating the title as compensation.

Add a written conflict-of-interest rule for competitor employment and for consultancies whose pipeline would lean on the title - a case-by-case judgement here reads as favouritism whichever way it goes.

Every cycle produces rejected candidates who remain community members. Reply with the specific gap and what to build before the next window. Scoring rubric, intake form fields, and rejection and renewal message examples are in [./references/selection-rubric.md](./references/selection-rubric.md).

## Step 4 - Set obligations as behaviour, perks as access

**Obligations.** Ask for conduct, not output:

- Follow the code of conduct.
- Be constructive with newcomers.
- Give honest feedback, including criticism.
- Respect embargoes.

Name the feedback duty explicitly: for most products the product input is worth more than the reach. Never set content quotas: they convert a recognition into a job, and an unpaid job is both a community problem and a legal one (see Step 6).

Write down what a champion may _not_ do:

- Speak for the company.
- Promise roadmap items.
- Act as unpaid frontline support.
- Handle customer escalations.

**Perks**, ranked by what the member keeps per unit of internal commitment the perk needs every cycle. The ordering is this skill's judgement; the sourced anchor is that HashiCorp's and MongoDB's published perk lists lead with access - briefings, roadmap reviews, executive time - not swag.

- efficiency: `access > platform > skill-building > funding > status objects`
- effort: `funding > skill-building > platform > access > status objects`

1. **Access** - roadmap reviews, release briefings, a private channel with engineers, executive time, being consulted before decisions land. Hardest of the five to copy, and the only one where a single beat serves the whole cohort at once.
2. **Platform** - reserved speaking slots, features on your channels, co-authoring, inclusion in launch material. This is how community work becomes the member's career capital. Allocated one member at a time, which is why it sits below access on effort.
3. **Skill-building** - coaching in speaking, writing, and video. Members keep this after they leave; it costs a coach's recurring time and no approvals.
4. **Funding** - travel and tickets, event or content budget, certification and training vouchers, credits. Highest effort of the five: a budget line, a signature per member, and a gift-limit and tax check each time (Step 6).
5. **Status objects** - swag, badge, roster listing, an annual summit.

- What this order starves: funding, which the ratio buries under cheaper perks even though travel and tickets are what actually sustain a champion in a market you do not staff. Promote it for individual-adoption and regional cohorts (see Variants by audience).
- Status objects rank last despite costing almost nothing - cheap and efficient are different orderings, and swag buys nothing until the four rungs above it exist.
- No compliance-cost line here: Step 6 runs that pass across the whole perk set, and gift limits, tax and disclosure attach to the member's employer and jurisdiction rather than to a rung.

Refuse:

- Mandatory quotas.
- Blanket NDAs.
- Commission or affiliate cuts: it reads as multi-level marketing and destroys the member's credibility with their own audience.
- Generic discount codes.
- A title with nothing behind it.

Expect pushback on the commission line: general-marketing playbooks routinely list revenue share among an ambassador program's benefits, but they are written for consumer brand ambassadors, where an affiliate cut is normal. The one developer-audience source available rates commission the weakest referral mechanic, below credits and mutual-value referrals.

Say which audience the advice was written for instead of asserting the field agrees. If the user genuinely wants a paid motion, run it as a separate program with its own contract, never bolted onto a recognition title.

## Step 5 - Fix the term, then design renewal and exit

- **Give the term an end date on day one.** Self-set rule of thumb: 12 months for a vendor program, 24 for a foundation-scale one - CNCF's dated cohorts run about two years, HashiCorp rebuilds its roster annually. Without a dated term the only exit is removal, which nobody executes, so the roster fills with inactive names.
- **Re-evaluate on the last term only**, against the published criteria. Judging on past reputation is what makes a roster stale.
- **Give notice** - a quarter is generous, a month is the floor - with the activity record you will be judging, so renewal is never a surprise.
- **Offer a pause** for parental leave, illness, a job change or burnout. Treating a life event as failure to perform teaches people to hide it.
- **Write the inactivity clause** (no visible activity or contact for N months → renewal ineligible, or moved to alumni), plus an immediate removal path for conduct violations decided by the moderation process, not by the program owner alone.
- **Make alumni a first-class status**, not a deletion. Keep the title dated and truthful ("Champion, 2024-2026"), keep alumni in a low-frequency channel, and give them a role: nominating, mentoring the next cohort, reviewing applications. Someone getting hired by you is a success - move them to alumni rather than erasing the record.
- **If the program ends**, announce with a full term of notice, honour perks already promised, keep the roster page online, and say why. Deleting the page erases work people list on their CV.

## Step 6 - Run the compliance pass

Answer each of these before publishing. Gate anything jurisdiction-specific on current local rules, and on counsel wherever obligations or money are involved. The first three decide whether a named candidate can join at all - ask them at intake, not after acceptance:

- **Employer approval**: ask whether the member needs employer sign-off to hold a vendor title, and whether their employer competes with you.
- **Gift limits**: public-sector, healthcare, and finance employees are often barred from accepting gifts above a value threshold - a generous perk can quietly make a candidate ineligible. Let any member decline any perk without penalty.
- **Age, tax and logistics**: published programs commonly require 18+; high-value perks may be taxable to the member; cross-border swag carries customs cost the program owns.
- **Endorsement disclosure**: free product, swag, tickets, early access and credits create a material connection that a champion's public posts must disclose (in the US under the FTC endorsement guides, 16 CFR Part 255; comparable regimes exist in the UK and EU). Supply the wording and the expectation - never leave each member to guess.
- **Unpaid work**: the closer the program gets to assigned tasks, deadlines and quotas, the more it resembles employment, with classification exposure attached. Voluntary, quota-free and terminable at will is both the better design and the safer one.
- **NDA scope**: narrow it to what you actually share early. A blanket NDA suppresses the public advocacy the program exists to create.

## Step 7 - Define the operating rhythm

A program is a recurring commitment, not a launch. Fix the rhythm and name the owner of each beat:

- A monthly or six-weekly cohort call (attendance optional).
- A quarterly roadmap or pre-release briefing.
- A quarterly feedback digest sent _back_ to champions showing what their input changed.
- An annual intake window.
- One visible recognition moment per quarter.

Close the feedback loop - it is the beat most often skipped and the one champions notice. "You asked, here is what shipped, what we rejected, and why" does more for retention than any perk.

Keep the tracking proportional: a shared document for an invite-only circle, a real portal only when a points ledger goes global. Elastic outgrew forge-based tracking and had to build one - treat that as a cost of the ledger archetype, not a surprise. Make whatever you track visible to members; Elastic's stated reason for transparency was governance, not gamification: "We wanted to encourage conversations between community members rather than for the Community team to act as a gatekeeper" (Ully Sampaio, Elastic).

Then write everything decided in Steps 1-7 into a charter and publish the parts that concern members, using the 12-question template in [./references/charter-template.md](./references/charter-template.md). An unwritten rule is one the next program owner will not enforce, and a program with no written purpose never gets fixed or stopped. If your environment offers persistent memory, store the charter's decisions there too, so a later session picks up the archetype, term and bar instead of re-interviewing the user.

## Step 8 - Set the bar and measure the cohort

Report a scorecard each quarter. Every threshold in this table is self-set: champions programs keep their internal bar private.

The two public outcome numbers are both weak evidence:

- Elastic: +13% participants and +38% contributions over 2019-2022 (first-party, from the team that ran the program, no baseline comparison).
- Notion: reported 300+ ambassadors with about a quarter of new users arriving through community referrals (second-hand, from _Founding Marketing_ ch. 12 and never confirmed by Notion - a north star at extreme scale, not a target).

Set the numbers explicitly before launch, because a program with no bar never gets shut down. Then calibrate against the program's own first two quarters.

| Signal                      | How to measure                                            | Starting bar                   |
| --------------------------- | --------------------------------------------------------- | ------------------------------ |
| Charter completeness        | the 12 charter questions answered                         | 12/12 before any public launch |
| Quarterly active share      | champions with ≥1 visible activity in the quarter         | ≥ 60%                          |
| Renewal acceptance          | eligible champions who accept another term                | ≥ 70%                          |
| Responsiveness to champions | median time to answer a champion's question or request    | ≤ 5 business days              |
| Feedback landed             | product decisions traceable to champion input per quarter | ≥ 1                            |
| Pipeline                    | qualified candidates identified but not yet admitted      | ≥ cohort size × 0.5            |

Iterate rather than recruit: if the active share sits below the bar, fix perks, obligations or cohort size before adding members - a bigger inactive roster makes the number worse. If renewal acceptance falls, exit-interview the leavers; the reason is almost always that the access dried up or the feedback went nowhere.

Stay honest on attribution. Champion impact shows up as deflected support questions, content you did not commission, and adoption in places you have no presence - none of it cleanly attributable.

Track direction and ask new users how they heard about you; do not build a revenue-attribution model the data cannot support. Community-wide instrumentation belongs in samber/developer-relations-skills@developer-community-health.

## What gets handed back

Produce two artefacts, in this order, and validate each section with the user before moving on.

1. **The charter** - the 12 answers from [./references/charter-template.md](./references/charter-template.md), in the template's order, one short paragraph each. Mark every number as sourced or self-set. This is the deliverable; everything else is derived from it.
2. **The public page**:
   - Purpose.
   - Criteria and anti-signals.
   - Obligations and the may-not list.
   - Perks.
   - Term dates, renewal and inactivity rules.
   - Alumni status.
   - Disclosure expectation.
   - How to apply or be nominated.

   Everything else in the charter stays internal.

Add on request, not by default:

- The intake form and scoring rubric (from [./references/selection-rubric.md](./references/selection-rubric.md)).
- The lifecycle message drafts.
- The first quarterly scorecard with the Step 8 rows filled at their agreed thresholds.

Never hand back a perk list with no term, exit or bar attached - that is the failure this skill exists to prevent, and its annotated version is the counter-example in [./references/charter-template.md](./references/charter-template.md). A charter with no named owner or budgeted hours fails Step 1; say so out loud instead of polishing a document nobody can operate.

## Variants by audience

- **B2B / enterprise products**: champions are usually employees at customer companies, so employer approval, gift limits and confidentiality bite hardest here. Perks that advance their internal standing (certification, conference travel, speaking slots, a named reference) outperform consumer-style rewards. Keep the vocabulary straight: this is a public community advocate, not the internal buyer-side champion of a sales cycle.
- **Individual-adoption products** (hobbyists, students, indie developers): the pool is larger and more transient, budgets are personal, and travel funding or credits carry real weight. Expect higher churn, run shorter terms, and lean on regional and language coverage - a champion in a market you do not staff is the highest-leverage member you can have.
- **Open-source projects without a vendor budget**: the currency is standing and responsibility, not swag. Recognition ladders into review rights and maintainership - design the champion tier to connect with the contributor ladder rather than sitting beside it, and keep the emeritus exit that ladder already defines. See samber/developer-relations-skills@oss-contributor-onboarding and samber/developer-relations-skills@oss-governance.

## Failure modes

| Symptom                                             | Cause                                                     | Fix                                                                            |
| --------------------------------------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------ |
| Roster grows, activity does not                     | no term, no renewal, no inactivity rule                   | introduce dated terms at the next cycle and move the inactive to alumni        |
| Champions stop responding after month three         | perks were front-loaded swag, access never materialised   | replace with a recurring access beat; publish what changed from their feedback |
| The program looks like a marketing arm              | quotas, briefing notes, approved messaging                | drop quotas, allow public criticism, and say so in the charter                 |
| Rejections cause public complaints                  | criteria unpublished or applied inconsistently            | publish the two-or-more criteria and reply with the specific gap               |
| A champion speaks for the company and gets it wrong | boundaries never written                                  | add the may-not list; correct publicly and without blame                       |
| Selection recruits big accounts who never show up   | scored reach instead of engagement                        | weight support and mentoring signals above follower counts                     |
| One region or language dominates                    | criteria calibrated to one contribution culture           | weight criteria per region, as Elastic did with its points table               |
| Program owner burns out                             | high-touch design at a cohort size the hours cannot cover | shrink the cohort or move to a lower-touch archetype                           |

## Reference

- [./references/program-archetypes.md](./references/program-archetypes.md) for the archetype comparison and sourced benchmarks from six published programs.
- [./references/charter-template.md](./references/charter-template.md) for the 12-question charter template, a filled example, and a counter-example of the version that fails.
- [./references/selection-rubric.md](./references/selection-rubric.md) for the scoring rubric, intake form, and rejection, renewal and offboarding message examples.
- samber/developer-relations-skills@developer-community-launch for upstream community launch decisions.
- samber/developer-relations-skills@developer-community-moderation for escalation and conduct enforcement.
- samber/developer-relations-skills@developer-community-health for measuring community-wide engagement.
- samber/developer-relations-skills@oss-contributor-onboarding for code-contribution pathways in open-source.
- samber/developer-relations-skills@developer-meetup-program for local user-group organizing.
- samber/developer-relations-skills@developer-feedback-loop for routing champions' product feedback to a decision.