OperationsPAI Governance

This document describes the governance model for the OperationsPAI community.

Current Stage: Bootstrap Phase

OperationsPAI is in its early bootstrap phase (2026-2027). During this period, governance is intentionally lightweight to enable rapid iteration and experimentation.

Governance Principles

1. Meritocracy

Influence is earned through contributions, not granted by title.

2. Transparency

Decisions are made openly with community input.

3. Inclusivity

All voices are heard, especially from diverse backgrounds and use cases.

4. Pragmatism

We prioritize working solutions over perfect processes.

Decision-Making

Day-to-Day Decisions

Who Decides: Repository maintainers

Examples:

• Bug fixes
• Documentation updates
• Minor feature additions
• Code review and merging

Process: Standard pull request review and approval

Significant Technical Decisions

Who Decides: Core team with community input

Examples:

• Major architectural changes
• New repository creation
• Breaking API changes
• Technology stack changes

Process:

1. Proposal in GitHub Discussions
2. Community feedback period (1-2 weeks)
3. Core team decision
4. Public announcement

Strategic Decisions

Who Decides: Core team with academic advisors

Examples:

• Project roadmap and priorities
• Research directions
• Partnership agreements
• Funding allocation

Process:

1. Internal core team discussion
2. Community RFC (Request for Comments)
3. Feedback integration
4. Final decision with rationale published

Roles and Responsibilities

Community Members

Anyone who engages with the project:

• Use the software
• Report bugs
• Ask questions
• Participate in discussions

Rights:

• Access to all public resources
• Voice in community discussions
• Fair treatment per Code of Conduct

Contributors

Definition: Made at least one merged contribution

Responsibilities:

• Follow contribution guidelines
• Respond to feedback on PRs
• Help review others’ contributions

Rights:

• Listed in repository contributors
• Invited to contributor channels
• Vote in community polls

Maintainers

Definition: Trusted contributors with repository write access

Responsibilities:

• Review and merge pull requests
• Triage issues
• Maintain code quality
• Guide contributors
• Participate in technical decisions

Rights:

• Repository write access
• Vote on technical decisions
• Represent the project in technical forums

Current Maintainers: See individual repository MAINTAINERS.md files

Core Team

Definition: Strategic leaders of the project

Responsibilities:

• Set project vision and roadmap
• Make strategic decisions
• Represent the project publicly
• Mentor maintainers
• Ensure project sustainability

Rights:

• Final decision authority
• Access to all resources
• Speak on behalf of the project

Current Core Team:

• To be listed as team forms

Becoming a Maintainer

Maintainers are nominated by existing maintainers based on:

1. Sustained Contributions: 6+ months of regular contributions
2. Technical Expertise: Deep knowledge of specific components
3. Community Engagement: Helpful to other contributors
4. Judgment: Makes sound technical decisions
5. Alignment: Shares project values and vision

Process:

1. Nomination by existing maintainer
2. Discussion among current maintainers
3. Consensus decision (no objections)
4. Public announcement and onboarding

Conflict Resolution

Level 1: Direct Communication

Most conflicts are resolved through respectful direct communication.

Level 2: Maintainer Mediation

If direct communication fails, maintainers can mediate.

Level 3: Core Team Decision

For unresolved conflicts, the core team makes a final decision.

Code of Conduct Violations

Handled separately per Code of Conduct enforcement process.

Evolution of Governance

As the community grows, governance will evolve:

Phase 1: Bootstrap (2026-2027)

• Current: Lightweight, core team-led
• Focus: Rapid iteration, community building

Amendments

This governance document can be amended by:

1. Proposal in GitHub Discussions
2. Community feedback period (2 weeks minimum)
3. Core team approval
4. Public announcement of changes

Questions and Feedback

Have questions about governance?

• Open a discussion in GitHub Discussions
• Email the core team (to be established)

Last Updated: February 2026