Skip to content

GOVERNANCE_PROTOCOL.md

Latest commit

 

History

History
1231 lines (935 loc) · 31.4 KB

GOVERNANCE_PROTOCOL.md

File metadata and controls

1231 lines (935 loc) · 31.4 KB
Raw

Fused Gaming Governance Protocol

Version: 1.0 Effective Date: January 16, 2026 Last Updated: January 16, 2026 Next Review: April 16, 2026 Status: Active

Document Purpose

This document establishes formal operational protocols for executing the governance framework defined in GOVERNANCE.md. While GOVERNANCE.md defines what and why, this protocol defines how and when.

Scope: All organizational decisions, community interactions, and project operations across the Fused Gaming ecosystem.

Table of Contents

  1. Decision-Making Protocols
  2. Voting Procedures
  3. Proposal Submission Process
  4. Meeting Protocols
  5. Conflict Resolution Procedures
  6. Role Assignment and Changes
  7. Project Lifecycle Protocols
  8. Emergency Decision Protocol
  9. Documentation and Transparency
  10. Amendment Procedures

Decision-Making Protocols

Protocol 1.1: Routine Decision Process

Scope: Bug fixes, documentation updates, minor improvements, dependency updates

Procedure:

  1. Submission (Day 0)

    • Create pull request with clear title and description
    • Link related issues using Fixes #N or Relates to #N
    • Ensure all automated checks pass (tests, linting, security scans)
    • Apply appropriate labels: type: bug, type: documentation, etc.

  2. Review Window (Day 0-1)

    • Minimum 24-hour review period from submission
    • Assignee reviews within 48 hours
    • Community members may provide feedback

  3. Approval (Day 1+)

    • Requires: 1 approval from maintainer OR technical lead
    • No blocking comments or change requests
    • All CI/CD checks passing

  4. Merge (Day 1+)

    • After 24-hour minimum window + approval
    • Squash and merge for single commits
    • Merge commit for multiple logical commits
    • Delete branch after merge

Fast-Track Exemption: Critical security fixes may bypass 24-hour window with approval from 2 core team members.

Protocol 1.2: Significant Decision Process

Scope: New features, dependency changes, refactoring, API changes

Procedure:

  1. Proposal Creation (Day 0)

    • Create GitHub issue with template
    • Title format: [PROPOSAL] Brief description
    • Include:
      • Problem statement
      • Proposed solution
      • Alternative approaches considered
      • Impact assessment
      • Resource requirements
    • Apply label: type: proposal

  2. Community Feedback (Day 0-7)

    • Minimum 3-day feedback period
    • Recommended 7 days for complex proposals
    • Announce in:
      • GitHub Discussions
      • Telegram channel
      • Twitter (for major features)
    • Proposer responds to questions within 48 hours

  3. Core Team Review (Day 3-7)

    • At least 2 core team members review
    • Technical lead provides technical assessment
    • Security team reviews if security-relevant

  4. Decision (Day 7)

    • Requires: 2+ core team approvals
    • Document decision rationale in issue
    • Update relevant documentation
    • Close issue or convert to implementation task

  5. Implementation (Day 7+)

    • Create milestone/project board card
    • Assign to owner
    • Follow routine PR process for implementation

Escalation: If no consensus after 10 days, escalate to strategic decision process.

Protocol 1.3: Strategic Decision Process

Scope: New projects, major architecture changes, governance updates, funding decisions

Procedure:

  1. RFC Creation (Day 0)

    • Create issue with type: rfc label
    • Title format: [RFC] Strategic initiative name
    • Required sections:
      • Executive Summary
      • Problem/Opportunity
      • Proposed Solution
      • Alternatives Considered
      • Resource Requirements (time, budget, people)
      • Success Metrics
      • Risk Assessment
      • Implementation Timeline
      • Community Impact

  2. Public Announcement (Day 0-1)

    • Announce in all channels:
      • GitHub Discussions (pinned)
      • Telegram
      • Twitter/X
      • LinkedIn
    • Create dedicated discussion thread
    • Schedule community discussion session if needed

  3. Community Feedback Period (Day 0-14)

    • Minimum 14 days for community input
    • Extended to 21 days for governance changes
    • Host live discussion session (optional)
    • Proposer maintains FAQ section in RFC

  4. Core Team Deliberation (Day 14-16)

    • All core team members review
    • Private deliberation session if needed
    • Consider all community feedback
    • Prepare decision document

  5. Decision & Communication (Day 17)

    • Requires: 3+ core team member approvals
    • For governance changes: 75% of core team approval
    • Document:
      • Final decision (approve/reject/defer)
      • Rationale
      • How community feedback was considered
      • Next steps if approved
    • Announce decision publicly in all channels

  6. Implementation Planning (Day 18+)

    • Create detailed project plan
    • Assign project lead
    • Set milestones and checkpoints
    • Begin execution

