Changes for content/handbook/engineering/workflow/reviewer-values.md: 10 added lines, 0 removed lines.
Original line number
Diff line number
Diff line
@@ -170,6 +170,16 @@ approach and not because it's a personal preference to you.
**Pro-tip:** When in doubt, ask another reviewer for a sanity check.
### Maintainer is a role, not a rank
Becoming a maintainer is a real milestone, but the title isn't a trophy you earn once and keep. It's a role you actively hold: reviewing thoroughly, mentoring reviewers, guarding consistency, and staying reliably available to unblock others. It also carries a responsibility to the whole engineering organization, not only to your immediate team's area.
Because it's a role and not a rank, our capacity to fill it changes over time. Priorities shift, people change teams, take on new scope, or simply need room. Stepping back from maintainership when you can't currently meet its responsibilities is a normal, healthy act: good stewardship, not a demotion. We should be able to say *"I can't give this the attention it deserves right now"* and be met with thanks. The [process for stepping back and returning](/handbook/engineering/workflow/code-review/#transitioning-away-from-being-a-reviewermaintainer) is deliberately lightweight, and your experience always counts when you come back.
This is overwhelmingly about self-awareness and self-release. In keeping with our value of [honesty](#honesty), it also means we should be able to have direct, caring conversations with each other when the role isn't being fulfilled, the same fearless collaboration we ask for in reviews. Formally removing someone should be rare, if it ever happens at all. The goal is a culture where people feel safe stepping back on their own, not one where the title can be taken away for a slow month.
> *A role is defined by what we do with it, not by having once been given it.*
### Worst case analysis
In the situation where you find there are unknowns in the merge request you are reviewing,
