Chapter 5 — Turn Audiences into Participants

The ambassador program with nothing to be an ambassador for

Composite. Built from recurring patterns across several community-program reviews; no identifying detail.

The program launch deck is genuinely good. Two hundred applicants, sixty accepted, a private channel, a hoodie, a monthly call, a badge for a personal site. The company calls them ambassadors, and the first quarter looks healthy: reposts, meetup talks, a spike in referral traffic.

By month five the private channel has gone quiet except for the program manager’s monthly prompt. Eleven of the sixty have stopped responding. One of them writes a short exit note that the program manager forwards up the chain, and the whole diagnosis is in three sentences: the ambassador found four errors in the workshop deck she was asked to present, filed them, and got no reply; she was asked to post about a release she had not been able to test; when an attendee harassed her in a meetup chat she did not know who to tell.

Look at what the program gave her and what it withheld. She received messages, merchandise, a quota, and a title. She had no access to the engineers who owned the workshop, no authority to correct a deck with her name on it, no budget for the room she booked at her own expense, no reporting route when someone made her event unsafe, and no visible way to move from presenting someone else’s material to shaping it. She was asked to lend credibility outward while receiving none of the standing that would make that credible.

The program had participants. It had almost no participation. The question this chapter answers is what has to be structurally true — in roles, rights, decision boundaries, safety process, and governance — before an invitation to join is an invitation to affect anything.

Agency is the line that matters

Five words get used as though they were degrees of the same thing, and the substitution hides the only transition that changes a relationship.

Attention means a person saw or heard something. Engagement means they reacted — a star, a reply, a question in a session. Participation means they contributed to a shared activity: answered someone else’s question, fixed a broken sample, ran the local meetup. Agency means they can affect an outcome — a decision, a standard, an artifact, a roadmap area — through a route that exists whether or not any individual staff member likes them that week. Stewardship means they carry continuing responsibility for whether the shared thing stays healthy after the people who started it leave.

Attention through participation can all be produced by a sufficiently good marketing program. Only the last two require the organization to give something up. That is why programs stall at participation: everything up to that point costs money and effort, and the next step costs control.

None of this is a demand that every member become a leader. Most people in a healthy community sit at observe, ask, or answer for years, and that is a complete way to belong — the person who answers three questions a month in a forum is doing load-bearing work, not incomplete work. What a program owes them is that the higher stages be real rather than decorative. A member should be able to look at the route from where they are to a decision that matters and see actual holds: named criteria, named sponsors, a published scope of authority. When those holds are painted on, people find out, and the ones who find out first are usually the ones you most wanted.

Study the artifacts: participation stages, membership rules, and enforceable norms

Three public sources answer three different questions about the same problem. Read them together.

Artifact one: Jono Bacon’s community participation model, developed in The Art of Community (O’Reilly, first edition 2009; second edition 2012) and in his later consulting writing. Chapter 4 used his on-ramp work; the relevant part here is the progression past it — the observation that communities have distinguishable bands of involvement, that most members never leave the outer band, and that the health question is whether movement inward is possible and supported rather than whether everyone moves. Observable mechanic: the model treats each band as a designed state with its own entry conditions and its own kind of support, which forces a program to say what it actually offers a regular contributor that it does not offer a newcomer. Limit: the model is descriptive and portable, which means it tells you the shape and not the content. Two programs can both implement it and one can still be extractive, because the model does not require that inward movement come with rights.

Artifact two: the Kubernetes community membership documentation (community-membership.md in the kubernetes/community repository; read at access date 2026-07-25 — this file is revised, so check the current version before copying specifics). It answers the content question. Each role — member, reviewer, approver, subproject owner — is written as a row of requirements, responsibilities, and privileges, and the requirements are inspectable: a sustained contribution history, sponsorship by existing reviewers or approvers, subscription to the development list. Observable mechanic: the document makes sponsorship a named role’s act rather than a friendship. Sponsors have public review histories, so a candidate can identify who could sponsor them and see what those people have already approved. Transferable method: write each role as requirements, responsibilities, and privileges in the same table, so that no role can be added to the ladder without someone specifying what the holder receives. Limit: Kubernetes is a large multi-vendor project with enough contributor volume to support formal review roles. A twelve-person project that imports this structure produces a ladder nobody can climb because nobody qualifies to sponsor. Copy the columns, size the rungs to your population.

