For AI agents: this page as Markdown · llms.txt · JSON Schema
#Governance
Who takes part in Rerail, who maintains it, and how decisions are made. For day-to-day contribution, see CONTRIBUTING.md.
Nera Software Inc. develops Rerail under the Apache License 2.0 and holds the copyright (NOTICE). Contribution is gated:
- Anyone can use, fork and redistribute the code, and propose a change from their fork.
- Code lands only through a pull request from a branch here, opened by contributors or the project's automation.
Reviewing the gate covers how the gate is reviewed.
#Roles
Four roles take part, from anyone opening an issue to the maintainers who merge.
| Role | Who | What they do |
|---|---|---|
| Anyone | Anyone | Opens and comments on issues: bugs, rule misfires, feature and integration requests, questions. Proposes changes from a fork, as a pull request or a branch linked from an issue, with no CI (Proposing a change from your fork) |
| Contributor | Nera Software employees, and outsiders the maintainers approve (the list) | Pushes branches here and opens pull requests from them, with CI. Claims good first issue and help wanted issues |
| Automation | Dependabot, and the GitHub Actions release and upstream bump workflows (How contribution works) | Opens dependency update, release and upstream bump pull requests, reviewed and merged like any other |
| Maintainer | Code owners (.github/CODEOWNERS), appointed by Nera Software | Reviews and merges, ports fork proposals, triages issues, agrees the approach for issue-first work, keeps the contributor list, enforces the Code of Conduct |
A fork pull request is a proposal. A maintainer who takes it ports it to a branch here in their own pull request,
credits the author with Co-authored-by:, and closes the original with a link.
#How decisions are made
Nera Software sets policy; maintainers decide within it, in the open.
- Final say. Nera Software sets this policy and appoints maintainers. Within it, maintainers decide by consensus, or by majority if they cannot agree (Disagreement).
- In the open. Decisions on code, rules, packs or docs are recorded, with the reason, in the issue or pull request before anyone acts.
- Everyday changes. A pull request merges when a code owner other than its author approves and CI result
passes. It is squash-merged. The automated reviewer (
reviewer.yml) comments but never approves. - Issue first. For anything Start with an issue lists, a maintainer agrees the approach in the issue before coding. Large changes write a short design there first (Large changes).
- Disagreement. Any maintainer can object with a reason; the change waits while the issue or pull request discusses it. If disagreement persists, a majority decides and the issue records the outcome and why.
- Saying no. A maintainer closes as
wontfixorduplicatewith a one-line reason, linking the original for a duplicate. - Asking again. Dispute a decision on your issue, pull request or contributor request there. A maintainer other than the one who decided answers.
- Releases. Core and packs publish only after one of the
releaseenvironment's required reviewers, all maintainers, approves the run (docs/release.md).
#Who the maintainers are
Nera Software appoints and removes maintainers internally; .github/CODEOWNERS is the public record.
There is no nomination, application or promotion to maintainer, from contributor or otherwise. A pull request to that file adds or removes a maintainer.
#Internal-testing features
Graduating or removing an internal testing feature (in the code, unsupported) needs one approved issue.
- Rerail's product owner at Nera Software proposes it in an issue, with the reason.
- Nera Software's chief product officer approves it there.
- The follow-up pull request links that issue.
#Reviewing the gate
Nera Software reviews the gate at least every six months in a public issue, first by 30 April 2027.
Each review records what it looked at, the outcome and why.
Why the gate exists and what each review checks
The gate ensures every change comes from someone accountable, costly CI runs only on branches here, and review meets the response times. Each review looks at:
- Contributor requests since the last review: how many, how many approved, time to decision.
- Fork proposals: how many ported or declined, time to decision.
- Response times: first response within 5 business days, decision within 10.
#Where to reach the project
Use issues for most things; report security and conduct problems privately.
- Issues: bugs, rule misfires, feature and integration requests, questions, contributor requests, fork changes.
- Security: privately, per SECURITY.md, never in a public issue.
- Conduct: opensource@nera.software, per the Code of Conduct.
#Changing this document
Nera Software decides this policy; a pull request records each change and merges like any other.