CIP-001: Community Staff Onboarding System#1
Open
thebalaa wants to merge 6 commits intoopenclaw:mainfrom
Open
Conversation
Introduces a general onboarding framework for all four community staff teams (Discord Mod, VC Mod, Helper, Configurator) with team-specific extensions. ## General Framework (community-staff-001-onboarding.md) - Email-based entry point via shadow@openclaw.ai - /onboard-start command with --team flag for team leads - Application → Trial → Promotion pipeline applicable to all teams - Extensible trial requirements (teams define their own criteria) - Team voting system with Team Lead final approval - Community Staff umbrella role granted on promotion - Privacy-first for trials (no public visibility until promotion) - Security requirements (Discord 2FA, GitHub 2FA) - Full audit trail and permanent data retention - Configurable cooldown periods and vote windows ## Voice Extensions (rfc/voice/voice-001-extensions.md) - Time slot system: 6+ hour minimum, 1-hour blocks, 24/7 coverage - Voice presence tracking: 75% threshold (45 min/hour), zero tolerance - Trial commands: /slots, /claim, /unclaim, /my-slots, /report - Clawtributor role system for protected voice channels - Clawtributor commands: /voc-nominate, /voc-remove, /voc-nominations - Trial metrics: slot completion, channel diversity, report quality - Extended data model: TimeSlot, Report, ClawtributorNomination entities ## Design Goals - Single bot managing onboarding for all 4 teams - Extensible architecture for team-specific requirements - Consistent experience across teams with flexibility for unique needs - Clear separation of concerns between general and team-specific features Future RFCs will define extensions for Discord Mod, Helper, and Configurator teams. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
thewilloftheshadow
requested changes
Mar 4, 2026
Member
thewilloftheshadow
left a comment
thewilloftheshadow
left a comment
There was a problem hiding this comment.
Welcome back! I submitted some initial comments from a quick read-through, will defer to @alauppe's leadership on the voice-specific RFC.
Additionally, in a couple hours, Barnacle is being split into two bots, with the Sapphire moderation portion being called Barnacle and the new utility bot being called Hermit. You'll be able to implement your part on there, and have the full bot + database available
alauppe
reviewed
Mar 4, 2026
Member
alauppe
left a comment
alauppe
left a comment
There was a problem hiding this comment.
Overall, this is a strong RFC direction. The mechanism keeps humans in the loop at the right decision points while still giving the bot enough structure to enforce consistency.
Non-blocking recommendations from my review:
- Add an explicit
AWAITING_LEAD_APPROVALapplication status and a max wait window for lead sign-off so candidates do not stack indefinitely.
- Suggested default: auto-approve after 7 days if the team vote already passed.
- Clarify the VC slot data model for implementation.
- Since slots are pre-generated and can have multiple claimants, consider
SlotWindow+SlotClaim(or equivalent) to avoid ambiguity. - I am not concerned about this from a procedure/management perspective; this is mainly implementation clarity.
- Revisit Clawtributor governance and naming.
- Consider a voice-scoped term (for example,
Voice Clawtributor) to avoid confusion with code contributors. - Require at least one VC mod in the two-endorsement grant path.
- Keep an endorsement lineage/audit record so endorsements can be reviewed if issues arise.
- Add nomination hygiene rules.
- Nomination TTL: 30 days.
- Auto-close nominations if nominee leaves the guild.
- Send reminders before nomination expiry.
- Tune VC voting logistics.
- Suggested VC vote window: 72 hours (weekend-safe).
- Suggested quorum: at least 3 votes, with a small-team guard such as
min(3, eligible_voters).
- Handle promotion role-assignment failures as partial completion.
- Preserve affirmative vote outcome in record.
- Use a pending role-assignment state when role grant fails.
- Retry on rejoin is a good default.
- This is relatively minor and can be handled per-case if needed.
Though it is always a challenge to program and automate people-touching procedures involving approval and disapproval, this method does a lot to keep humans in the loop at the right spots. I think this mechanism has a great shot at being successful, and I look forward to watching it come together. It’s a privilege to be able to participate in its creation.
Member
Updated terminology for clarity: - "Clawtributor" → "VoiceContributor" throughout both RFCs - More descriptive name that clearly indicates voice channel contribution - Commands remain /voc-* for brevity (/voc-nominate, /voc-remove, etc.) - Updated all references in data model, configuration, and documentation Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Co-authored-by: Shadow <william.shadow@outlook.com>
Replace text-based ASCII workflow diagrams with a comprehensive mermaid flowchart that visualizes all four stages (Application, Onboarding, Trial, Promotion) in a single diagram with clear decision points, flow paths, and color coding. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Replace background fill colors with colored borders (stroke) to improve text contrast and readability. Success nodes use green borders, failure nodes use red borders. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
…ion approval requirements Implement explicit status tracking throughout the entire onboarding pipeline with clear state transitions and full audit trail. Add auto-approval timeout for Team Lead sign-off and structured application approval requirements. Status Changes: - Rename PENDING → APPLICATION_PENDING_REVIEW (clearer context) - Rename DENIED → APPLICATION_DENIED (distinguishes from DENIED_BY_LEAD) - Rename AUTO_PROMOTED → PROMOTED_BY_LEAD_INACTION (explicit) - Rename PROMOTED → PROMOTED_BY_LEAD (explicit) - Rename LEAD_DENIED → DENIED_BY_LEAD (consistent naming pattern) - Remove APPROVED status (team approval immediately starts trial) - Add AWAITING_TEAM_VOTE (trial complete, vote in progress) - Add AWAITING_LEAD_APPROVAL (vote passed, awaiting Lead sign-off with 7-day timeout) - Keep VOTE_FAILED (vote did not reach majority) - Keep TRIAL_FAILED (failed trial requirements) Application Approval Requirements: - Require 2 full team members to approve, OR 1 Team Lead approval - Any single full team member can deny (immediate denial) - Only full team members (not trial members) can approve/deny applications - Track all approvers in approved_by array field - Track denier in denied_by field Data Model: - Add comprehensive status values table with descriptions and state transitions - Replace reviewer_id with approved_by (array) and denied_by (single ID) - Add lead_approval_deadline timestamp (when auto-approve will trigger) - Add lead_decision_by field (Team Lead ID at time of decision/timeout) - Add lead_decided_at timestamp (when decision was made) - Define terminal states clearly (APPLICATION_DENIED, TRIAL_FAILED, VOTE_FAILED, PROMOTED_BY_LEAD, PROMOTED_BY_LEAD_INACTION, DENIED_BY_LEAD) Configuration: - Add LEAD_APPROVAL_TIMEOUT_DAYS variable (default: 7) Workflow: - Update flowchart to show 2-approval requirement (or Team Lead) - Show status changes at each transition - Add AWAITING_TEAM_VOTE state to flowchart - Show all three outcomes from AWAITING_LEAD_APPROVAL with Lead ID recording - Clarify that Team Lead ID is recorded for all final promotion/denial decisions Documentation: - Update Review Process section with explicit approval requirements - Update edge cases to reflect auto-approval, explicit Lead denial, and Lead tracking - Update DM and team channel notifications for all new statuses - Update Vote Mechanics section with timeout details - Clarify reapplication eligibility after terminal states Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
thewilloftheshadow
approved these changes
Mar 5, 2026
Member
thewilloftheshadow
left a comment
thewilloftheshadow
left a comment
There was a problem hiding this comment.
LGTM, I look forward to seeing implementations! Let me know if you need assistance, and start a post in our projects channel (https://discord.com/channels/1456350064065904867/1477367750665175212) to get the other staff in the loop!
thebalaa
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Overview
This CIP (community improvement plan) introduces a comprehensive onboarding system for all four OpenClaw community staff teams (Discord Mod, VC Mod, Helper, Configurator).
Architecture
The system is designed with a general framework + team-specific extensions pattern:
📋 General Framework (
rfc/community-staff-001-onboarding.md)Provides the core onboarding pipeline applicable to all teams:
/onboard-start @user --team [team]command for team leads🎤 Voice Extensions (
rfc/voice/voice-001-extensions.md)Adds VC Mod-specific features:
/slots,/claim,/report,/voc-nominate, etc.Design Goals
✅ Single bot managing onboarding for all 4 teams
✅ Extensible architecture for team-specific requirements
✅ Consistent experience with flexibility for unique team needs
✅ Clear separation between general and team-specific features
Future Work
Additional RFCs will define extensions for:
Files Changed
rfc/community-staff-001-onboarding.md(667 lines) - General frameworkrfc/voice/voice-001-extensions.md(468 lines) - VC Mod extensionsRequest for Comments
Feedback requested on:
Related: Reconciles with Feb 28, 2026 mod meeting decisions on organizational structure.