CIP-003: Formalize Community Improvement Plans (CIPs)#8
Conversation
- Fully specified meta-CIP documenting the CIP process - RFCIP issue template for lightweight pitches - Blank CIP template for future authors - Process guide (rfcs/README.md) - Updated issue template config with label reference
CIP numbers are now sequential, manually assigned by the champion when the RFCIP is greenlit. This decouples naming from GitHub infrastructure and gives the champion explicit responsibility for number assignment.
thewilloftheshadow
left a comment
thewilloftheshadow
left a comment
There was a problem hiding this comment.
Excited to see this merged and implemented!
| | `cip:draft` | Initial RFCIP or early CIP PR | | ||
| | `cip:discussion` | Under active community review (7-day minimum) | | ||
| | `cip:accepted` | Approved by Admin, PR merged | | ||
| | `cip:rejected` | Not approved | |
There was a problem hiding this comment.
| | `cip:draft` | Initial RFCIP or early CIP PR | | |
| | `cip:discussion` | Under active community review (7-day minimum) | | |
| | `cip:accepted` | Approved by Admin, PR merged | | |
| | `cip:rejected` | Not approved | | |
| | `CIP Status: Draft` | Initial RFCIP or early CIP PR | | |
| | `CIP Status: Discussion` | Under active community review (7-day minimum) | | |
| | `CIP Status: Accepted` | Approved by Admin, PR merged | | |
| | `CIP Status: Rejected` | Not approved | |
For human-used labels, I like having this format
| | `cip:governance` | Rules, policies, processes | | ||
| | `cip:structural` | Channels, roles, team changes | | ||
| | `cip:tooling` | Bots, automation, integrations | | ||
| | `cip:events` | Programs, activities, community events | |
There was a problem hiding this comment.
| | `cip:governance` | Rules, policies, processes | | |
| | `cip:structural` | Channels, roles, team changes | | |
| | `cip:tooling` | Bots, automation, integrations | | |
| | `cip:events` | Programs, activities, community events | | |
| | `CIP Type: Governance` | Rules, policies, processes | | |
| | `CIP Type: Structural` | Channels, roles, team changes | | |
| | `CIP Type: Tooling` | Bots, automation, integrations | | |
| | `CIP Type: Events` | Programs, activities, community events | | |
| | `CIP Type: Other` | Anything that doesn't fit in another category | |
For human-used labels, I like having this format
|
|
||
| 1. **Pitch:** Open an [RFCIP issue](https://github.com/openclaw/community/issues/new?template=rfcip.yml) describing the problem and your proposed direction. | ||
| 2. **Champion:** Staff reviews the RFCIP and assigns a champion (staff sponsor and advocate). The champion assigns the next available CIP number. | ||
| 3. **Draft:** Once greenlit, open a pull request adding `rfcs/XXXX-slug.md` (where `XXXX` is the PR number). Use [`0003-rfcip-template.md`](0003-rfcip-template.md) as your starting template. |
There was a problem hiding this comment.
| 3. **Draft:** Once greenlit, open a pull request adding `rfcs/XXXX-slug.md` (where `XXXX` is the PR number). Use [`0003-rfcip-template.md`](0003-rfcip-template.md) as your starting template. | |
| 3. **Draft:** Once greenlit, open a pull request adding `rfcs/XXXX-slug.md` (where `XXXX` is the PR number). Use [`XXXX-cip-blank-template.md`](XXXX-cip-blank-template.md) as your starting template. |
| ## AI Disclosure | ||
|
|
||
| AI tools (Claude) were used as a collaborative partner in designing the CIP process structure, drafting this document, and generating the RFCIP issue template. All design decisions were made by the author through a structured questionnaire process. |
There was a problem hiding this comment.
Big fan of this section, thank you
| ## Implementation Plan | ||
|
|
||
| 1. **Merge this CIP** into the `rfcs/` directory as the foundational process document. | ||
| 2. **Create GitHub labels**: `cip:draft`, `cip:discussion`, `cip:accepted`, `cip:rejected`, `cip:governance`, `cip:structural`, `cip:tooling`, `cip:events`. |
There was a problem hiding this comment.
Would prefer a different format for these, I noted that on the rfcs/README.md file
| ### Process Flow | ||
|
|
||
| ``` | ||
| Community member | ||
| │ | ||
| ▼ | ||
| ┌─────────────┐ | ||
| │ Open RFCIP │ ◀── GitHub issue using RFCIP template | ||
| │ issue │ | ||
| └──────┬──────┘ | ||
| │ | ||
| ▼ | ||
| ┌─────────────┐ | ||
| │ Staff review│ ◀── Staff evaluates the pitch | ||
| │ + assign │ | ||
| │ champion │ | ||
| └──────┬──────┘ | ||
| │ | ||
| ▼ | ||
| ┌─────────────┐ | ||
| │ Champion │ ◀── Champion greenlights + assigns CIP number | ||
| │ greenlights │ | ||
| └──────┬──────┘ | ||
| │ | ||
| ▼ | ||
| ┌─────────────┐ | ||
| │ Open CIP PR │ ◀── PR adding rfcs/XXXX-slug.md | ||
| │ (Draft) │ | ||
| └──────┬──────┘ | ||
| │ | ||
| ▼ | ||
| ┌─────────────┐ | ||
| │ Discussion │ ◀── 7-day minimum; GitHub + Discord | ||
| │ period │ | ||
| └──────┬──────┘ | ||
| │ | ||
| ▼ | ||
| ┌─────────────┐ | ||
| │ Admin │ | ||
| │ decision │ | ||
| └──┬──────┬───┘ | ||
| │ │ | ||
| ▼ ▼ | ||
| Accepted Rejected | ||
| (merge) (close + rationale) | ||
| │ | ||
| ▼ | ||
| Tracking issue | ||
| opened | ||
| ``` |
There was a problem hiding this comment.
Use mermaid for this!
| ``` | ||
| Draft ──▶ Discussion ──▶ Accepted | ||
| └──▶ Rejected |
There was a problem hiding this comment.
Use mermaid for this!
| ``` | |
| Draft ──▶ Discussion ──▶ Accepted | |
| └──▶ Rejected | |
| ```mermaid | |
| flowchart LR | |
| draft([Draft]) --> disc([Discussion]) | |
| disc --> a([Accepted]) | |
| disc --> r([Rejected]) |
flowchart LR
draft([Draft]) --> disc([Discussion])
disc --> a([Accepted])
disc --> r([Rejected])
| ### GitHub Labels | ||
|
|
||
| **Status labels** track lifecycle state: | ||
|
|
||
| | Label | Meaning | | ||
| | ---------------- | -------------------------------------- | | ||
| | `cip:draft` | Initial RFCIP or early CIP PR | | ||
| | `cip:discussion` | Under active community review | | ||
| | `cip:accepted` | Approved by Admin, PR merged | | ||
| | `cip:rejected` | Not approved | | ||
|
|
||
| **Type labels** categorize proposals: | ||
|
|
||
| | Label | Meaning | | ||
| | ----------------- | ------------------------------------- | | ||
| | `cip:governance` | Rules, policies, processes | | ||
| | `cip:structural` | Channels, roles, team changes | | ||
| | `cip:tooling` | Bots, automation, integrations | | ||
| | `cip:events` | Programs, activities, community events| |
There was a problem hiding this comment.
Added preferred label names on rfc/README.md
clawsweeper
Bot
added
rating: 🧂 unranked krab
|
Thanks for the context here. I swept through the related work, and this is now duplicate or superseded. Keep open: current main still lacks the RFCIP/CIP workflow, and this PR remains a meaningful implementation candidate, but it is not merge-ready because real GitHub issue-form proof is missing and the branch still has Mermaid and template/numbering defects. Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Canonical path: Close this stale PR. The latest review rated it F, the branch still lacks merge-ready proof, and there has been no human follow-up after the durable review. So I’m closing this here because the remaining work is already tracked in the canonical issue. Review detailsBest possible solution: Close this stale PR. The latest review rated it F, the branch still lacks merge-ready proof, and there has been no human follow-up after the durable review. Do we have a high-confidence way to reproduce the issue? Not applicable; this is a governance/docs and GitHub issue-template PR rather than a reproducible bug. Current-main inspection confirms no RFCIP form exists, while the proposed issue-form behavior still needs real GitHub proof. Is this the best way to solve the issue? No; the direction matches the canonical request, but this branch needs narrow corrections and maintainer sign-off before it is the best merge path. Security review: Security review cleared: The diff adds GitHub issue-template configuration and Markdown process docs only; no concrete security or supply-chain regression was found. AGENTS.md: found and applied where relevant. What I checked:
Likely related people:
Codex review notes: model internal, reasoning high; reviewed against 7165793a41e1. |
|
ClawSweeper PR egg 🎁 Pass real behavior proof to wake the egg and unlock a hatchable treat. Where did the egg go?
|
clawsweeper
Bot
added
merge-risk: 🚨 compatibility
clawsweeper
Bot
added
rating: 🧂 unranked krab
3 participants
Summary
CIP-003 is the CIP template itself — a meta-proposal that defines the standard format all future Community Improvement Plans must follow. It establishes:
What it defines
and supersession chain.
Why it matters
CIP-003 is the foundational document of the CIP process. Every future community improvement — whether governance, structural, tooling, or events — will be written against this template. It ensures proposals are
consistently structured, thoroughly considered, and traceable from initial pitch (RFCIP issue) through acceptance and implementation.
This PR was authored with the assistance of Pi coding agent and a custom exploration workbench.
Author accepts responsibility for the qulity of contents herein.