# Requests for comments

A structured way to propose changes, compare alternatives, and preserve the reasoning behind OpenForex decisions.

## Publication status
Published by the OpenForex Society, the standard-setting core of the OpenForex Foundation, as part of its established standards service to the open standards community.

## Version
0.2.0

## Last Updated
2026-09-24

## When to write an RFC
Use an RFC when a proposal changes a standard's behavior, adds a compatibility requirement, changes governance authority, or introduces a consequential data or monetary policy. A spelling correction or link repair normally needs a focused patch instead.

No numbered RFC register or ratified RFC decision is included in this package. Do not invent an accepted RFC identifier to give a proposal authority.

## Proposal structure
| Section | What reviewers need |
| --- | --- |
| Title and author | A specific problem and accountable proposer |
| Status and revision | Draft state and exact version under review |
| Motivation | Who encounters the problem and under which conditions |
| Proposed behavior | Concrete before-and-after behavior |
| Alternatives | Plausible options and reasons for the selection |
| Compatibility | Affected documents, implementations, and migration requirements |
| Evidence | Derivations, fixtures, experiments, or source references |
| Risks and unresolved questions | Known limitations and decisions still needed |
| Decision record | Review outcome and authorized publication reference |

## Review workflow
Start with a draft linked to affected pages. Invite domain review through the official contribution channel when available. Incorporate feedback in a visible revision history. Separate resolved objections from questions still awaiting evidence.

A proposal can remain a draft, enter structured review, be revised, be withdrawn, or receive a recorded decision under the adopted governance process. An author marking a file Approved is not itself ratification.

## Example of a well-scoped question
A proposal to reject stale oracle snapshots should define observation time, permitted age, configuration scope, and the resulting error. Include a fresh example, a boundary example, and an expired example. Explain how existing consumers migrate.

## After a decision
Link the accepted proposal to the exact specification revision and effective conditions. Retain rejected or withdrawn proposals when they explain design choices, with their status clearly visible.

Use the [page template](?page=seed-content/templates/page-template), [contribution workflow](?page=docs/contribution-workflow), and [governance overview](?page=seed-content/governance/overview).