Special Provisions:

  • Governance Changes: 21-day minimum feedback + 75% core team approval
  • Financial Decisions >$1000: Requires public disclosure of budget impact
  • Partnership Agreements: Require legal review + conflict of interest disclosure

Voting Procedures

Protocol 2.1: Standard Voting Process

When Required:

  • No consensus after discussion period
  • Conflict resolution escalation
  • Core team membership changes
  • Strategic decisions requiring formal vote

Procedure:

  1. Vote Initiation

    • Any core team member may call for vote
    • Must be announced 48 hours before voting opens
    • State clearly:
      • Vote question/motion
      • Voting period (minimum 72 hours)
      • Eligible voters
      • Required threshold

  2. Eligible Voters

    • Routine/Significant Decisions: Core team members
    • Strategic Decisions: Core team + active contributors (10+ PRs or 6+ months activity)
    • Governance Changes: Core team + active contributors + advisory members

  3. Voting Period

    • Minimum 72 hours for standard votes
    • Minimum 7 days for strategic votes
    • Votes cast via:
      • GitHub issue comments (preferred)
      • Private channel for sensitive matters
    • Vote options: Approve, Reject, Abstain

  4. Vote Counting

    • Simple majority (>50%) for routine decisions
    • Supermajority (≥66%) for significant decisions
    • Supermajority (≥75%) for governance changes
    • Abstentions not counted in threshold calculation
    • Quorum requirement: 50% of eligible voters must participate

  5. Result Announcement

    • Results published within 24 hours of vote closing
    • Include:
      • Final tally (anonymized if requested)
      • Decision outcome
      • Implementation plan or next steps
    • Document in issue/discussion thread

  6. Implementation

    • Winning decision takes effect immediately unless otherwise specified
    • Losing side may request documentation of minority opinion
    • All parties expected to support final decision publicly

Protocol 2.2: Emergency Vote Process

When Required: Security incidents, legal threats, imminent harm situations

Procedure:

  1. Emergency Declaration

    • Any 2 core team members may declare emergency
    • Must state nature of emergency
    • Document why standard process insufficient

  2. Expedited Voting

    • Voting period: 24 hours minimum
    • Notification: All available channels immediately
    • Required: 75% of core team approval
    • Quorum: 60% of core team

  3. Post-Emergency Review

    • Within 7 days, conduct retroactive review
    • Community informed of decision
    • Document lessons learned
    • Update protocols if needed

Proposal Submission Process

Protocol 3.1: Project Proposal Submission

For: New projects, major initiatives, significant resource commitments

Required Information:

  1. Project Overview

    • Name and tagline
    • Problem statement (what problem does this solve?)
    • Target audience
    • Success criteria

  2. Technical Details

    • Technology stack
    • Architecture overview
    • Dependencies
    • Integration points with existing systems

  3. Resource Requirements

    • Development time estimate
    • Infrastructure costs
    • Ongoing maintenance needs
    • Required skills/expertise

  4. Impact Assessment

    • Community benefit
    • Alignment with strategic goals (reference GOALS.md)
    • Potential risks
    • Opportunity cost

  5. Timeline

    • Key milestones
    • MVP target date
    • Full launch target
    • Dependencies on other projects

  6. Team

    • Proposed project lead
    • Core contributors
    • Skills needed
    • Contributor recruitment plan

Submission Process:

  1. Create issue using "Project Proposal" template
  2. Label: type: project-proposal, status: needs-review
  3. Post in GitHub Discussions for community visibility
  4. Present in community call if scheduled
  5. Follow Strategic Decision Process (Protocol 1.3)

