How YOU can contribute!

A guide to contributing to the Open Media Streaming Foundation.

OMSS is built in public, and contributions are welcome across the specification, implementations, SDK, documentation, and community tooling. You do not need to start with a large feature: a clear issue, a documentation correction, or a focused review can make the project better.

Choose where to help

• Specification: propose endpoint, schema, behavior, or compliance changes in omss-spec.
• Backend tooling: improve OMSS Core, the runtime and plugin orchestrator for OMSS-compliant services.
• Frontend tooling: improve the OMSS SDK, including its client API, types, and examples.
• Starter experience: improve the backend template so new implementations are easier to create.
• Documentation: improve the Mintlify documentation repository, guides, examples, and API explanations.

Before you start

1. Search existing issues, pull requests, and discussions so your work does not duplicate an existing proposal.
2. Read the repository’s CONTRIBUTING.md, CODE_OF_CONDUCT.md, and security policy when they are present.
3. For a specification change, explain the interoperability problem first. Include the proposed behavior, affected schemas or endpoints, compatibility considerations, and an example request or response where useful.
4. For an implementation change, identify the relevant version of the specification and include tests or a reproducible example.

Submit a change

Make sure you have first discussed your change in an issue, discussion, or design document. Then follow the repository’s contribution workflow:

1. Fork the relevant repository and create a focused branch from its default branch.
2. Make the smallest coherent change. Keep unrelated formatting or refactoring out of the same pull request.
3. Run the repository’s formatting, linting, type-checking, and test commands before opening a pull request.
4. Update documentation, schemas, examples, or changelogs when the behavior they describe changes.
5. Open a pull request with a concise title and a description that explains the motivation, implementation, testing, and compatibility impact.
6. Respond to review feedback and keep the branch focused until the change is ready to merge.

Do not include credentials, private URLs, copyrighted provider data, or other sensitive material in issues, pull requests, examples, or logs.

Specification proposals

Changes to the standard affect every compliant client and backend, so they need especially clear reasoning. When proposing a new capability, describe why existing endpoints or fields are insufficient, define the normative behavior, consider versioning and backward compatibility, and provide machine-readable schema or OpenAPI updates when applicable.

Use the project’s issue templates for bug reports, feature requests, and specification clarifications. Discussions are also useful for exploring an idea before turning it into a concrete proposal.

Security reports

Do not publish an unpatched vulnerability or secret in a public issue. Follow the repository’s security policy and responsible disclosure instructions instead. If you are unsure whether a report is security-sensitive, treat it as private and ask the maintainers for the correct reporting channel.

Documentation contributions

Documentation changes should be accurate, task-oriented, and consistent with the current specification. Prefer short examples that can be verified against the API, link to the canonical repository or schema, and state version-specific behavior when a feature is not available in every OMSS release.

Thank you for helping make media backends easier to implement and easier to consume.