A major change can become hard to challenge once somebody has spent weeks implementing it. A request-for-comments process moves the discussion earlier. The proposer explains the problem, proposed approach, alternatives, and expected drawbacks in a document that others can examine and amend.
In the Rust project's RFC process, submitting a proposal begins consideration rather than granting permission to implement it. The familiar initials also appear in Internet standards publishing, but not every organizational RFC is an Internet standards document.
Write before the commitment
A community archive could use an RFC before changing how contributors label and license photographs. Volunteers unable to attend one meeting would have time to read the consequences, identify missing cases, and suggest a less disruptive alternative.
The document creates a shared object of discussion, reducing repeated explanations and preserving reasoning. But writing skill becomes an entry cost. Long proposals can privilege people with more time, and an endless comment period can leave nobody responsible for reaching a decision.
A complete process therefore identifies who decides, how feedback will be handled, and what acceptance means. It also reserves the effort for changes large enough to justify it. Requiring an RFC for every minor correction would turn a tool for consequential deliberation into a barrier to ordinary contribution.