Policy change: Add CIP (Community Improvement plan) Issue type for the Openclaw/Community Git, to be used by the community (dishord etc).

[Jonohobs]

Summary

Create a new issue type, in the openclaw/community repository, for the community improvement plan, RFC.

New Issue Type name: 'Community improvement plan'.

Current policy section

No current pollicy. The closest issue type is 'policy change request'

Proposed change

This change introduces an RFC-style community improvement plan issue-type in the Openclaw/community repository.

New Issue Type name: 'Community improvement plan'

Rationale

Adhoc conversations are rarely materializing into action - in part due to a lack of effective record keeping.

Leveraging the openclaw/community git-repository issues-section will provide a centralized place for members of the community to propose and discuss improvements.

Impact / enforcement notes

CIPs will follow conventional RFC guidelines.

Alternatives considered

More Adhoc conversations that rarely materialize.

Checklist

• I reviewed existing policy docs to avoid duplicates.
• I wrote the proposed text in a clear, enforceable way.
• I wrote this in my human voice with no AI assistance.

[thewilloftheshadow]

RFCs are done via PRs by our Community Staff based on GH issues submitted by others as well as their own plans, I want to have that intentional separation between discussions and official RFCs

What conversations are you seeing not materialize?

[thewilloftheshadow]

Thanks for sending this in, we'll be implementing a system like this very shortly!

[thebalaa]

@Jonohobs for posterity,

@thewilloftheshadow and I decided to introduce what we are calling the RFCIP (request for community improvement plan) issue type.

The general workflow will be as follows:

1. community members leverage RFCIP issue template (CIP-003) to propose well articulated and actionable improvements to one or more of the openclaw/community Discord subsystems

2. Community Staff team leads will review RFCIPs for relevance, feasibility, and cost/benefit analysis in order to make a determination on if/when the RFCIP is to be incorporated into a formal CIP.

Thank you for taking the time to create this issue. We look forward to your future contributions.

[Jonohobs]

No worries. I was talking with Mo and a couple of others in the Dischord VC, and I volunteered to scribe. I'm sure Mo's filled you in.

I used to work in videogames and wrote up hundred of forms like these, so it was kind of nostalgic. 😄

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 15, 2026, 1:33 PM ET / 17:33 UTC.

Summary
Keep open: current main still only has policy and rules issue forms, while the RFCIP/CIP implementation path in #8 is open and previously reviewed as not merge-ready, with the remaining durable work routed back to this issue.

Reproducibility: not applicable. this is a requested GitHub issue-template and governance workflow rather than a reproducible product bug. The current-main source check confirms no RFCIP/CIP issue template exists today.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
This needs maintainer governance review because adding an RFCIP/CIP path sets community process, and the existing implementation PR is open but not merge-ready.

Review details

Best possible solution:

Keep this as the canonical governance/process request until maintainers land a corrected RFCIP issue template and CIP process, or explicitly close the proposal after deciding not to add that intake path.

Do we have a high-confidence way to reproduce the issue?

Not applicable; this is a requested GitHub issue-template and governance workflow rather than a reproducible product bug. The current-main source check confirms no RFCIP/CIP issue template exists today.

Is this the best way to solve the issue?

Unclear; the requested direction has supportive maintainer discussion, but the exact workflow and governance authority still need maintainer approval before a replacement PR should land.

AGENTS.md: found, but no applicable review policy affected this item.

Remaining risk / open question:

• Maintainers still need to decide the final RFCIP/CIP governance boundary, including how community issue discussions become formal staff-owned CIP/RFC PRs.
• The existing open implementation PR has prior proof and merge-readiness concerns, so it should not be treated as the merged or safe canonical implementation.

Codex review notes: model internal, reasoning high; reviewed against 7165793a41e1.

Label changes

Label changes:

• add P3: This is a low-risk repository-process enhancement for community proposal intake, not an urgent runtime bug or regression.
• add impact:other: The request affects maintainer-visible community intake and record keeping, but it does not match the specific runtime impact categories.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: This is a low-risk repository-process enhancement for community proposal intake, not an urgent runtime bug or regression.
• impact:other: The request affects maintainer-visible community intake and record keeping, but it does not match the specific runtime impact categories.

Evidence reviewed

What I checked:

• Current issue templates: Current main lists only config.yml, policy-change.yml, and rules-change.yml under .github/ISSUE_TEMPLATE; there is no rfcip.yml or CIP issue form on main. (7165793a41e1)
• Closest current form: The current policy form is named "Policy change request", matching the reporter's statement that this was the closest available issue type rather than a dedicated CIP/RFCIP path. (.github/ISSUE_TEMPLATE/policy-change.yml:1, 7165793a41e1)
• Blank issue behavior: Blank issues are disabled and config.yml only exposes appeals/report contact links, so contributors cannot bypass templates to create an unstructured CIP issue from the configured issue chooser. (.github/ISSUE_TEMPLATE/config.yml:1, 7165793a41e1)
• Related implementation path: CIP-003: Formalize Community Improvement Plans (CIPs) #8 adds .github/ISSUE_TEMPLATE/rfcip.yml plus RFC/CIP process docs, but it is still open and its ClawSweeper review says the branch is not merge-ready and that remaining work is tracked in the canonical issue.
• Maintainer discussion: Issue discussion includes repository-member support for implementing a system like this and a later comment naming the RFCIP workflow and linking CIP-003: Formalize Community Improvement Plans (CIPs) #8, so the request is understandable and not stale-insufficient-info.
• Template history: The existing issue-template system was introduced by Shadow in commit 85dd57f, which is the central current-main history for this request. (.github/ISSUE_TEMPLATE/policy-change.yml:1, 85dd57f086aa)

Likely related people:

• thewilloftheshadow: They supplied member feedback on the RFC/RFCIP separation in this issue, and the current issue-template files trace to Shadow's 85dd57f commit. (role: issue-template feature owner and reviewer; confidence: high; commits: 85dd57f086aa; files: .github/ISSUE_TEMPLATE/config.yml, .github/ISSUE_TEMPLATE/policy-change.yml, .github/ISSUE_TEMPLATE/rules-change.yml)
• thebalaa: They documented the agreed RFCIP workflow in this issue discussion and authored the open implementation PR that adds the RFCIP issue template and CIP process docs. (role: RFCIP proposal author; confidence: medium; commits: 6d973948dbdb, 41594f9f5b43; files: .github/ISSUE_TEMPLATE/rfcip.yml, rfcs/0003-rfcip-template.md, rfcs/README.md)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.