Governance

This document describes who decides what goes into the Standard, and how that is intended to change.

Current state: maintainer-led

Version 0.x is maintained by PermitZIP. Proposals arrive as pull requests and issues; the maintainers merge them. There is no committee, no vote, and no formal appeal.

This is stated plainly rather than dressed up, because a young standard with an elaborate governance structure and three users is misrepresenting itself. Maintainer-led is the honest description of a specification at this stage.

What that means in practice

• Anyone may propose anything. Open an issue or a pull request. You do not need to ask first.
• Profiles are the easiest contribution to land. They extend the Standard without changing it, and the maintainers defer to domain practitioners on domain content. See profiles/WRITING-A-PROFILE.md.
• Changes to spec/core.md are the hardest. The invariants in Core §9 are the substance of the Standard. Proposals that weaken one need a strong argument, and "it is inconvenient in our meetings" is not one.
• The maintainers can be wrong. If a proposal is rejected and you still believe it is correct, the licence permits you to fork and publish your own version. That is a legitimate outcome, not a hostile one.

Path to a steering group

The intent is to move to a multi-organization steering group at version 1.0. The maintainers do not believe a standard used seriously by several independent firms should be controlled by one of them.

Two conditions should be met before that transition is meaningful:

1. At least three organizations outside PermitZIP have run sessions under the Standard and reported results.
2. At least two profiles have been contributed and are maintained by practitioners outside PermitZIP.

When those conditions are met, the maintainers will publish a proposed structure for comment. Until then, announcing a governance body would be theatre.

If you are running sessions under this Standard, say so by opening an issue. That is the mechanism by which condition 1 becomes visible.

Decision record

Substantive decisions about the Standard — particularly rejections of proposed changes to Core — are recorded in CHANGELOG.md with reasoning. A reader six months from now should be able to find out why something is the way it is without reconstructing it from pull request threads.

Conflicts of interest

PermitZIP builds software that can produce Conformance Level 3 event streams. That is a direct commercial interest in the Standard's adoption, and it is disclosed here rather than buried.

Two commitments follow from it:

1. The Standard will not be shaped to advantage any implementation. Conformance Levels 1 and 2 require no software at all, and that will not change. If a proposed addition to the Standard would only be satisfiable by purchasing something, it does not belong in the Standard.
2. Listing in IMPLEMENTATIONS.md is descriptive, not an endorsement, and is open to any implementation meeting the stated criteria, including competing ones.

If you believe a decision has been shaped by that conflict, say so in an issue. It is a fair question to ask.

Contact

Open an issue on the repository. For matters that cannot be public, the maintainer contact is listed at co-prompting.com.