Protocol 3.2: Feature Proposal Submission

For: New features in existing projects

Required Information:

  1. Feature Description

    • What the feature does
    • User stories/use cases
    • Expected behavior

  2. Justification

    • Why this feature is needed
    • User/community demand evidence
    • Alternative solutions considered

  3. Technical Approach

    • Implementation strategy
    • Changes required
    • Backward compatibility

  4. Testing Plan

    • How feature will be tested
    • Edge cases considered
    • Performance impact

Submission Process:

  1. Create issue in relevant repository
  2. Use feature request template
  3. Label: type: feature, status: needs-triage
  4. Follow Significant Decision Process (Protocol 1.2)

Meeting Protocols

Protocol 4.1: Community Call Protocol

Frequency: Monthly (last Wednesday of month) Duration: 60 minutes Format: Virtual (Discord/Telegram voice)

Procedure:

  1. Pre-Meeting (1 week before)

    • Announce date/time in all channels
    • Create agenda issue
    • Solicit community topics (5 days before)
    • Finalize agenda (3 days before)
    • Share agenda publicly (2 days before)

  2. Meeting Structure

    • 0:00-0:05: Welcome and introductions
    • 0:05-0:20: Project updates (2-3 minutes each)
    • 0:20-0:45: Community topics/discussions
    • 0:45-0:55: Open Q&A
    • 0:55-1:00: Action items and closing

  3. During Meeting

    • Designated moderator controls flow
    • Notes taker documents key points
    • Record meeting (with consent)
    • Time-box topics strictly

  4. Post-Meeting (within 48 hours)

    • Publish meeting notes in GitHub Discussions
    • Share recording (if available)
    • Create action item issues
    • Assign follow-ups to owners

  5. Accessibility

    • Meetings recorded and transcribed
    • Written summaries for those who cannot attend
    • Different time zones accommodated through rotation (quarterly)

Protocol 4.2: Core Team Meeting Protocol

Frequency: As needed (minimum quarterly) Participants: Core team members only Format: Private or public as appropriate

Agenda Categories:

  1. Organizational health review
  2. Strategic direction
  3. Sensitive matters (private)
  4. Community feedback synthesis
  5. Goal progress review

Transparency Requirements:

  • Public meeting notes for non-sensitive topics
  • Private matters documented in secure location
  • Decisions affecting community communicated within 48 hours
  • Rationale provided for all significant decisions

Conflict Resolution Procedures

Protocol 5.1: Technical Disagreement Resolution

Scope: Disagreements on technical approach, architecture, implementation

Steps:

  1. Direct Discussion (0-3 days)

    • Parties discuss in issue/PR comments
    • Focus on technical merits
    • Document pros/cons of each approach
    • Seek to understand, not to win

  2. Mediation (Day 3-5)

    • If no resolution, invite neutral third party
    • Technical lead mediates (if not involved)
    • Or invite external expert opinion
    • Joint review of requirements and constraints

  3. Technical Proposal (Day 5-7)

    • Each side writes technical proposal
    • Include:
      • Solution description
      • Pros/cons analysis
      • Risk assessment
      • Maintenance implications
    • Community feedback solicited

  4. Decision (Day 7-10)

    • Technical lead makes final call (if not involved)
    • Or core team votes
    • Decision based on:
      • Alignment with architecture principles
      • Long-term maintainability
      • Community benefit
      • Resource constraints

  5. Implementation & Retrospective

    • Implement winning approach
    • After 30 days, review decision
    • Document lessons learned
    • Update guidelines if needed

Principles:

  • Assume good faith
  • Focus on technical merits
  • Avoid personal attacks
  • Accept decision once made
  • Support chosen approach publicly

Protocol 5.2: Interpersonal Conflict Resolution

Scope: Disagreements involving behavior, communication, or personal issues

