Governance, ownership, participation, and collaboration for the ARCORIS ecosystem.
Core Platform · Docs · Handbook · Enhancements · Examples
Governance · Ownership · Participation · Communication · Meetings · Working Bodies · Templates
Overview: Purpose · Start here · Intended audiences
Scope: What belongs here · What does not belong here · Source of truth
Structure: Repository map · Community map · Community principles
Repository: Contributing · Repository status
This repository is the community and governance repository for ARCORIS.
It exists to define how participation, ownership, working bodies, community communication, and project governance are structured across the ecosystem.
This repository is not public product documentation and it is not an engineering policy repository. It is the canonical home for governance rules, ownership structures, participation paths, meeting records, community bodies, and collaboration templates.
Use the Community Index as the primary entry point for community navigation, reading order, and section-based access paths.
The index defines how the community repository should be explored across overview, governance, bodies, ownership, participation, communication, meetings, and templates.
Use this repository for material that defines how people participate in and coordinate around ARCORIS.
Typical content includes:
- governance model, amendment rules, conflict resolution, and decision-making process;
- codes of conduct, escalation paths, appeals, and community boundaries;
- steering committees, working groups, response teams, and other chartered bodies;
- ownership model, maintainership lifecycle, delegation rules, and area responsibility mapping;
- contributor onboarding, roles, participation paths, and recognition structures;
- communication channels, support boundaries, office hours, and response expectations;
- meeting types, calendars, notes standards, decision-log policy, and archived records;
- reusable templates for charters, ownership profiles, role pages, announcements, and working groups.
This repository must not absorb responsibilities that belong elsewhere.
The following should live outside this repository:
- canonical public system explanation, architecture narratives, and user-facing platform guidance;
- engineering and documentation operating rules, standards, and quality gates;
- major technical proposals, decision history for accepted changes, and enhancement lifecycle tracking;
- runnable examples, environment baselines, demos, and scenario material;
- implementation-near technical documentation that belongs next to source code.
If a topic defines who participates, who owns what, how groups operate, or how the project coordinates itself, it belongs here. If it explains the platform, governs engineering workflow, tracks major technical change, or documents runtime behavior, it should remain in the repository that owns that responsibility.
ARCORIS uses multiple repositories with different responsibilities. This repository is only one layer of that system.
| Repository | Role |
|---|---|
| Core Platform | Main code repository for the platform |
| Repository | Role |
|---|---|
| Docs | Public documentation and canonical system explanation |
| Handbook | Engineering and documentation operating rules |
| Community (this repository) | Governance, ownership, participation, and collaboration |
| Enhancements | Major proposals, accepted changes, and decision history |
| Examples | Runnable examples, baselines, demos, and scenario material |
This repository should define how the ecosystem is governed and coordinated without taking over the stable responsibilities of the repositories that own system explanation, operating rules, change records, examples, or implementation detail.
The repository is organized around a small set of durable, reader-facing entry points.
| Section | Role |
|---|---|
| Overview | Mission, scope, glossary, participation model, repository boundaries, and community mapping |
| Governance | Governance model, decision-making, amendment process, conflict resolution, escalation, and code of conduct |
| Bodies | Steering committees, response teams, code-of-conduct bodies, and working groups |
| Ownership | Ownership model, delegation, maintainership lifecycle, area map, and area-level responsibility pages |
| Participation | Contributor journey, onboarding, community roles, and recognition |
| Communication | Channels, office hours, announcements, response expectations, and support boundaries |
| Meetings | Meeting types, calendars, notes standards, records, templates, and decision-log rules |
| Templates | Reusable templates for charters, area profiles, roles, announcements, and working groups |
| Community Index | Primary entry point into the full community documentation set |
Detailed navigation and reading order should be defined in the Community Index and in the section index pages themselves, not in this root README.
This repository serves several audiences:
- contributors who need to understand how to join, participate, and grow in the project;
- maintainers and area owners who need clear ownership, delegation, and escalation structures;
- working group and committee members who need charters, responsibilities, membership rules, and operating boundaries;
- reviewers, approvers, and release participants who need clarity about roles and coordination expectations;
- future community stewards who need a durable governance and ownership record rather than undocumented practice.
Because these audiences differ, the repository should optimize for clarity, accountability, discoverability, and boundary discipline.
This repository should hold the canonical explanation of the community operating model for ARCORIS.
That means:
- governance rules should be documented here;
- ownership and maintainership structures should live here;
- roles, participation paths, and collaboration expectations should be defined here;
- meeting standards, body charters, and recurring community records should remain discoverable here.
If a topic exists in multiple forms, the boundary is simple:
- governance rule, ownership structure, participation path, role definition, body charter, or meeting record -> Community
- stable public system explanation -> Docs
- operating rules, writing policy, review discipline, and engineering standards -> Handbook
- major proposal, accepted technical decision, or change history -> Enhancements
- runnable and demonstrative material -> Examples
- implementation-near technical detail -> Core Platform
A community rule may influence engineering work, but it should not replace the engineering and documentation operating rules that belong in the handbook.
Material in this repository should follow a small set of strict principles:
- Governance must be explicit. Ownership, authority, escalation, and amendment paths should not remain implicit.
- Participation must be legible. New contributors should be able to understand how to enter, contribute, and grow.
- Bodies need clear boundaries. Committees, teams, and working groups should have explicit charters, responsibilities, and membership rules.
- Ownership must be traceable. Areas, contacts, and delegated responsibilities should remain easy to find.
- Meeting records must stay useful. Calendars, templates, notes, and decision logs should support continuity rather than create noise.
- Repository boundaries must hold. Community material should not become a substitute for Docs, Handbook, Enhancements, Examples, or code-near documentation.
- Docs-as-code rigor. Governance and participation material should be reviewable, versioned, and maintainable like source code.
A good change in this repository usually does one or more of the following:
- clarifies a governance rule, role, boundary, or escalation path;
- improves the usability of contributor onboarding and participation material;
- keeps ownership, area contacts, and maintainership information accurate;
- strengthens charters, body responsibilities, and coordination structures;
- improves meeting discipline through better standards, templates, or records;
- removes ambiguity, duplication, stale ownership information, or undocumented practice.
Changes should not move stable product documentation, engineering policy, proposal history, runnable examples, or implementation-near technical documentation into this repository.
This repository already reflects the core domains of community responsibility: governance, bodies, ownership, participation, communication, meetings, and reusable templates.
The current structure also supports a strong split between reader-facing guidance under docs/ and more specific section-level records beneath those entry points, including body pages, area pages, role pages, and meeting records.
As the repository evolves, section index pages, charters, area maps, role definitions, and meeting records should continue to reinforce this repository’s role as the canonical home for ARCORIS community structure and coordination.