Request for Comments (RFC) Process
RFCs are used for proposing and discussing significant changes to DuraGraph. They provide a structured way to capture design decisions, alternatives, and risks.
When to Write an RFC
Section titled “When to Write an RFC”You should write an RFC when proposing:
- Changes to the domain model or event schemas.
- Additions or modifications to API endpoints.
- Major system architecture changes (e.g., graph engine, event streaming).
- New integrations with external systems (LLM providers, storage, model APIs).
RFC Template
Section titled “RFC Template”Each RFC should include:
-
Title / Identifier Example:
RFC-0001: Streaming tokens via SSE -
Problem Statement Describe the problem and why it needs to be solved.
-
Proposal Outline the proposed solution, including architecture diagrams, sequence diagrams, or schema changes.
-
API / IR Changes Document API contracts, schema updates, and compatibility considerations.
-
Migration / Rollout Plan How the change can be adopted incrementally, and fallback/rollback options.
-
Risks & Open Questions Highlight potential risks and unanswered questions.
Workflow
Section titled “Workflow”- Draft RFC in a branch under
docs/rfcs/. - Open a Pull Request with label
rfc. - Discussion phase: request feedback from maintainers and community.
- Once consensus is reached, merge RFC into main branch.
- Link RFCs from
docs/project/rfcs.md.