Steps:

  1. Private Communication (Day 0)

    • Affected parties communicate privately
    • Use "I" statements, not "you" accusations
    • Focus on behavior, not person
    • Seek mutual understanding

  2. Mediation Request (Day 1-3)

    • If unresolved, request mediator
    • Mediator must be:
      • Neutral (no stake in outcome)
      • Trusted by both parties
      • Trained in conflict resolution (preferred)
    • Mediator from core team or external

  3. Mediated Discussion (Day 3-7)

    • Private session with mediator
    • Each party shares perspective
    • Identify root causes
    • Develop mutual commitments

  4. Resolution Plan (Day 7)

    • Document agreed behaviors
    • Set check-in schedule
    • Define escalation path if needed
    • Both parties sign/agree

  5. Follow-up (Day 30)

    • Mediator checks in
    • Assess if resolution holding
    • Adjust if needed

Escalation to Code of Conduct Enforcement:

  • If mediation fails, may escalate to CoC process
  • If behavior violates CoC, skip mediation
  • If safety concerns exist, immediate escalation

Protocol 5.3: Governance Dispute Resolution

Scope: Disagreements about governance interpretation or application

Steps:

  1. Clarification Request

    • Create issue: [GOVERNANCE QUESTION] Topic
    • State the dispute clearly
    • Reference relevant governance documents
    • Explain different interpretations

  2. Core Team Review (3 days)

    • Core team reviews governance documents
    • Identifies ambiguity or gap
    • Proposes clarification or amendment

  3. Community Input (7 days)

    • Proposed interpretation shared publicly
    • Community provides feedback
    • Consider precedent and intent

  4. Decision

    • Core team vote on interpretation (simple majority)
    • Document in governance FAQ
    • Update governance documents if needed
    • Communicate decision publicly

  5. Appeal (within 30 days)

    • Decisions may be appealed with new information
    • Requires 2 core team members to sponsor appeal
    • Full re-review process
    • Final decision binding

Role Assignment and Changes

Protocol 6.1: Core Team Member Nomination

Eligibility Criteria:

  • 6+ months active contribution
  • 10+ merged PRs OR equivalent non-code contribution
  • Demonstrated alignment with values
  • Community recommendation
  • Technical competence in relevant area

Nomination Process:

  1. Nomination (Day 0)

    • Any core team member may nominate
    • Or individual may self-nominate
    • Submit nomination in private core team channel
    • Include:
      • Nominee name and GitHub handle
      • Contribution summary
      • Proposed role
      • Why this person is right fit

  2. Background Review (Day 0-3)

    • Review contribution history
    • Check for CoC violations
    • Assess activity patterns
    • Verify eligibility criteria met

  3. Core Team Discussion (Day 3-7)

    • Private discussion among core team
    • Address concerns
    • Consider team balance and needs
    • Assess nominee's interest and availability

  4. Vote (Day 7-10)

    • All core team members vote
    • Required: 75% approval
    • Anonymous voting allowed
    • Results shared with nominee only

  5. Invitation (Day 10)

    • If approved, extend invitation
    • Explain responsibilities and expectations
    • Allow 7 days for nominee to accept
    • If accepted, public announcement
    • If declined, thank nominee privately

  6. Onboarding (Day 10-30)

    • Grant appropriate repository access
    • Add to core team channels
    • Assign mentor for first 30 days
    • Provide governance orientation
    • Introduce to community

Protocol 6.2: Role Change or Removal

Voluntary Role Change:

  1. Member notifies core team of intention
  2. Transition period agreed (typically 30 days)
  3. Knowledge transfer to replacement
  4. Public announcement thanking member
  5. Transition to emeritus status (if applicable)

Involuntary Removal - Inactivity:

  1. Inactivity Definition: No meaningful contribution for 90 days
  2. Check-in (Day 90)
    • Private message to inactive member
    • Ask about status and intention
    • Offer support or reduced commitment option
  3. Grace Period (Day 90-120)
    • Allow 30 days to resume activity
    • Or plan transition
  4. Status Change (Day 120)
    • Move to emeritus status
    • Reduce permissions
    • Public thank you announcement
    • Door always open to return

Involuntary Removal - Performance/Conduct:

  1. Issue Identification

    • Performance concerns or conduct issues documented
    • Private discussion with member
    • Clear expectations set

  2. Improvement Plan (30 days)

    • Written plan with specific goals
    • Support provided
    • Regular check-ins

  3. Review (Day 30)

    • Assess progress
    • Continue, extend, or remove

  4. Removal Decision

    • Requires 75% core team vote
    • Member informed privately
    • Public announcement (minimal detail)
    • Immediate permission revocation if necessary

