Coordinate and act
The maintainer and the RFC
A named owner, and written proposals for big changes
A named owner for each area's quality, plus a short written proposal for changes big enough to warrant review.
Borrowed from open-source software projects, which name a maintainer for each component, and the Internet Engineering Task Force's "request for comments" process. Read the original source.
Changes a rule or role · Minutes to start · Anyone on the team can start it
Try this first
Name one owner for one area's quality, and set the size of change that gets written down first.
Use it when
Ownership is unclear and big changes surprise people.
Skip it when
It suits work with distinct areas and changes worth reviewing. On small or fast-moving work, maintainers and written proposals cost more than they return.
How to introduce it
Set up two things. Name a maintainer who owns the quality of each area. Then route significant changes through a short written proposal others can comment on before the change lands. Clear ownership, plus a light way to gather input where it matters.
How to show up
Name the maintainers and agree what size of change earns a written proposal. Keep the proposal light. Guard both failure modes: the maintainer as bottleneck, and the proposal step swelling into bureaucracy.
How long it takes
A little setup to name owners and set the threshold. Then it runs lightly.
What makes it hard
Route everything through the maintainer and they jam. Let the proposal step grow and it becomes paperwork. Keep both light. Getting the threshold right takes tuning, so it catches what matters without taxing the trivial.
What it looks like when it's working
Each area has an owner, significant changes get useful input before they land, and the work stays coherent. A swamped maintainer, or proposals for trivial changes, means rebalance it.
How long until it sticks
A few weeks to calibrate which changes warrant a proposal and to keep the process light.
How you know it stuck
Areas have owners and significant changes get a quick written review without anyone policing it.
The idea behind it
Quality needs a name attached, and significant changes need a moment of open review. Together those keep work coherent without heavy process.
Where it comes from
Open-source collaboration. A named owner for each area plus a lightweight written-proposal norm before big changes. A named maintainer owns a component's quality. Significant changes go through a written "request for comments" others can weigh in on.