Steward
Sign in

Documentation › Contributor guides

Reputation as a contributor

This doc is the author's view of the reputation system — specifically, what your reputation means, how to grow it, and what it unlocks. The maintainer-POV concept doc at Contributor reputation covers the same system from the gate-configuration side and is the deeper mechanical reference; this guide is what you need to know as the person whose name shows up in the score.

What your reputation is

For each repo you've contributed to, Steward keeps a per-domain reputation score for you. Not one number — a vector:

alice: { api: 12.4, ui: 0.8, docs: 6.1, rest: 2.0 }

A domain is a named slice of the codebase declared in the repo's .steward/governance.pxf (covered at governance.pxf + domains). Your reputation in each domain is independent.

The number is real-valued and starts at zero for a new contributor. Reputation comes from merged PRs; it accumulates over time; it decays when you stop contributing.

Why it matters to you

Three concrete effects, listed by how often they hit:

1. Self-merge eligibility

The most common impact. Each domain has an approval_threshold (configured by the maintainer). If your reputation in the touched domain is at or above the threshold, you can self-merge without an explicit reviewer approval. Below it, you need a review from someone above the threshold.

So: high reputation = fewer review hoops for changes in your strong domains. This is the carrot.

2. Cross-domain consensus

When a PR spans multiple domains, the maintainer can require a reputation-weighted supermajority across all touched domains before merge (the supermajority_ratio config). Authors with deep reputation in one domain carry more weight when approving PRs touching that domain.

This rarely affects you as an author; it affects you as a reviewer when others ask you to weigh in on cross-domain PRs.

3. Slashing — when reputation goes down

If you merge a PR and that PR is later linked to a critical bug, Steward can apply a retroactive penalty (the slashing config). Your reputation in the touched domain drops by an amount that grows over time — "the longer the bug was latent, the more it hurt."

Slashing is opt-in per repo and disabled by default; many maintainers don't enable it because calibrating "what's a critical bug" is hard. But it's there. Aim for working code, not just merged code.

How you earn it

Every merged PR appends a PR_MERGED event to the ledger. The earn formula is:

points = base × (1 + ln(complexity)) × criticality
Variable Source
base The repo's decay.base_points setting — typically 1.0.
complexity The cyclomatic complexity delta of your merge. Trivial PRs floor to complexity = 1 so the natural log doesn't go negative.
criticality The touched domain's criticality_multiplier. Security or core domains weigh more than auxiliary ones.

So a small fix in docs earns less than a substantive change in auth. This is intentional — substantial work in high-stakes areas earns more recognition than typo fixes in low-stakes areas.

Practical implications

  • Small PRs accumulate. Ten small PRs build more rep than one giant PR — the natural log on complexity dampens the benefit of large diffs. A PR that touches 50 lines and one that touches 500 lines aren't 10× different in reputation gain; they're ~2× different (because of the log).
  • Domain choice matters. If you can pick which domain to contribute to, picking one with a higher criticality_multiplier rewards you more per PR. But only do that if your work is genuinely valuable there — getting caught making low-quality PRs to high-criticality areas earns rep slower (lower test ratio scores, more reviewer pushback) and risks slashing if a bug surfaces.
  • Trivial PRs still count. A typo fix earns the floor base × 1 × criticality. Small contributions matter; the system doesn't penalise low-effort merges, it just doesn't reward them disproportionately.

How it decays

Reputation halves over decay.half_life of inactivity:

R(t) = R₀ × e^(-λt)   where λ = ln(2) / half_life_in_days

A typical setting is half_life: "180d" — your reputation halves every six months without new contributions.

Decay is per-domain, per-pair. If you contribute to api weekly but haven't touched docs in a year, your api reputation stays steady while your docs reputation has halved twice.

Leave windows pause decay

If you mark yourself as on leave (via /app/account → Set leave window), decay pauses for that period. The specific window is [from, leave_until]. So a parental leave, sabbatical, or extended PTO doesn't punish you — when you return, your reputation is where you left it.

Set this from your account page when you're going dark for more than a month or two. It's a few clicks; it's free; it's the right move.

Why decay exists

Reputation is meant to track "could this person responsibly self-merge a change in this area right now?" If your last api PR was three years ago, you're probably not the right person to merge something there without review — the codebase has moved on, your context has aged out. Decay encodes that.

Cross-repo accumulation

This is the most counter-intuitive property: reputation in a domain accumulates across every repo that has a domain with the same name.

So your core reputation is the sum of your core contributions to every Steward-governed repo that declares a core domain. A senior Go engineer's core reputation doesn't restart at zero when they open their first PR on a new repo — their established authority carries over.

The flip side: domain names are coordination points. If two unrelated projects both name a domain core, your reputation in one affects your eligibility in the other.

The implication: when you join a new project, ask the maintainer what their domain names are. If they happen to match domains you already have reputation in, you start with real authority instead of zero.

How to check your own reputation

From a PR comment

Drop this on any PR in a Steward-installed repo:

/steward check-reputation

Within seconds, Steward posts a markdown table showing your reputation in every domain of that repo (decayed to now):

Reputation vector for @alice (decayed to now)

| Domain | Decayed reputation |
| :----- | -----------------: |
| api    |              12.40 |
| docs   |               6.10 |
| ui     |               0.80 |

The numbers are domain-specific to that repo's governance.pxf, but the underlying scores cross-accumulate as described above.

From the dashboard

The full view lives at:

/app/contributors/<your-github-login>

It shows your reputation across every domain across every repo where Steward has seen activity from you, plus the recent ledger events that produced your current numbers. So you can answer "why is my api rep 8.3, not 10?" by reading the actual event chain (a merge, two decay checkpoints, a slashing event from that bug last year, etc).

Building reputation efficiently

A few practical patterns that work:

  • Pick one repo and contribute regularly. Steady weekly contribution outpaces sporadic large bursts under exponential decay. A new contributor making one merged PR per week for three months has more reputation than a contributor who made twelve PRs in a weekend and then disappeared.
  • Read governance.pxf early. Knowing the domain structure tells you where reputation accumulates faster (high criticality_multiplier domains). And matching your contribution to where authority is actually scarce in the project (small domains with few high-rep contributors) builds rep faster than where authority is abundant.
  • Use the sandbox-issue intake. Many repos seed new contributors via /steward sandbox-me — see Sandbox issues. It's the fastest path from "no reputation" to "your first ungated merge."
  • Don't merge code you're not confident in. Slashing is the asymmetric risk: a PR that earns you 4 reputation points can lose you 6+ if it later breaks. The math rewards careful, not just prolific.

What happens when you stop contributing

A few questions worth answering up front:

Will I be removed?

No. Steward doesn't delete contributor records or revoke reputation just because you went quiet. Decay reduces your effective reputation over time, but the ledger stays.

Will my history disappear?

No. Your PR_MERGED events stay in the audit-grade ledger forever. They're how the reputation math reconstructs your current score on lookup, and they're what an auditor sees during a Service Organization Control 2 (SOC2) review.

What if I want all my data gone?

You can delete your Steward account via /app/account → Delete my account. The flow is documented at Your account + your data.

Account deletion tombstones your identity-bearing columns (login, email, avatar) but preserves the underlying ledger events with a sentinel-login placeholder. The events stay because they're load-bearing for the reputation math; the identity-side data is the part that's actually private and that gets scrubbed.

If you object to the events themselves persisting, contact the maintainer of the repo(s) you contributed to — they own their repo's data, including your historical contributions.

What's next