Artifact three: the Contributor Covenant (version 2.1, published 2021; Coraline Ada Ehmke and contributors). It answers the enforcement question. The interesting part is not the values statement that most projects paste; it is the enforcement guidelines, which name a graduated response — correction, warning, temporary ban, permanent ban — with the community impact that triggers each. Observable mechanic: the template contains a bracketed blank for a reporting contact, which does not resolve itself. A copied file with that bracket unfilled is a public record that the project adopted values and skipped operations. Transferable method: norms become real at the point where a specific person is prepared to receive a report and act within a stated window. Limit: the document is a template, not a program. It does not train responders, handle evidence, or manage the conflicts of interest that appear when the reported person is an employee of the project’s largest sponsor.

Research note: all three read as primary sources at the dates given. The Kubernetes and Contributor Covenant readings are observation of documents that continue to change; the combined editorial rule below is inference.

The rule the three produce together: define the stages, write each role as responsibilities and privileges and decision boundaries, and make the norms operational by naming who responds, how, and by when.

The participation ladder is a climbing wall

A funnel has one direction, one width, and a bottom. Participation has routes.

Seven stages, all optional, in no fixed sequence:

1. Observe — read, watch, attend, or use.
2. Ask — surface a question, a need, or a failure.
3. Answer — help a peer from experience.
4. Contribute — improve a guide, an issue, a translation, a sample, an event, a process.
5. Co-create — shape a proposal, a roadmap area, a curriculum, a program.
6. Lead — coordinate people, make bounded decisions, mentor others.
7. Steward — maintain standards, governance, continuity, succession.

For each stage a program uses, write down eight things. The entry signal — what action or evidence opens the stage, stated so a person can self-assess rather than wait to be noticed. The meaningful action available at that stage, which must be work someone actually needs done. The support supplied: documentation, a mentor, a named contact, staff time, tooling, budget. The decision rights, in the language of recommend, approve, veto, or own. The recognition or compensation. The safety and conduct expectations, including what the person may expect from you. The next option, if they want one. And the pause-or-exit path.

That last one gets skipped most often and costs the most. Volunteer capacity changes — a new job, a newborn, an illness, a war, a semester. A program without a designed way to step back gets its step-backs anyway, in the form of silence, unanswered pings, and a maintainer who feels too guilty to say they are done. Write the exit as a normal transition with a name, a handover checklist for anything they hold, and a retained standing: former organizers keep their listing, marked inactive, and can return without re-qualifying for some stated period. A community that makes leaving graceful gets people back.

Two failure modes recur. The first is a ladder where stages 5 through 7 exist on the diagram and are held entirely by staff, so the top of the wall is a picture. The second is upward pressure — recognition, invitations, and warmth all concentrated on people who are advancing, which teaches long-term answerers that their standing is a function of ambition. If your program’s monthly highlight has never featured someone who has cheerfully sat at answer for four years, that is the smell.

Rights before responsibilities

Open your role descriptions and count the sentences. If nearly all of them describe what the person will do and one describes what they get, you have written a job requisition without the job.

Every responsibility should have a matching right, written in the same document, at the same level of specificity. Access to information and to the owners of decisions that affect the role. A stated review and response expectation — the number of working days within which their issue, pull request, or question gets a human answer, and what to do when it does not. Attribution and credit by name, in the places where the work appears. Authority inside a defined scope, in the recommend / approve / veto / own vocabulary, so that “you own the workshop content” means something enforceable. Budget, tooling, or reimbursement where the role costs money, along with the actual process and turnaround, because an unfunded expectation of expenses is an income test on leadership. Safety and escalation with a named responder. The ability to decline a promotional request without consequence, stated explicitly, because it is not believed unless it is written. And a transparent route to expanded responsibility, with criteria rather than vibes.

The response-expectation right is the one that quietly determines whether the rest are real. In the cold open, the ambassador filed four errors in a deck she had been asked to present. The program did not deny her the right to improve the material; it simply had no commitment about review, so her contribution decayed into an unanswered issue and she read that, correctly, as an answer.

A useful test before you publish a role: for each right, name the person or team who would be out of compliance if it were not delivered. If a right has no such name, it is a preference.

Community safety is an operating system

A code of conduct is a document. Safety is an operating capability, and the gap between the two is where harm actually happens. A program that has adopted a policy and prepared nothing has moved its liability, not its risk.

