|
| 1 | +# Contributing to Ralph Loops |
| 2 | + |
| 3 | +Thanks for helping shape Ralph Loops. This repository is the canonical source |
| 4 | +for the Ralph Loops format: its specification, examples, conformance tests, |
| 5 | +and governance. |
| 6 | + |
| 7 | +## What lives here |
| 8 | + |
| 9 | +- **`specification/`** — the normative format spec |
| 10 | +- **`loop-creation/`** — creator-facing docs |
| 11 | +- **`implementors/`** — runtime-author docs |
| 12 | +- **`examples/`** — reference loop packages |
| 13 | +- **`schemas/`** — JSON Schema for frontmatter metadata |
| 14 | +- **`tests/`** — valid/invalid conformance fixtures |
| 15 | +- **`rfcs/`** — RFCs for non-trivial changes |
| 16 | + |
| 17 | +Code for specific runtimes (e.g. Ralphify) does **not** live here. |
| 18 | + |
| 19 | +## Kinds of contributions we welcome |
| 20 | + |
| 21 | +- Typo, clarity, and wording fixes in the spec and docs |
| 22 | +- New conformance fixtures under `tests/valid/` and `tests/invalid/` |
| 23 | +- New example loops under `examples/` |
| 24 | +- RFCs proposing additions or changes to the format |
| 25 | +- Translations and accessibility improvements to docs |
| 26 | + |
| 27 | +## Discussion first, PR second |
| 28 | + |
| 29 | +For anything beyond a typo or a small clarification, please open an issue or |
| 30 | +a discussion first. This is especially true for spec changes. We prefer |
| 31 | +small, well-scoped PRs over large, speculative ones. |
| 32 | + |
| 33 | +## Spec changes require an RFC |
| 34 | + |
| 35 | +Any change that affects what a Ralph Loop *is* — required fields, path |
| 36 | +resolution rules, compatibility classes, runtime contract, etc. — must go |
| 37 | +through the RFC process under `rfcs/`. Use `rfcs/0001-format-principles.md` |
| 38 | +as a template. |
| 39 | + |
| 40 | +Additive, backwards-compatible clarifications to existing fields may be |
| 41 | +landed directly as a PR against `specification/`. |
| 42 | + |
| 43 | +## Adding an example loop |
| 44 | + |
| 45 | +Each example under `examples/` must include: |
| 46 | + |
| 47 | +1. A `RALPH.md` with complete, valid frontmatter |
| 48 | +2. A short `README.md` explaining what the loop is for |
| 49 | +3. At least one bundled supporting file (script, doc, template, or fixture) |
| 50 | +4. Realistic exit conditions and validation steps |
| 51 | + |
| 52 | +Prefer outcome-oriented names (`fix-failing-tests`, not `my-loop-1`). |
| 53 | + |
| 54 | +## Adding conformance fixtures |
| 55 | + |
| 56 | +- Valid fixtures go under `tests/valid/<name>/`. |
| 57 | +- Invalid fixtures go under `tests/invalid/<name>/` with a short |
| 58 | + `REASON.md` file explaining why the fixture is invalid. |
| 59 | + |
| 60 | +## Style |
| 61 | + |
| 62 | +- Prose: plain English, short sentences, no hype language. |
| 63 | +- Normative keywords (MUST, SHOULD, MAY) follow RFC 2119 semantics. |
| 64 | +- Code fences should declare a language where applicable. |
| 65 | + |
| 66 | +## Code of conduct |
| 67 | + |
| 68 | +Participation in this project is governed by our |
| 69 | +[Code of Conduct](CODE_OF_CONDUCT.md). |
0 commit comments