Discuss
Start early ideas, architecture, research, governance, and questions in Discussions. File reproducible bugs and concrete proposals through an issue form.
Participation / Conversation-gated contributions
Every pull request begins with a public conversation and a maintainer-approved tracking issue. Approval establishes scope, evidence, risk, and a reviewer before implementation consumes contributor or maintainer time.
Start early ideas, architecture, research, governance, and questions in Discussions. File reproducible bugs and concrete proposals through an issue form.
A maintainer records scope, non-goals, acceptance criteria, risk, AI expectations, owner, reviewer, and expiry on the tracking issue.
Only decision:approved authorizes implementation. Claim the issue, stay within scope, and keep the change small enough to understand.
Link one primary issue, disclose provenance and AI, pass CI and DCO, and obtain the independent human approvals required by risk.
An accepted Discussion becomes a tracking issue. A pull request is allowed only after a maintainer applies decision:approved and confirms an implementation owner and reviewer. Approval permits work; it does not promise merge.
Pull requests without an approved issue may be closed without technical review. The only exception is an authorized confidential security change using exception:private-security.
Issues hold decisions. Pull requests implement decisions.
review:planned.exception:large-pr.AI may assist with code, tests, documentation, analysis, and private review. The contributor remains responsible for every line, claim, source, test, and artifact. They must understand the subsystem, review the complete diff, verify generated analysis against authoritative evidence, and explain the solution in their own words.
Material AI use must be declared in the approval issue and pull request. It receives ai:assisted and is reviewed under the target repository's risk policy; tool use alone does not determine risk. AI cannot be an author, DCO signatory, reviewer, maintainer, or reason to merge.
Do not paste generated responses as conversation with maintainers. Do not send secrets, vulnerabilities, private source, personal data, or confidential artifacts to an unauthorized provider. Do not accuse contributors based on writing style.
Read the AI policyImplement an approved issue, preserve project invariants, and prove success and failure behavior.
Browse Hyphae issuesRun a documented protocol on another environment. Null results and regressions belong in the record.
Review methodsClarify boundaries, operations, security assumptions, accessibility, translations, diagrams, or examples.
Review is a contribution. Examine parsers, persistence, release integrity, public contracts, rights, and ambiguity.
Review standardImprove project charters, role progression, transparent decisions, continuity, and accessible participation.
Governance recordSustained work and sound judgment across code, review, research, operations, and community can lead to explicit authority.
Current rolesSoftware and implementable normative specifications use Apache-2.0. Narrative documentation uses CC BY-SA 4.0. Every commit requires a human DCO 1.1 sign-off. Contributors retain their copyright; the DCO does not assign it.
Security reports and sensitive conduct concerns never belong in public issues. Community support is best effort and no service-level commitment is implied.
Current limitation: the initiative has not yet appointed the independent conduct recipients or second critical-change maintainer required for full public operation. Critical contributions remain blocked until independent review exists.