Appeals Process: Member may appeal to full core team within 14 days

Project Lifecycle Protocols

Protocol 7.1: Project Initialization

Prerequisites:

  • Approved project proposal (Protocol 3.1)
  • Identified project lead
  • Minimum viable team (lead + 1 contributor)

Initialization Steps:

  1. Repository Setup (Day 0-1)

    • Create repository from template
    • Set up branch protection
    • Configure CI/CD basics
    • Add required files:
      • README.md
      • LICENSE
      • CONTRIBUTING.md
      • SECURITY.md
      • .github/CODEOWNERS

  2. Documentation (Day 1-3)

    • Complete README with:
      • Project description
      • Installation instructions
      • Usage examples
      • Development setup
    • Create docs/ folder structure
    • Write architecture overview

  3. Team Setup (Day 3-5)

    • Assign core contributors
    • Set up communication channel
    • Define roles and responsibilities
    • Schedule kickoff meeting

  4. Initial Sprint Planning (Day 5-7)

    • Define MVP scope
    • Create milestones
    • Break down into issues
    • Assign initial tasks

  5. Public Announcement (Day 7)

    • Announce in all channels
    • Explain project purpose
    • Invite contributors
    • Set expectations for timeline

Required Checkpoints:

  • Week 2: First PR merged
  • Week 4: MVP scope validated
  • Week 8: Progress update to community
  • Month 3: Beta release or scope adjustment

Protocol 7.2: Project Health Review

Frequency: Quarterly for active projects

Review Criteria:

  1. Activity Metrics

    • Commits in last 90 days
    • PRs merged
    • Issues addressed
    • Community engagement

  2. Quality Metrics

    • Test coverage
    • Documentation completeness
    • Security scan results
    • Performance benchmarks

  3. Community Metrics

    • Active contributors
    • User adoption
    • Issue response time
    • Community sentiment

Review Process:

  1. Project lead prepares review document
  2. Present to core team
  3. Classify project status:
    • Healthy: Active development, growing
    • Stable: Mature, maintenance mode
    • Needs Attention: Declining activity
    • Seeking Maintainer: Lead stepping down
    • Sunset: Preparing for archive
  4. Update project documentation
  5. Communicate status to community

Protocol 7.3: Project Archival

Triggers:

  • No activity for 6+ months
  • No maintainer available
  • Project objectives achieved
  • Deprecated by better solution

Archival Process:

  1. Community Notice (30 days before)

    • Announce intention to archive
    • Explain rationale
    • Solicit new maintainer
    • Identify alternative solutions

  2. Knowledge Preservation

    • Complete all documentation
    • Document lessons learned
    • Create final release/snapshot
    • Update README with archive notice

  3. Repository Archival

    • Mark as archived on GitHub
    • Add clear banner to README
    • Disable issues/PRs
    • Preserve read access
    • Update org documentation

  4. Security Handling

    • Security policy marked as inactive
    • Critical vulnerabilities fixed before archival
    • Or clear warning if unfixable

  5. Post-Archival

    • May be un-archived if maintainer found
    • Community fork encouraged if demand exists
    • Link to active forks in README

Emergency Decision Protocol

Protocol 8.1: Emergency Classification

Level 1 - Critical Emergency:

  • Active security breach
  • Data loss incident
  • Legal threat
  • Imminent harm to community members
  • Complete service outage

Response: Immediate action authorized

Level 2 - Urgent Issue:

  • Security vulnerability disclosed
  • Major service degradation
  • PR crisis
  • Compliance deadline

Response: 24-hour expedited process

Level 3 - Time-Sensitive:

  • Opportunity with deadline
  • Competitive response needed
  • Partnership timing

Response: 72-hour accelerated process

Protocol 8.2: Emergency Response Process

