Skip to content

Contributing and Collaboration Policy

HybridOps welcomes technical corrections, reproducible failure cases, tests, implementation improvements and documentation feedback.

Public contribution and review discussion is coordinated through the open project repositories, with HybridOps.Core issues as the main entry point for runtime, documentation and technical-review feedback.

Documentation and public guidance

Corrections to public documentation are welcome, including:

  • broken or stale links
  • missing operating steps
  • inaccurate capability or lifecycle descriptions
  • unclear ownership or authority boundaries
  • examples that no longer match the implementation
  • reproducible counterexamples or failure cases
  • evidence that a documented path behaves differently in practice

Open a HybridOps.Core issue and include the public page link, the correction or observed behaviour, and any supporting evidence that can be shared safely. Suggested replacement wording is welcome but a pull request is not required.

HybridOps.Core

Use Core issues for defects, usability feedback, feature requests and technical review.

Focused pull requests are welcome when they follow the Core contribution guide, keep contracts reusable and include the checks appropriate to the change. Where a change requires real-environment acceptance, use the installable candidate produced by CI so the exercised artifact matches the proposed implementation.

Normal users should install tagged releases through the Quickstart.

HybridOps.Workloads

Issues and focused pull requests are welcome for reusable, environment-neutral desired-state changes.

Useful issue detail

A useful report normally includes:

  • a short problem or proposed correction
  • the affected command, page or capability
  • steps to reproduce where applicable
  • expected and observed behaviour
  • relevant versions and environment assumptions
  • logs, screenshots or run records with secrets removed

A short practitioner correction can still be useful when a full reproduction is not available.

Documentation quality

Public documentation should:

  • be factual and current
  • be specific enough to operate from
  • state capability and ownership boundaries directly
  • distinguish implementation, verification evidence and future evidence requirements
  • retain meaningful failure conditions and release gates
  • avoid filler, promotional language and unnecessary implementation-stack detail

Name a provider, platform, protocol or implementation technology when the reader needs that identity to operate, troubleshoot or reproduce the documented behaviour. Otherwise describe the capability and outcome directly.

Reuse and forks

Licensing is defined by each public repository. See its licence and notice files where present. Public components may be forked and adapted under the applicable terms. MIT-0 code requires no attribution; CC BY 4.0 documentation does.

Security

Do not disclose vulnerabilities publicly. Follow the security policy for responsible reporting.

Commercial engagement

For implementation support, reviews or delivery programmes, see the contracting and capability statement.