|
1 | 1 | # OpenClaw RFCs |
2 | 2 |
|
3 | | -More details coming soon |
| 3 | +This repository stores design proposals and longer-form technical decisions for |
| 4 | +OpenClaw. |
| 5 | + |
| 6 | +## Structure |
| 7 | + |
| 8 | +RFC documents live under the `rfcs/` subdirectory at the repository root: |
| 9 | + |
| 10 | +```text |
| 11 | +. |
| 12 | +├── LICENSE |
| 13 | +├── README.md |
| 14 | +└── rfcs/ |
| 15 | + ├── 0000-template.md |
| 16 | + ├── <id>-<short-name>.md |
| 17 | + └── <id>/ |
| 18 | +``` |
| 19 | + |
| 20 | +New RFCs should use the template and follow the structure below when diagrams or |
| 21 | +supporting assets are needed: |
| 22 | + |
| 23 | +```text |
| 24 | +. |
| 25 | +├── LICENSE |
| 26 | +├── README.md |
| 27 | +└── rfcs/ |
| 28 | + ├── 0000-template.md |
| 29 | + ├── <id>-<short-name>.md |
| 30 | + └── <id>/ |
| 31 | + ├── architecture-overview.png |
| 32 | + └── other-assets... |
| 33 | +``` |
| 34 | + |
| 35 | +The Markdown file is the RFC. The sibling `<id>/` directory inside `rfcs/` is |
| 36 | +optional and is used only for assets referenced by that RFC. |
| 37 | + |
| 38 | +## Naming |
| 39 | + |
| 40 | +- `rfcs/0000-template.md` is the starter template for new RFCs. |
| 41 | +- New RFCs should be named `<id>-<short-name>.md`. |
| 42 | +- When an RFC has supporting assets, store them under a sibling folder inside |
| 43 | + `rfcs/` named exactly `<id>/`. |
| 44 | + |
| 45 | +Example: |
| 46 | + |
| 47 | +```text |
| 48 | +. |
| 49 | +└── rfcs/ |
| 50 | + ├── 0123-policy-runtime-hardening.md |
| 51 | + └── 0123/ |
| 52 | + └── architecture-overview.png |
| 53 | +``` |
| 54 | + |
| 55 | +## Asset References |
| 56 | + |
| 57 | +Reference assets with repo-relative paths from the RFC file: |
| 58 | + |
| 59 | +```md |
| 60 | + |
| 61 | +``` |
| 62 | + |
| 63 | +This keeps the RFC portable and lets GitHub render the document and images |
| 64 | +together. |
| 65 | + |
| 66 | +## RFC Template Shape |
| 67 | + |
| 68 | +New RFCs should start from [`rfcs/0000-template.md`](./rfcs/0000-template.md). |
| 69 | +The template keeps a compact RFC shape while borrowing the core proposal habits |
| 70 | +from Go and Rust: short summary, explicit motivation, concrete proposal text, |
| 71 | +rationale for the chosen approach, and clear unresolved questions. |
| 72 | + |
| 73 | +RFC metadata should live in YAML frontmatter at the top of each RFC. The |
| 74 | +template currently uses these metadata keys: |
| 75 | + |
| 76 | +- `title` |
| 77 | +- `authors` |
| 78 | +- `created` |
| 79 | +- `last_updated` |
| 80 | +- `rfc_pr` |
| 81 | + |
| 82 | +The expected top-level sections are: |
| 83 | + |
| 84 | +- `Summary` |
| 85 | +- `Goals` |
| 86 | +- `Non-Goals` |
| 87 | +- `Motivation` |
| 88 | +- `Proposal` |
| 89 | +- `Rationale` |
| 90 | +- `Unresolved questions` |
| 91 | + |
| 92 | +## Authoring Notes |
| 93 | + |
| 94 | +- Keep one RFC per Markdown file. |
| 95 | +- Use the sidecar asset folder only when the RFC needs diagrams, screenshots, or |
| 96 | + other supporting files. |
| 97 | +- Prefer stable filenames for images so review comments and links do not churn. |
| 98 | +- Keep assets specific to one RFC in that RFC's own `<id>/` directory rather |
| 99 | + than creating a shared global asset folder. |
| 100 | +- Keep `Summary` to one paragraph. |
| 101 | +- Use `Goals` to define what success looks like for the proposal. |
| 102 | +- Use `Non-Goals` to define what is intentionally out of scope. |
| 103 | +- Use `Motivation` to explain why the change is necessary. |
| 104 | +- Use `Proposal` to describe what is changing. |
| 105 | +- Use `Rationale` to compare alternatives and explain the tradeoffs in the |
| 106 | + chosen design. |
| 107 | +- Use `Unresolved questions` to call out relevant gaps or follow-up areas that |
| 108 | + are intentionally not addressed by the proposal. |
0 commit comments