Level 1 Response:

  1. Immediate (0-2 hours)

    • Any core team member may take immediate protective action
    • Notify all core team members immediately
    • Document actions taken
    • Contain incident

  2. Assessment (2-6 hours)

    • Assemble response team
    • Assess scope and impact
    • Determine if ongoing threat
    • Plan remediation

  3. Communication (6-12 hours)

    • Internal communication to core team
    • Public communication if needed (incident response plan)
    • Update stakeholders
    • Coordinate response

  4. Resolution (12-48 hours)

    • Implement fixes
    • Verify resolution
    • Monitor for recurrence
    • Document incident

  5. Post-Mortem (Within 7 days)

    • Root cause analysis
    • Document lessons learned
    • Update procedures
    • Community transparency report

Level 2 Response:

  • Expedited vote process (Protocol 2.2)
  • 24-hour decision timeline
  • Required core team alignment

Level 3 Response:

  • Accelerated proposal process
  • 72-hour community feedback
  • Core team decision authority

Documentation and Transparency

Protocol 9.1: Decision Documentation Requirements

All Decisions Must Document:

  1. Context

    • What decision was needed
    • Who was involved
    • When decision was made

  2. Process

    • What process was followed
    • How community was consulted
    • Feedback received

  3. Rationale

    • Why this decision was made
    • Alternatives considered
    • Trade-offs accepted

  4. Impact

    • Who is affected
    • What changes
    • Timeline for implementation

Documentation Locations:

  • GitHub Issues: For project-specific decisions
  • GitHub Discussions: For strategic/org-wide decisions
  • Meeting Notes: For decisions made in meetings
  • CHANGELOG.md: For decisions affecting users

Protocol 9.2: Public Records Maintenance

Required Public Records:

  1. Meeting Notes

    • All community calls
    • Public portions of core team meetings
    • Published within 48 hours

  2. Decision Log

    • Major decisions tracked
    • Updated monthly
    • Maintained in GitHub Wiki or Discussions

  3. Governance Changes

    • All amendments documented
    • Change history maintained
    • Version control via Git

  4. Metrics Reports

    • Monthly: Community health metrics
    • Quarterly: Progress on goals
    • Annually: Year in review

Record Retention:

  • Permanent: Governance documents, decisions, meeting notes
  • 2 years: Metrics reports, incident reports
  • 1 year: Routine communications

Protocol 9.3: Transparency Exceptions

Private Discussions Allowed For:

  1. Security Issues

    • Undisclosed vulnerabilities
    • Active incident response
    • Security planning

  2. Personnel Matters

    • Role changes/removals
    • Conflict resolution
    • Performance issues

  3. Legal Matters

    • Pending legal issues
    • Confidential agreements
    • Privacy-protected information

  4. Financial Negotiations

    • Ongoing partnership discussions
    • Funding negotiations
    • Sensitive budget matters

Requirements for Private Discussions:

  • Document that private discussion occurred
  • Explain why privacy was needed
  • Commit to transparency when possible
  • Summarize outcome publicly (when appropriate)

Amendment Procedures

Protocol 10.1: Protocol Amendment Process

Types of Changes:

Minor Changes (Clarifications, typos, formatting):

  • Any core team member may propose via PR
  • Requires 1 core team approval
  • No community feedback required
  • Effective immediately upon merge

Moderate Changes (New procedures, process refinements):

  • Create proposal issue
  • 7-day community feedback period
  • Requires 2 core team approvals
  • Announce change in all channels
  • 7-day notice before effective date

Major Changes (Fundamental governance changes):

  • Full RFC process (Protocol 1.3)
  • 21-day community feedback period
  • Requires 75% core team approval
  • May require community vote for significant changes
  • 30-day notice before effective date

Protocol 10.2: Annual Governance Review

Schedule: Every January

Review Process:

  1. Preparation (Weeks 1-2)

    • Core team reviews all governance documents
    • Identifies gaps, conflicts, outdated sections
    • Gathers community feedback from year
    • Compiles proposed changes

  2. Community Input (Weeks 3-4)

    • Share proposed changes
    • Solicit feedback
    • Host community discussion
    • Incorporate suggestions

  3. Finalization (Week 5)

    • Core team votes on changes
    • Document version history
    • Update all related documents
    • Publish new versions

  4. Communication (Week 6)

    • Announce changes
    • Explain rationale
    • Provide training if needed
    • Update FAQs

Effectiveness: New governance version effective February 1st

