ECL-1 Working Group

How to join

The working group is open to implementers, assessors, researchers, operators and other interested people. There is no fee, and no membership agreement beyond the contribution terms below. You do not need to join before raising a problem or commenting on a proposal.

1. Introduce yourself through the working-group contact below. Give the name you use, any affiliation you want recorded, your area of interest and the work you would like to contribute.
2. Read the participation and contribution terms. Declare any material interest in a proposal before reviewing it.
3. Choose a proposal, review task or session topic. Comments identify the document, section or requirement concerned and include supporting evidence where possible.

Email is the contact route on this page. The repository also provides the structured participation record: working-group sign-up form (coming soon). An editor records a comment submitted by email with the credit the sender chooses; private security details stay in the security process.

How the working group works, current version (coming soon)

Public working sessions

Public working sessions are open to anyone, including people who have not signed up. Public session dates will be announced here.

Before a session

The chair posts the agenda and joining details at least seven days in advance. Anyone can propose an agenda item, with the question to resolve and the material participants need to read.

During a session

The discussion follows the agenda and records the alternatives, objections and proposed actions. Attendance is not a condition for having a technical objection considered.

After a session

The chair publishes notes within seven days, including actions and their owners. Attendees are named only with their agreement.

Decisions remain open

A conclusion from a session is written into its proposal and stays open for at least seven days before the editors decide. A meeting alone does not approve a change.

No dated session is listed yet. Each session is listed here before it meets.

How decisions are made

Anyone can raise a problem or propose a change through the contribution channels below. The group uses the same process for the maintainer’s proposals and outside contributions:

1. Describe the change. The proposal identifies the problem, affected documents and requirements, proposed resolution and supporting evidence. Non-editorial changes also state compatibility, security and migration effects and the tests needed.
2. Classify and review. The editors assign the change class by its effect. Corrective and additive changes require a second reviewer; behavioral and breaking changes also require compatibility evidence and a reviewer without a conflict. The author cannot supply the only approval.
3. Answer objections. Participants examine the evidence and alternatives. Rough consensus means that each objection is addressed or answered with a reason; it is not a vote and does not require everyone to agree.
4. Record the decision. Before a proposal is merged or closed, its record states the decision, the reason, who decided, the affected versions and any follow-up work. Deferred work keeps a stated reason and target version.
5. Check the result. The change includes the required positive and negative tests, consistent generated files and a change-log entry. If a required review or check is missing, the change waits.

A decision can be appealed to the chair within 30 days, with the decision identifier, the alleged error, supporting evidence and the remedy requested. The chair answers in writing within 30 days. An unresolved appeal can be taken to a public issue within 30 days of that answer; the issue remains open for at least 14 days. Conflicts and participation in the original decision are disclosed.

The maintainer may not overrule a recorded consensus except for a legal or a security reason stated in writing. Embargoed security detail remains private until disclosure is allowed; the reason and disposition still receive a public record.

The change process, current version (coming soon)Appeals, current version (coming soon)The charter, current version (coming soon)

Roles

Maintainer

G-14, Inc. is responsible for source custody, the public website and namespaces, the editors and chair, release authorization and the publication of releases and errata.

Editors

Triage proposals, keep the documents and generated artifacts consistent, arrange the required reviews, and record decisions and their reasons.

Chair

Organizes the public sessions, keeps the agenda and notes, protects the opportunity to comment asynchronously, and hears appeals.

Participants and reviewers

Raise issues, examine evidence, contribute text and tests, and disclose relevant interests. A reviewer’s independence is stated for the specific work reviewed, not inferred from a title.

One person may hold more than one role, but cannot count twice where the process requires two people, an independent reviewer or a separate appeal decision.

Public review

Later minor versions have a public review window of at least 30 days, and later major versions at least 60 days. Each announcement names the exact draft, its tag and manifest digest, the opening and closing dates, and where to send comments. The draft stays frozen during the window.

Every review comment receives a written disposition: accepted, accepted with changes, declined, deferred, out of scope, duplicate, noted or withdrawn. A disposition names the reason and the resulting change or follow-up. Reviews do not close with unanswered comments or unresolved appeals. Errata and patch versions follow the change process.

No review window is open. Each window is announced on this page and in the repository before it opens.

The public review procedure, current version (coming soon)Errata, current version (coming soon)

How a change becomes a release

A decision to accept a proposal is separate from permission to publish a release. The release manager freezes the source, companion versions, dependencies and provenance, then produces the package, manifest, checksums and release notes.

A release reviewer without a conflict rebuilds from the frozen source and compares the manifest and archive digest. The release manager and reviewer both sign the checklist; the maintainer separately records publication authorization. Passing tests alone does not publish a version, and an incomplete required check stays incomplete.

Release notes identify changes, compatibility effects, known limitations and the status of any outside security review. Earlier versions and decision records remain available; a correction, withdrawal or supersession adds a dated record rather than erasing history.

Contributing on GitHub

The contribution process uses issues for problems and proposals, discussions for questions, and pull requests for changes to the text, schemas, tests or verifier. The repository is linked here when available: GitHub repository (coming soon). The working-group contact above accepts participation requests and comments.

Sign-off

Every commit carries a Developer Certificate of Origin sign-off, a line Signed-off-by: with your name and email address, which git commit -s adds. With it you certify that you have the right to submit the work under the project’s licenses.

Licenses

A contribution is made under the license of the part it changes: CC BY 4.0 for text, and Apache-2.0 for code and machine-readable files.

Patents

Contributors make the same commitment on essential patent claims for their contributions that G-14 makes in its patent pledge.

No agreement to sign

There is no contributor license agreement.

Conduct

Everyone taking part follows the current version of the code of conduct (coming soon). Security problems are reported privately, as the current version of the security policy describes. The links on this page to the working group’s papers open their current version on the repository’s main branch; the texts of Version 1.0 are linked at the tag v1.0.

The contributing guide, current version (coming soon)The Developer Certificate of Origin, current version (coming soon)Open issues (coming soon)Discussions (coming soon)

The maintainer’s interests

G-14, Inc. maintains ECL-1 and this site. The governance page lists its interests in the subject.