This document describes how the ARO project is governed.
ARO follows a Benevolent Dictator model. The project maintainer has final say on all decisions, including feature direction, code acceptance, and community matters. This keeps decision-making simple and consistent.
New features and significant changes should go through the formal proposal process:
- Create a proposal document in the
Proposals/directory - Use the format
ARO-XXXX-short-description.md(next available number) - Follow the structure of existing proposals
- Open a PR for discussion
- The maintainer will review and decide on acceptance
For small fixes and improvements, a direct PR with a clear description is fine.
ARO welcomes new maintainers! If you're interested, here's the path:
- Contribute consistently - Submit quality PRs over time
- Understand the vision - Familiarize yourself with the proposals and language design
- Help the community - Answer questions, review PRs, improve documentation
- Express interest - Open an issue or reach out to discuss
There's no fixed timeline or quota. Maintainer status is granted based on trust, alignment with project goals, and demonstrated commitment.
ARO uses Semantic Versioning:
- Major (X.0.0): Breaking changes to the language or runtime
- Minor (0.X.0): New features, backward-compatible
- Patch (0.0.X): Bug fixes and minor improvements
During the 0.x phase, the language is experimental and breaking changes may occur in minor versions.
When features need to be removed:
- Announce - Document the deprecation in release notes
- Warn - Add compiler warnings for deprecated syntax/features
- Grace period - Keep deprecated features for at least one minor version
- Remove - Remove in a subsequent release with clear migration guidance
We aim to minimize breaking changes and provide clear upgrade paths.