Appendix A: Quick Reference Guide

Decision-Making Quick Reference

Decision Type Timeline Approvals Needed Community Input
Routine 24h min 1 core team Optional
Significant 3-7 days 2+ core team Required
Strategic 14+ days 3+ core team Required
Emergency L1 Immediate Post-approval Post-notification
Emergency L2 24 hours 75% core team Expedited
Governance 21+ days 75% core team Required

Common Scenarios Reference

Scenario: I want to propose a new feature → Use Protocol 3.2 (Feature Proposal Submission) → Follow Protocol 1.2 (Significant Decision Process)

Scenario: There's a security vulnerability → Use Protocol 8.1 & 8.2 (Emergency Response) → Follow SECURITY.md reporting process

Scenario: Two contributors disagree on approach → Use Protocol 5.1 (Technical Disagreement Resolution)

Scenario: I want to join the core team → Review Protocol 6.1 eligibility criteria → Request nomination or self-nominate

Scenario: A project needs to be archived → Use Protocol 7.3 (Project Archival)

Scenario: I want to update governance docs → Use Protocol 10.1 (Amendment Process) → Determine if change is minor, moderate, or major

Appendix B: Templates

Decision Documentation Template

## Decision: [Title]

**Date**: YYYY-MM-DD
**Decision Maker(s)**: [Names/Roles]
**Status**: [Proposed/Approved/Implemented]

### Context
[What decision was needed and why]

### Process Followed
[Which protocol was used, who was consulted]

### Options Considered
1. **Option A**: [Description]
   - Pros: [List]
   - Cons: [List]
2. **Option B**: [Description]
   - Pros: [List]
   - Cons: [List]

### Decision
[What was decided]

### Rationale
[Why this decision was made]

### Impact
- **Who**: [Who is affected]
- **What**: [What changes]
- **When**: [Timeline]

### Action Items
- [ ] [Task 1]
- [ ] [Task 2]

### Related
- Issue #[N]
- Discussion #[N]

Meeting Notes Template

# [Meeting Type] - [Date]

**Date**: YYYY-MM-DD
**Time**: HH:MM [Timezone]
**Facilitator**: [Name]
**Notes**: [Name]
**Attendees**: [List]

## Agenda
1. [Topic 1]
2. [Topic 2]

## Discussion

### Topic 1: [Title]
[Summary of discussion]

**Decisions Made**:
- [Decision 1]

**Action Items**:
- [ ] [Task] - @owner - [Due date]

### Topic 2: [Title]
[Summary]

## Next Meeting
**Date**: [Date]
**Time**: [Time]
**Tentative Agenda**: [Topics]

Appendix C: Escalation Paths

Issue Level 1: Routine → Repository maintainer
                         ↓
Issue Level 2: Significant → Technical lead or 2+ core team
                             ↓
Issue Level 3: Strategic → Core team + community
                          ↓
Issue Level 4: Governance → Full governance process + vote

Conflict Level 1: Direct discussion
                  ↓
Conflict Level 2: Mediation
                  ↓
Conflict Level 3: Core team decision
                  ↓
Conflict Level 4: Code of Conduct enforcement

Emergency Level 1: Critical → Immediate action + core team notification
Emergency Level 2: Urgent → 24-hour expedited process
Emergency Level 3: Time-sensitive → 72-hour accelerated process

Appendix D: Contact Information

Process Questions

  • GitHub Discussions: Org-wide questions
  • GitHub Issues: Specific process questions (label: governance)
  • Core Team Email: [To be established]

Emergency Contact

  • Security: See SECURITY.md
  • Code of Conduct: [To be established]
  • Legal/Critical: [To be established]

Community Channels

Document History

Version Date Changes Author
1.0 2026-01-16 Initial protocol document Claude AI

Compliance Certification

This governance protocol complies with:

  • Fused Gaming GOVERNANCE.md framework
  • GOALS.md strategic objectives
  • Open source best practices
  • Transparent decision-making principles

Approved By: [To be completed by core team] Effective Date: [To be completed upon approval]

Related Documents

For questions about this protocol, create an issue with label governance or post in GitHub Discussions.

Last Updated: January 16, 2026 Version: 1.0 Next Review: April 16, 2026