Proposed governance and license

[amye]

Lightweight governance proposal to make it easier to contribute, Apache 2.0 license
Now a PR, as previously intended!

[ognis1205]

One suggestion from a contributor's perspective regarding the RFC process, noting that the project is still at a very early stage, so this may be premature or something to revisit later as the ecosystem evolves:

As this project grows, it may be helpful to explicitly document:

• The intended responsibility of each RFC-related directory (e.g. /design vs /docs/proposals)
• Which kinds of changes are expected to go where (schemas, registry APIs, etc.)

In addition, for schema-related PRs, it would be helpful to clarify:

• Which schema definition format(s) are considered normative for this project, e.g., CDDL, JSON Schema, protobuf, and how other formats should be treated, e.g., derived, informational, or out of scope.

Without this guidance, contributors may submit equivalent schemas in different formats, which can make reviews harder and risk fragmentation over time.

Finally, for schema-related PRs, it might also be worth considering whether a lightweight issue or PR template could capture a recommended submission structure, for example:

• Motivation / problem statement
• Example instances

Making these expectations explicit would likely improve review consistency and lower the barrier for new contributors, especially for specification-heavy changes.

[amye]

These are good points!
Primarily, I was considering a maintainer structure that lends itself to a contributor structure, whereas I think you're looking for a project structure overall.

That's not wrong, and you're mindful of that by the 'this might be too early'! I think it is worth proposing these separately as a contributor guide, because as this grows, we're likely to see changes in 'how and where to contribute' and less to actual governance documentation.

Governance documentation is meant to describe voting mechanisms and shouldn't shift often (or really ever, in an established project.) Contributor guides are more specific to the project space and defines normative space.

[ognis1205]

Thanks, that distinction makes sense.

I agree this is less about GOVERNANCE.md and more about CONTRIBUTING.md. My intent wasn't to formalize things too early, but to reduce the chance of fragmentation as contributions increase, especially for schema-heavy changes.

I'm aligned that this can be introduced gradually as a contributor guide and refined over time.