Skip to content

Contributor Ceremony

"Ceremony" is a term from agile practice for the rituals that coordinate a team. OSS contributors need rituals too, especially when contributors are asynchronous and globally distributed. This page describes the ceremonies FCC uses (onboarding, review, release) and how to adapt them.

The three main ceremonies

  1. Onboarding ceremony — what happens from a contributor's first issue to their first merged PR.
  2. Review ceremony — what happens from PR-opened to PR-merged.
  3. Release ceremony — what happens from code-freeze to tag to announce.

Each is short, explicit, and repeatable.

Onboarding ceremony

FCC's onboarding is built around three touchpoints:

  • First issue. An onboarding issue gets a standard welcome comment linking to CONTRIBUTING.md, the relevant ADR(s), and a "good-first-issue" list.
  • First PR. A standard PR template with a checklist: tests, docs, changelog entry, persona adoption checklist satisfied (for FCC specifically; for you, whatever replaces it).
  • First merge. The contributor is added to CONTRIBUTORS.md and tagged in the next release notes.

Total elapsed maintainer time: under 30 minutes across those three touchpoints.

Adaptation:

  • Standard welcome comment — stored as an issue template.
  • Standard PR template.
  • An explicit "first-timer" label to route automatically.

Review ceremony

Three rules FCC enforces via convention:

  1. One reviewer is required; two for changes in governance, schema, or release tooling.
  2. Reviews happen in the PR, not in private chat. If a conversation moves to DMs, it is summarized back in the PR.
  3. "Approve with suggestions" means approve; blocking changes require a Requested Changes verdict.

Together these produce a measurable improvement in review throughput without sacrificing rigor.

The R.I.S.C.E.A.R.-adapted role specs (see Adopting R.I.S.C.E.A.R.) should include a pr-reviewer role with its own constraints (e.g., "never approve your own changes," "always cite a specific behavior that changed").

Release ceremony

FCC's release cadence is roughly monthly for minors and weekly-during-patch-clusters for patches. Each release follows the same script:

  1. Code freeze — announced in a pinned issue.
  2. Release-candidate tag — v1.7.0-rc.1.
  3. Regression pass — maintainers run the full test suite; designated reviewer runs the CI on a fresh clone.
  4. Final tag — v1.7.0.
  5. Release notes updated in RELEASE_NOTES.md.
  6. Announce — GitHub release, mailing list, social.

For smaller OSS projects the ceremony can compress to three of these steps: freeze-test-announce. The discipline is not the length; it is the consistency.

The release "plan" pattern

FCC plans releases explicitly as numbered stages. For v1.5.0, for instance, the plan specified five stages: each shipped as an interim minor (v1.4.1, v1.4.2, ..., v1.4.4) before the culminating v1.5.0. The pattern helps because:

  • Each stage is testable in isolation.
  • Slipping one stage does not delay the next.
  • Stakeholders can see progress at monthly granularity.

Adaptation: take your next minor release, break it into 3-5 sub-stages, ship each as a patch, and converge on the minor. The first time this pattern is uncomfortable; the second time it is faster than not-doing-it.

Small-team variations

Solo maintainer:

  • Onboarding ceremony: the welcome-comment issue template + a "good-first-issue" label.
  • Review ceremony: every PR gets a self-review note ("I considered X, Y, Z") in the PR description before merge.
  • Release ceremony: a simple make release target + a pinned release-checklist issue.

Two maintainers:

  • Onboarding: one maintainer owns welcome, the other owns the merge.
  • Review: require one approval, allow it to be the other maintainer.
  • Release: alternate roles each release.

3-10 maintainers:

  • Adopt a rotation schedule; pin it in the README.
  • Introduce lightweight retros every 3 releases.

Retros

FCC runs informal retros during patch clusters (v1.3.5, v1.3.5.1, ..., v1.3.5.4). The retro asks three questions:

  1. What went well?
  2. What surprised us?
  3. What will we do differently next time?

The answers go into the next plan. Retros that produce actionable change are worth doing; retros that produce feelings are not.

Security ceremony

Every OSS project needs a security ceremony. FCC uses:

  • SECURITY.md at the repo root.
  • A designated security-responder role (adapted R.I.S.C.E.A.R.).
  • Embargo protocol: 90 days for most issues, 30 days for severe.
  • CVE coordination with the relevant body when applicable.

Copy SECURITY.md templates from well-known projects (curl, Rust, Python) and adapt.

Communications ceremony

Every release notes entry follows a pattern:

  • Headline (one sentence)
  • Context (why this matters)
  • What's new (bulleted)
  • Breaking changes (none if none; be explicit)
  • Known issues (if any; be explicit)
  • Thanks (named contributors)

The "thanks" line is non-negotiable. It is also how you retain contributors.

What not to ceremonialize

Not everything benefits from ceremony. Avoid:

  • Code style discussions. Use a formatter; move on.
  • "Should we merge this?" polls. Use a clear review process; move on.
  • Acronym debates. Pick one; move on.

Ceremony is cheap up to a point; beyond that it is overhead.

Example calendar for a small project

  • Daily: triage new issues (15 min).
  • Weekly: dependabot/PR sweep (30 min).
  • Biweekly: merge week + release candidate (variable).
  • Monthly: full release + announcement (2-4 hours).
  • Quarterly: role-spec review + CONTRIBUTING.md sweep (half day).

This calendar is sustainable for a small team. FCC's pace is more aggressive; scale up only when you have bandwidth.

Where next

With ceremonies in place, the last piece is release rhythm: see Release Cadence Lessons. For the broader reading list, Further Reading.