diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml index d3a5501..9ba992b 100644 --- a/.github/ISSUE_TEMPLATE/config.yml +++ b/.github/ISSUE_TEMPLATE/config.yml @@ -1,4 +1,7 @@ blank_issues_enabled: false +# CIP labels: cip:draft, cip:discussion, cip:accepted, cip:rejected +# cip:governance, cip:structural, cip:tooling, cip:events +# cip:community contact_links: - name: Appeals url: https://appeal.gg/clawd diff --git a/.github/ISSUE_TEMPLATE/rfcip.yml b/.github/ISSUE_TEMPLATE/rfcip.yml new file mode 100644 index 0000000..5e3ba65 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/rfcip.yml @@ -0,0 +1,109 @@ +name: Suggest a Community Improvement Plan (RFCIP) +description: Pitch an idea for a Community Improvement Plan (CIP) +title: "RFCIP: " +labels: + - cip:draft +body: + - type: markdown + attributes: + value: | + ## Request for Community Improvement Plan + + Use this form to pitch an idea before writing a full CIP. + A staff champion must be assigned before a CIP pull request can be opened. + + **What happens next:** + 1. Staff reviews your request. + 2. A champion (staff sponsor) is assigned. + 3. Champion greenlights you to open a CIP pull request. + + See `rfcs/0003-rfcip-template.md` for the full CIP document template. + + - type: textarea + id: problem + attributes: + label: Problem statement + description: What problem, gap, or opportunity does this address? Be specific. + placeholder: "Currently, there is no way to..." + validations: + required: true + + - type: textarea + id: proposed-direction + attributes: + label: Proposed direction + description: High-level sketch of your proposed solution. This doesn't need to be detailed — that's what the full CIP is for. + placeholder: "I propose we..." + validations: + required: true + + - type: textarea + id: scope-impact + attributes: + label: Scope and impact + description: What parts of the community does this affect? Which teams, channels, roles, tools, or processes? + placeholder: "This would affect..." + validations: + required: true + + - type: dropdown + id: cip-type + attributes: + label: CIP type + description: What category best describes this proposal? + options: + - Governance (rules, policies, processes) + - Structural (channels, roles, team changes) + - Tooling (bots, automation, integrations) + - Events (programs, activities, community events) + - Other + validations: + required: true + + - type: textarea + id: author-commitment + attributes: + label: Willingness to author + description: Are you willing to write the full CIP document? If not, are you looking for someone to take it on? + placeholder: "I'm willing to write the full CIP and see it through." + validations: + required: true + + - type: textarea + id: proposed-champion + attributes: + label: Proposed champion + description: Is there a staff member you'd like to champion this? If unsure, leave blank and staff will assign one. + placeholder: "@username or leave blank" + validations: + required: false + + - type: textarea + id: prior-discussion + attributes: + label: Prior discussion + description: Has this been discussed before? Link any relevant Discord threads, issues, or conversations. + placeholder: "Discussed in #general on 2026-03-01: https://discord.com/..." + validations: + required: false + + - type: checkboxes + id: checklist + attributes: + label: Checklist + options: + - label: I searched existing issues and CIPs to avoid duplicates. + required: true + - label: I believe this requires a full CIP (not a simple rules or policy change). + required: true + - label: If AI tools were used in drafting this request, I have disclosed that below. + required: true + + - type: textarea + id: ai-disclosure + attributes: + label: AI disclosure + description: If AI tools were used to help draft any part of this request, describe how they were used. Leave blank if not applicable. + placeholder: "Used ChatGPT to help organize bullet points." + validations: + required: false diff --git a/rfcs/0003-rfcip-template.md b/rfcs/0003-rfcip-template.md new file mode 100644 index 0000000..69b2069 --- /dev/null +++ b/rfcs/0003-rfcip-template.md @@ -0,0 +1,302 @@ +# CIP-003: Community Improvement Plan Process + +| Field | Value | +| ----------------------- | ------------------------------------------------------------ | +| **CIP** | 003 | +| **Title** | Community Improvement Plan Process | +| **Author(s)** | balaa | +| **Champion** | — | +| **Status** | Draft | +| **Type** | Governance | +| **Date** | 2026-03-07 | +| **RFCIP Issue** | — | +| **Teams Affected** | All teams | +| **Discussion (GitHub)** | — | +| **Discussion (Discord)**| — | +| **Supersedes** | — | +| **Superseded by** | — | + +--- + +## Summary + +This CIP establishes the Community Improvement Plan process — a formal, community-led proposal system for changes that affect the OpenClaw Discord community. It defines the two artifacts (RFCIP and CIP), their structure, lifecycle, roles, and rules. All future CIPs are written against the template and process defined here. + +## Motivation + +The OpenClaw Discord community currently has lightweight GitHub issue templates for rules changes and policy changes. These work well for small, staff-driven tweaks, but there is no structured path for community members to propose and shepherd larger initiatives — things like channel restructuring, new tooling, event programs, or cross-team process changes. + +Without a formal proposal process: + +- Community-driven ideas lack a clear path from concept to implementation. +- Proposals vary wildly in quality and completeness, making them hard to evaluate. +- There is no public record of what was proposed, why it was accepted or rejected, and what alternatives were considered. +- Staff has no structured way to sponsor and advocate for community ideas. + +A lightweight RFC-inspired process fills this gap while keeping overhead appropriate for a Discord community, not a protocol specification body. + +## Detailed Design + +### Two Artifacts + +The CIP process involves two artifacts: + +#### 1. RFCIP (Request for Community Improvement Plan) + +A GitHub issue opened using the RFCIP issue template. This is a **mandatory screening gate** — every CIP must start as an RFCIP. Its purpose is to pitch an idea at low cost before investing in a full proposal. + +**RFCIP fields:** + +| Field | Required | Description | +| -------------------- | -------- | -------------------------------------------------------- | +| Problem statement | Yes | What problem, gap, or opportunity this addresses | +| Proposed direction | Yes | High-level sketch of the proposed solution | +| Scope and impact | Yes | What parts of the community are affected | +| CIP type | Yes | Governance, Structural, Tooling, Events, or Other | +| Willingness to author| Yes | Whether the submitter will write the full CIP | +| Proposed champion | No | Preferred staff sponsor, if any | +| Prior discussion | No | Links to relevant Discord threads or issues | +| AI disclosure | No | How AI tools were used, if applicable | + +**Checklist (all required):** +- Searched existing issues and CIPs to avoid duplicates. +- Believes this requires a full CIP (not a simple rules or policy change). +- If AI tools were used, has disclosed that. + +#### 2. CIP (Community Improvement Plan) + +A formal markdown document submitted as a pull request to the `rfcs/` directory. The CIP number is **sequentially assigned by the champion** when the RFCIP is greenlit. The file is named `rfcs/XXXX-short-descriptive-slug.md`. + +**CIP metadata header:** + +| Field | Description | +| ----------------------- | --------------------------------------------------------- | +| CIP | Sequentially assigned number | +| Title | Descriptive title | +| Author(s) | Name(s) and Discord handle(s) | +| Champion | Staff sponsor — name and Discord handle | +| Status | Draft, Discussion, Accepted, or Rejected | +| Type | Governance, Structural, Tooling, or Events | +| Date | Date of initial submission (YYYY-MM-DD) | +| RFCIP Issue | Link to the originating RFCIP issue | +| Teams Affected | Which teams are impacted | +| Discussion (GitHub) | Link to the CIP pull request | +| Discussion (Discord) | Link to Discord thread, if any | +| Supersedes | CIP number this replaces, if applicable | +| Superseded by | CIP number that replaced this, if applicable | + +**CIP document sections:** + +| # | Section | Purpose | +| -- | -------------------- | ---------------------------------------------------------------------- | +| 1 | Summary | One-paragraph overview of the proposal | +| 2 | Motivation | The problem or opportunity; concrete examples and evidence | +| 3 | Detailed Design | The core proposal in full detail; before/after states where applicable | +| 4 | Drawbacks | Honest costs, risks, and trade-offs | +| 5 | Alternatives | Other approaches considered and why they were rejected | +| 6 | Prior Art | Examples from other communities or platforms | +| 7 | Implementation Plan | Concrete steps, responsibilities, and required changes | +| 8 | Timeline | Proposed schedule and milestones | +| 9 | Success Metrics | Measurable or observable outcomes that define success | +| 10 | Unresolved Questions | Open items needing further discussion or investigation | + +An **AI Disclosure** section is included at the end when AI tools were used in drafting. + +### Lifecycle + +A CIP moves through three states: + +``` +Draft ──▶ Discussion ──▶ Accepted + └──▶ Rejected +``` + +- **Draft:** The CIP pull request has been opened. The author and champion are refining the document. +- **Discussion:** The CIP is ready for community review. A **minimum 7-day discussion period** begins. Discussion happens on both the GitHub pull request (formal review) and Discord (informal discussion). The champion chooses the Discord venue per-CIP. +- **Accepted:** The Admin has approved the CIP. The pull request is merged and a tracking issue is opened for implementation. +- **Rejected:** The Admin has declined the CIP. The pull request is closed with rationale documented. + +### 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 +``` + +### Roles + +#### Author +- Any community member. +- Writes the RFCIP and (if willing) the full CIP document. +- Responds to feedback and revises the proposal during discussion. + +#### Champion +- A staff member who serves as **sponsor and advocate** for the proposal. +- **Assigns the CIP number** when greenlighting the RFCIP (next available sequential number). +- Actively advocates for the proposal to the Admin and team leads. +- Takes ownership of shepherding the CIP through the process. +- Chooses the Discord discussion venue. +- Posts periodic summaries if discussion spans both platforms. + +#### Admin +- Makes the **final accept or reject decision** on every CIP. +- Consistent with the existing community hierarchy. + +### Numbering + +CIP numbers are **sequential and manually assigned by the champion** when the RFCIP is greenlit. The champion determines the next available number before the author opens the CIP pull request. The file is named: + +``` +rfcs/XXXX-short-descriptive-slug.md +``` + +For example, if the next available number is 004: +``` +rfcs/0004-voice-channel-restructure.md +``` + +The champion is responsible for checking existing CIPs to avoid number collisions. + +### 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| + +### Withdrawal + +An author may withdraw their CIP at any time before acceptance by closing their pull request. No approval is needed. + +### Amending Accepted CIPs + +Changes to accepted CIPs require a **new CIP that supersedes** the original. The new CIP sets `Supersedes: CIP-XXXX` in its header, and the original CIP is updated to set `Superseded by: CIP-YYYY`. In-place edits to accepted CIPs are not permitted. + +### AI Policy + +AI-assisted drafting is permitted for both RFCIPs and CIPs, but **must be disclosed**. The RFCIP issue template includes an AI disclosure field. The CIP document template includes an AI Disclosure section. The focus is on content quality and transparency, not policing the tools used. + +### Relationship to Existing Templates + +The CIP process runs **in parallel** with the existing rules-change and policy-change issue templates. Those templates remain the appropriate path for small, targeted changes to rules or policies. CIPs are for larger, structural, or cross-cutting proposals that benefit from the full RFC treatment. + +## Drawbacks + +- **Process overhead.** For a Discord community, even a lightweight RFC process adds friction. Some good ideas may not get proposed because the process feels heavy. +- **Champion bottleneck.** Requiring a staff champion means proposals can stall if no staff member is available or interested in sponsoring. +- **Low volume risk.** If CIPs are rarely used, the process becomes dead infrastructure that confuses newcomers. +- **Parallel processes.** Having both lightweight issue templates and the CIP process may create ambiguity about which path to use. + +## Alternatives + +- **Expand existing issue templates.** Add more fields to the rules/policy change templates instead of creating a new process. Rejected because the scope of CIPs is much broader than rules/policy, and the proposal-review-accept lifecycle doesn't map to a single issue template. +- **Discord-only proposals.** Use Discord threads or a forum channel for proposals without GitHub. Rejected because GitHub provides better long-term record-keeping, version control, and structured review. +- **Wiki-based proposals.** Use the GitHub wiki. Rejected because wikis lack the PR-based review workflow that makes Rust RFCs effective. +- **No formal process.** Continue with ad-hoc community suggestions. Rejected because this provides no structured path from idea to implementation and no public record of decisions. + +## Prior Art + +- **Rust RFCs** ([rust-lang/rfcs](https://github.com/rust-lang/rfcs)): PR-based, discussion-heavy, merged when accepted. Primary inspiration for the CIP process. Adapted from a programming language context to a community governance context. +- **Python PEPs** ([python/peps](https://github.com/python/peps)): Numbered proposals with an editor role and formal lifecycle. More heavyweight than needed here. +- **Ethereum EIPs** ([ethereum/EIPs](https://github.com/ethereum/EIPs)): Typed proposals (Standards, Meta, Informational) with clear status flow. The type categorization (Governance, Structural, Tooling, Events) is loosely inspired by EIP types. +- **IETF RFCs**: Highly formal, consensus-driven. Too heavyweight for a Discord community, but the concept of a numbered, permanent record of decisions is valuable. + +## 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`. +3. **Deploy the RFCIP issue template** (`.github/ISSUE_TEMPLATE/rfcip.yml`). +4. **Create a blank CIP template file** for authors to copy when starting a new CIP. +5. **Update the repository README** to reference the CIP process and link to `rfcs/README.md`. +6. **Announce the CIP process** in the Discord #announcements channel. +7. **Brief staff** on the champion role and expectations. + +## Timeline + +- **Week 1:** Merge CIP-003 and supporting files. Create labels. Update README. +- **Week 2:** Announce to the community. Brief staff on the process. +- **Ongoing:** Iterate on the process based on experience with the first few CIPs. + +## Success Metrics + +- At least **3 RFCIPs** submitted within the first 3 months. +- At least **1 CIP accepted** within the first 3 months. +- Community members report the process is **clear and accessible** (qualitative feedback). +- Staff champions report the workload is **manageable** (qualitative feedback). +- No CIPs stall indefinitely waiting for a champion (champion assigned within 7 days of RFCIP submission). + +## Unresolved Questions + +- Should there be a maximum time limit for the discussion period, or can it stay open indefinitely? +- Should deferred CIPs (good idea, wrong time) have a formal status, or is rejection with a note sufficient? +- How should CIPs that span multiple types be labeled? +- Should the community be able to see a dashboard or index of all CIPs and their statuses? +- What happens if a champion leaves staff mid-process — is a new champion assigned automatically? + +--- + +## 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. + +--- + +*This is the foundational CIP that defines the Community Improvement Plan process. +To propose a CIP, start by opening an [RFCIP issue](https://github.com/openclaw/community/issues/new?template=rfcip.yml).* diff --git a/rfcs/README.md b/rfcs/README.md new file mode 100644 index 0000000..d0b032c --- /dev/null +++ b/rfcs/README.md @@ -0,0 +1,51 @@ +# Community Improvement Plans (CIPs) + +This directory contains Community Improvement Plans — formal proposals for changes that affect the OpenClaw Discord community. + +## Process + +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. +4. **Discussion:** Minimum 7-day discussion period on the GitHub PR and (optionally) Discord. The champion chooses the Discord venue. +5. **Decision:** The Admin makes the final accept or reject decision. +6. **Accepted:** PR is merged. A tracking issue is opened for implementation. +7. **Rejected:** PR is closed with rationale documented. + +## Naming + +CIP numbers are sequential, assigned by the champion when the RFCIP is greenlit. File names follow the pattern: + +``` +rfcs/XXXX-short-descriptive-slug.md +``` + +## Lifecycle Labels + +| Label | Meaning | +| --- | --- | +| `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 | + +## Type Labels + +| Label | Meaning | +| --- | --- | +| `cip:governance` | Rules, policies, processes | +| `cip:structural` | Channels, roles, team changes | +| `cip:tooling` | Bots, automation, integrations | +| `cip:events` | Programs, activities, community events | + +## Key Rules + +- **Anyone** in the community can author a CIP, but a **staff champion** is required. +- Authors may **withdraw** their CIP at any time before acceptance. +- Changes to **accepted CIPs** require a new CIP that supersedes the original. +- **AI-assisted drafting** is permitted but must be disclosed. + +## Template + +- [`0003-rfcip-template.md`](0003-rfcip-template.md) — CIP-003: the formal specification of the CIP process +- [`XXXX-cip-blank-template.md`](XXXX-cip-blank-template.md) — Blank template to copy when starting a new CIP diff --git a/rfcs/XXXX-cip-blank-template.md b/rfcs/XXXX-cip-blank-template.md new file mode 100644 index 0000000..5c11956 --- /dev/null +++ b/rfcs/XXXX-cip-blank-template.md @@ -0,0 +1,81 @@ +# CIP-[CIP#]: [Title] + +| Field | Value | +| ----------------------- | ------------------------------------------ | +| **CIP** | [Assigned number] | +| **Title** | [Descriptive title] | +| **Author(s)** | [Name(s) and Discord handle(s)] | +| **Champion** | [Staff sponsor — name and Discord handle] | +| **Status** | Draft | +| **Type** | Governance / Structural / Tooling / Events | +| **Date** | YYYY-MM-DD | +| **RFCIP Issue** | #[issue number] | +| **Teams Affected** | [e.g., Moderators, Helpers, Configurators] | +| **Discussion (GitHub)** | [Link to this PR] | +| **Discussion (Discord)**| [Link to Discord thread, if any] | +| **Supersedes** | — | +| **Superseded by** | — | + +--- + +## Summary + + + +## Motivation + + + +## Detailed Design + + + +## Drawbacks + + + +## Alternatives + + + +## Prior Art + + + +## Implementation Plan + + + +## Timeline + + + +## Success Metrics + + + +## Unresolved Questions + + + +--- + +## AI Disclosure + + + +--- + +*This document follows the [Community Improvement Plan process](0003-rfcip-template.md). +To propose a CIP, start by opening an [RFCIP issue](https://github.com/openclaw/community/issues/new?template=rfcip.yml).*