physical-ai-toolchain

Physical AI Toolchain uses a liberal contribution model where active contributors are recognized for current work. Microsoft maintains stewardship of the project while welcoming community contributions and leadership.

Governance Model

This project operates under a corporate-sponsored maintainer model:

• Microsoft provides stewardship, infrastructure, and core maintainer resources
• Community contributors participate through standard open source workflows
• Decision authority flows from active participation rather than historical contribution
• Consensus-seeking is preferred over voting for routine decisions

Roles and Responsibilities

The following matrix summarizes capabilities by role:

Capability	Maintainer	Triage	Contributor
Code review	✅	✅	✅
Merge pull requests	✅	❌	❌
Release management	✅	❌	❌
Architecture decisions	✅	Advise	Propose
Issue triage	✅	✅	❌
Label management	✅	✅	❌

Maintainers

Maintainers guide project direction, manage releases, and resolve conflicts.

Responsibility	Description
Technical direction	Set architectural standards and approve significant changes
Release management	Coordinate versioning, changelogs, and publication
Community health	Enforce code of conduct and foster inclusive participation
Access management	Grant and revoke repository permissions

Current maintainers are members of the @microsoft/edge-ai-core-dev team.

Triage Contributors

Triage contributors assist maintainers by managing issue flow and initial assessments.

Responsibility	Description
Issue labeling	Apply appropriate labels to new issues
Initial assessment	Identify duplicates, request clarification, verify reproduction steps
Community support	Answer questions and direct contributors to resources

Triage contributors target the response times documented in SUPPORT.md for initial issue acknowledgment.

Contributors

Contributors improve the project through code, documentation, and community engagement.

Responsibility	Description
Code contributions	Submit pull requests following contribution guidelines
Documentation	Improve guides, fix errors, add examples
Issue reporting	Report bugs with reproduction steps and suggest enhancements
Community participation	Engage in discussions and help other users

Decision-Making Process

Decisions follow a tiered model based on impact and reversibility.

Routine Changes

Standard pull requests for bug fixes, documentation updates, and minor enhancements:

• Require one maintainer approval
• Merged after CI checks pass
• No waiting period unless review comments are pending

Significant Changes

New features, API additions, or changes affecting multiple components:

• Require two maintainer approvals
• Allow minimum 48-hour review window for maintainer input
• May require design discussion in an issue before implementation

Breaking Changes

Changes that alter existing behavior or remove functionality:

• Require two maintainer approvals with explicit breaking-change acknowledgment
• Document migration path in changelog and relevant documentation
• Follow semantic versioning for major version increments

Governance Changes

Modifications to this governance document or project policies:

• Require consensus among active maintainers
• Allow one-week comment period for community input

Role Progression

Contributors advance through demonstrated commitment and quality work.

Becoming a Triage Contributor

Contributors may be nominated for triage status after:

• Sustained positive contributions over three or more months
• Demonstrated understanding of project scope and standards
• Consistent, helpful engagement with other contributors

Nomination process:

1. Existing maintainer nominates candidate in a private discussion
2. Maintainers reach consensus on the nomination
3. Candidate is invited and onboarded to triage responsibilities

Becoming a Maintainer

Triage contributors and significant contributors may be nominated for maintainer status after:

• Consistent high-quality contributions over six or more months
• Technical judgment aligned with project direction
• Demonstrated ability to mentor other contributors

Nomination process:

1. Existing maintainer nominates candidate
2. Maintainers reach consensus
3. Candidate is onboarded to maintainer responsibilities

Inactivity and Role Changes

• Contributors inactive for six months may have elevated permissions reviewed
• Role removal is not punitive and contributors may return when availability permits
• Departing maintainers should assist with knowledge transfer when possible

Dispute Resolution

When contributors disagree on technical or process matters:

1. Discussion: Parties discuss the issue in the relevant pull request or issue
2. Maintainer input: If unresolved, a maintainer provides guidance
3. Maintainer decision: If consensus remains elusive, maintainers make a binding decision

Code of conduct violations follow the process defined in CODE_OF_CONDUCT.md.

Inactivity Closure Policy

Open issues and discussions that remain inactive create noise for contributors and maintainers. This section defines the lifecycle policy for closing inactive items. Automation that enforces this policy (stale bot, scheduled workflows) is a separate effort that references these thresholds.

For pull request inactivity policy, see Pull Request Inactivity Policy in the pull request process guide.

Issues

Issue inactivity follows a three-stage lifecycle:

Stage	Trigger	Label	Action
Active	Any activity within the past 60 days	(none)	Normal lifecycle
Stale	60 days without activity	stale	Warning comment posted
Closed-stale	14 days after stale label without activity	closed-stale	Issue closed as not_planned

Exemptions that prevent automatic closure:

• Issues labeled pinned, security, or do-not-close
• Issues assigned to any milestone

Reopening rules:

• Any participant can reopen a stale-closed issue with additional context
• Reopening removes the stale label and resets the inactivity clock

Discussions

The same 60-day warning and 14-day closure thresholds apply to GitHub Discussions in principle. The same exemptions that prevent automatic closure for issues (pinned, security, do-not-close, or assigned to a milestone) and the same reopening behavior (reopening clears any stale status and resets the inactivity clock) apply to Discussions.

Because current automation tooling (actions/stale) does not support Discussions, enforcement is manual through periodic triage until dedicated tooling is implemented.

Access Continuity

Project continuity is ensured through Microsoft stewardship:

• Multiple Microsoft employees maintain administrative access
• Critical credentials (GitHub admin, CI/CD) are managed through Microsoft infrastructure
• Succession planning ensures no single point of failure for project operations
• Repository, domain, and service access survive individual personnel changes

Contribution Authorization

All contributions require agreement to the project license terms:

• External contributors sign the Microsoft Contributor License Agreement on their first pull request
• The CLA bot automatically verifies agreement status
• Signed agreements authorize contribution under the MIT License

Amending This Document

Changes to this governance document follow the governance changes process:

1. Propose changes via pull request with clear rationale
2. Allow one-week comment period for community input
3. Obtain maintainer consensus
4. Merge and communicate changes to the community

This site is open source. Improve this page.