Nine things have to be specified before the first incident, because during an incident you will not invent them well. Scope: which spaces, events, repositories, and channels the norms cover, and what happens at a conference the company sponsors but does not run. Reporting routes that are confidential and plural, since a single address fails when the report concerns the person who reads it. Responders who are trained and appropriately separated — at minimum, a route that does not pass through the reported person’s manager, sponsor, or friend. Response expectations: acknowledgement within a stated window and a described process, which is the part reporters most often say they never got. Evidence handling: what is collected, where it lives, who can see it, how long it is kept. Enforcement options, graduated the way the Contributor Covenant’s guidelines are, so that a first-time rudeness and a pattern of targeted harassment do not draw the same response. Privacy limits, stated honestly: what you can keep confidential, and what you cannot, because employment, legal, or platform obligations may force disclosure. Appeal or review where the enforcement is severe and the process was fast. And periodic readiness checks — a tabletop exercise once or twice a year, plus a live test that the reporting address still reaches a trained human, which is the check that most often fails.

Keep the tracks separate and say so. Community moderation, employment action, legal obligation, and public communication have different owners, different evidence standards, and different confidentiality rules. Collapsing them produces the two worst outcomes at once: reporters told that nothing happened when something did, and accused people denied any coherent process.

Do not promise safety. You cannot deliver it, and the promise becomes the second injury when it fails. Promise clear norms, prepared responders, a stated process, fair handling, and improvement after each case — and then be able to show the last readiness check.

Recognition without extraction

Recognition goes wrong in a specific way: it rewards the work that is visible to the company rather than the work that holds the community together. Leaderboards count posts, referrals, and appearances. They do not count the person who answered a beginner’s question kindly at 23:00, the translator who keeps the getting-started guide current in Portuguese, the moderator who de-escalated a thread before it became an incident, or the maintainer who spent a week on a release nobody noticed because it went fine.

Match recognition to the contributor’s own goals, which means asking. Authorship and named credit. Maintainership or a review role. Speaking support — slot, travel, coaching, an abstract read before submission. Mentorship in either direction. Access to engineers, to roadmap discussions, to early builds. A written recommendation or a reference that helps in a hiring process. Portfolio evidence a person can show an employer. Money, where the work is work: honoraria, contracts, stipends, or a funded maintainer seat. Travel and childcare support, which decides who can attend at all. Decision authority, which is the recognition most senior contributors actually want and the one most rarely offered.

Two things to stop doing. Stop ranking humans by volume, because volume rewards availability, and availability is a proxy for time zone, employment status, and freedom from caregiving. And stop building programs that require always-on presence — a streak, a weekly quota, a response-time expectation for volunteers — because those select for the people who will burn out and quietly exclude everyone else.

The line between community contribution and unpaid promotion is testable. If the work primarily serves the company’s distribution and the person receives standing, access, or authority in return, that is an exchange, and it should be written as one. If the work primarily serves the company’s distribution and the person receives merchandise, it is labor with a discount code. Where the task is one you would otherwise hire for — moderation shifts, support coverage, event production, sustained content — fund it.

Governance begins earlier than most teams think

The moment community input can affect a shared asset or decision, governance exists. Undocumented governance is still governance; it is just governance by proximity, where the outcome depends on who knows whom and who was in the channel when it came up. That system works passably while everyone agrees and fails precisely when you need it, because the first real disagreement becomes a contest over who had the authority all along.

Five things to write before ambiguity becomes a power contest. Ownership: who owns each shared asset — the repository, the docs site, the event brand, the community account, the trademark — and what that ownership permits. Decision modes: which decisions are made by the owner, by consent, by vote, by a lazy-consensus window with a stated duration, and where the decision gets recorded. Conflicts of interest: what participants declare, and when they recuse — a live question in any community with competing vendors in it. Removal: who may remove someone from a role, on what grounds, with what notice and what appeal. Succession: who takes a role when its holder leaves, which is the question that decides whether your community survives a reorganization or a resignation.

This does not require a foundation, a charter, or a lawyer on day one. It requires a page. A page that says who owns what, how decisions get made and written down, and what happens when someone has to go, is worth more than a governance model imported from a project a hundred times your size. Write it while everyone still agrees, because that is the only time you can write it fairly: nobody yet knows which rule will favor them.

Words that move

