git:20260720.41d8423 to git:20260728.fac4544

---

name: community-building

description: Grow product and open-source communities through seeded value, working moderation, and contributor ladders. Use when starting a community or reviving one that went quiet.

---

# Community building

A community exists when members get value from each other, not just

from you. Until that flywheel turns, you are running a support

channel with ambiance; the work is seeding, structuring, and then

deliberately getting out of the way.

## Method

1. **Give the community one clear job.** Peer support,

show-and-tell, contributor coordination, practice

instinct, applied to humans): the job decides the

platform (forum for searchable knowledge that

compounds: see technical-seo's durable-content logic;

chat for velocity and belonging; both means two jobs,

staffed as two). A community without a job is a logo

with a lurker problem.

2. **Seed activity for the cold-start year.** Founders and

team answer everything fast (first-response time is

the early community's heartbeat), post the content

that models the culture (build logs, questions,

honest failures: see developer-marketing's

practitioner voice), and personally invite the first

hundred members one at a time; ghost towns repel:

a small active space beats a large silent one, so

start narrow (one channel, one forum category) and

expand on pressure (see mvp-scoping's narrowing

rule).

3. **Write the code of conduct and enforce it early.**

Clear rules, named moderators, private reporting,

and visible consequence for the first serious

violation: the community's culture is set by the

worst behavior tolerated (see

open-source-review-board adjacency); moderation

capacity scales ahead of growth or the loudest

ten percent become the brand.

4. **Build the ladder from lurker to leader.** Most

members read only (fine: they still get value);

design the small first steps (introductions thread,

easy questions channel, good-first-issue labels:

see open-source-maintainer-role's contributor

funnel), then recognize climbers visibly

(contributor spotlights, early access, maintainer

invitations: see mentoring-engineers' sponsorship:

the same move at community scale). Titles and

badges are cheap; genuine trust and scope are the

real rungs.

5. **Feed the community's work back into the product.**

Answered questions become docs pages (see

docs-maintenance: the community is your

staleness-detector), repeated complaints become

roadmap evidence (see product-discovery,

churn-analysis's leading indicators), member

creations get amplified (their tutorials, plugins,

templates): the visible loop "we heard, we shipped,

credit to X" is what convinces members their

participation matters (see

roadmap-communication's change-loudly rule).

6. **Measure health, not headcount.** Active

participants (weekly posters/answerers), answer

rate and time-to-first-response, returning-member

ratio, and the founder-independence ratio (what

fraction of answers come from non-team members:

the flywheel metric); member count is the vanity

number (see product-metrics' vanity warning).

Review quarterly with the same decide-or-adjust

discipline as any product surface.

## Boundaries

- Communities are slow assets with real carrying

costs (moderation, programming, attention);

starting one you will abandon in six months is

worse than none: the dead community is public

evidence of neglect (see feature-sunsetting if it

comes to that: close honestly).

- The community is not a free labor pool or a

marketing broadcast list; extractive framing

(posting only announcements, harvesting content

without credit) reads instantly and kills

reciprocity (see developer-marketing's trust

economics).

- Platform choice creates lock-in for *members*

(their answered questions, their reputation);

migrations lose a real fraction of the community:

choose durably and early (see

managed-vs-selfhosted's exit-path thinking).