# Contributing to ACES

**Policy version 1.0. Effective 5 November 2026.**

Anyone may read the specification, ask questions and propose improvements. Consortium membership, a purchase or a fee is not required. A published or merged working draft is not an Approved Specification or a product certification.

## Acceptance

Read [LICENSE.md](LICENSE.md), [Scope.md](Scope.md), [CONTRIBUTOR-AGREEMENT.md](CONTRIBUTOR-AGREEMENT.md), [LICENSING.md](LICENSING.md) and [Governance.md](Governance.md) before submitting material for inclusion.

**Members:** the contributor agreement is accepted through membership. Identify the member and authorized contributor in the submission; reference the existing membership record. No separate signature or repeated agreement is required for every contribution.

**Non-members:** accept the contributor agreement through the submission statement in that document or another explicit electronic affirmation. Identify the actual Contributor and any represented entity. A personal account can act for an organization, but the person must have the authority required by CSL.

CSL contains copyright grants, patent commitments, exclusion rights and authority representations, including its definitions of Contributor and Affiliate. Do not submit another party's material without sufficient permission or represent an organization without authority.

## Initial material

Reuven Farchi's acceptance and authorization for the original ACES technical material and designated code examples are recorded in [Notices.md](Notices.md). The initial release does not require another adoption decision or a new signature for that material. Future substantive contributions are recorded when received.

## Submission paths

Use a pull request in the designated project repository where access is available, or send proposals to **info@aces-consortium.org**. The coordinator can arrange repository access or record an authorized submission. A private source repository does not prevent public access to the released specification and legal framework.

Identify whether a message is a contribution offered for incorporation or a question only. Substantive proposals from meetings, email, issues or website forms follow the same contributor and provenance rules as pull requests. Do not incorporate a non-member's material from a question-only discussion without obtaining acceptance.

Formal patent exclusions, withdrawals and repository-based implementer acceptances follow the specific pull request or commit routes in CSL and `Notices.md`. Email can arrange access and alert maintainers; it does not replace a required repository action. Access for a timely legal notice must be facilitated promptly.

## Submission contents

Explain the problem, the proposed change, the affected clauses and the reasons. Identify technical behavior changes, compatibility or safety implications, and third-party sources and licenses. Include examples or tests where appropriate. Clearly label any source-code material and its license.

Do not submit confidential information. Identify known IP concerns relevant to the proposal and use the formal process for any patent exclusion. Do not state that a technology is patent-free without an adequate basis.

## Maintainer review

- Verify the applicable membership or non-member acceptance record, represented party and contribution authority. A current member does not need a duplicate agreement; resolve any actual authority or third-party provenance concern before merging the affected material.
- Review the technical impact, Scope, attribution and code/specification license boundaries. Preserve the original submission and record the date it enters the draft.
- Record applicable patent notices and exclusion periods, including submitted but unmerged notices. A merge is not a waiver of a CSL notice right.
- Apply the approval gates in `Governance.md` only when designating an Approved Specification. Public working-draft releases may precede that technical approval and must identify their actual status.

The pull-request template assists human review; it does not install automated CLA checks or branch protection.

## Conduct and competition

Keep discussion technical and respectful. Do not harass participants or publish unnecessary personal information. Send conduct concerns to the coordination address; request review by an uninvolved participant when a maintainer is involved.

Follow CSL Section 6. Do not use consortium discussions to coordinate prices, divide markets, allocate customers or discuss other prohibited competitor conduct. Independent development, competing products and reasoned technical disagreement remain permitted.