Situation. A platform team is forming a working group of external practitioners to test a migration guide before general availability. Objective: recruit people who will do real technical work, while making the exchange explicit enough that nobody discovers the terms later.

The extractive version, which is what most such invitations look like:

Join our champions program and help spread the word about the new migration path!

The reciprocal version:

The migration working group will test the migration guide against real applications, identify unsupported cases, and recommend changes before general availability. Members get a standing channel with the two engineers who own the migration path, attribution by name in the release notes, and authority to approve the readiness checklist within the group’s scope — if the group does not approve it, the checklist does not ship as final. Commitment is six weeks at roughly two hours per week. We will reimburse tooling or cloud costs the testing requires; the process is in the linked page. Declining any promotional request will not affect your membership or your standing for future groups. Contact for anything that feels unsafe or unfair: , who is not in the reporting line of the migration team.

It points at inspectable evidence: the guide under test, the linked reimbursement process, the named engineers and responder. What it deliberately avoids: the words champion, advocate, and community-driven; any implication that promotion is part of the deal; an open-ended commitment; and a scope of authority so vague that the group would discover its own irrelevance in week five.

Situation. A contributor has spent significant effort on a pull request the project will not merge, and the underlying need is legitimate. Objective: decline the implementation without discarding the person or the problem.

Thank you for this, and for the problem it exposes — we had not seen that failure with nested configurations. We are not merging this implementation, because it changes the compatibility contract in resolveConfig(), which we have committed to holding until the 3.0 line. We are accepting the underlying need: I have opened design discussion #4471 with your case as the first example, and credited this pull request there. The decision record is due by 14 August; after it lands I will come back to this thread either with an approach we can accept or with a clear statement that we will not solve it, so this does not sit open indefinitely.

It names the reason as a specific contract rather than a judgment of the work, keeps the contribution attached to the person, and gives a date and an owner. What it avoids: “we appreciate your interest,” a closed issue with no successor, and the passive construction that hides who decided.

Change smells

• The community exists only on channels the company owns and can switch off.
• Members are measured by posts, referrals, or event appearances rather than by shared value created.
• Advancement requires sponsorship that is real but invisible — no published criteria, no way to tell who could sponsor you.
• Governance is unwritten and everyone insists it is fine, because there has not been a disagreement yet.
• The code of conduct has no reporting address, or has one that nobody has tested this year.
• Recognition tracks visibility while maintenance, moderation, translation, and care work stay uncounted.
• The organization asks for loyalty and offers no influence.
• Volunteers absorb support, moderation, or emotional labor the organization should be funding.
• Stages 5 through 7 of the ladder are occupied entirely by employees.
• Nobody has left the program gracefully, ever — people just stop replying.

Field tool: the participation architecture canvas

Fill this in for every role or stage in your program, one row at a time, before you announce it. A blank cell is not a formatting problem; it is the thing a member will hit and interpret.

Two ways to use it. Before launch, fill every row and have someone outside the program read the Rights and Decision scope cells and tell you what they think they would actually be allowed to do; the gap between your intent and their reading is your rewrite list. On an existing program, fill it from the documentation you already published — not from what you meant — and treat every cell you cannot source as an undocumented expectation you are currently enforcing anyway.

Measure it

Five signals tell you whether participation is real. Movement between stages without pressure to advance, which means tracking both the transitions and the number of long-tenured people happily stable at one stage — a program where everyone either climbs or vanishes is coercive. Repeat contribution and peer-help rates, since a first contribution measures your on-ramp and a second measures the experience you gave the first one. Review latency and contributor wait time, distribution rather than mean, because the tail is where people give up; this is the number that most directly reflects whether the response-expectation right is honored. The distribution of ownership, speaking slots, credit, and decision rights — if a small set of names holds most of each, you have a hierarchy with a community’s vocabulary. And safety-process readiness: date of the last tabletop exercise, date of the last live test of the reporting route, acknowledgement latency on real reports, and whether reporters said the process was fair.

Countermetric: total member count. A roster of twelve thousand can coexist with four people who can actually change anything, and the large number is what gets reported upward while the small number is what determines whether the community survives its founder leaving.

Next

Participation gives people voice and something to lose. Both of those are assets right up to the day you have to impose a cost on them — retire the path they built on, change the pricing, break the API, reverse a decision they argued for in public. That day arrives in every project that lasts. The next chapter is about how to communicate that kind of change without spending the trust that took four chapters to build.