Contribute to Helium

Last updated: July 30, 2026

Helium accepts contributions to both the framework and its documentation. The two areas use related docs-as-code and review practices, but they have different source repositories, validation requirements, and ownership boundaries.

Choose a contribution path

Contribute to the documentation

Use the documentation contribution path when you want to:

• correct or add consumer-facing guidance;
• improve navigation or learning paths;
• add or update code samples;
• maintain manual or generated reference content;
• change DocFX, the site theme, validation, preview, or publication behavior.

Start with:

• Documentation architecture to understand where content belongs;
• Authoring conventions to write and structure pages;
• TOC conventions to change navigation;
• Metadata reference to apply front matter;
• Issue and pull-request workflow to prepare a contribution.

Then use:

• Build the documentation locally;
• Validate links and cross-references;
• Preview environments;
• Publication process.

Contribute to the framework

Use the framework contribution path when you want to change runtime behavior, public contracts, packages, migrations, tests, build policy, or release artifacts.

Start with:

• Build Helium from source;
• Run repository validation;
• Coding and namespace conventions;
• Architecture Decision Records;
• Public API compatibility policy;
• Testing policy;
• Packaging and versioning;
• Release process.

A framework change that affects consumers normally requires a linked documentation issue or pull request. See Issue and pull-request workflow.

Repository responsibilities

Repository	Primary responsibility
strombetta/helium	Framework behavior, public contracts, packages, migrations, tests, and release artifacts.
strombetta/helium-docs	Consumer documentation, navigation, learning paths, reference presentation, validation, and publication.

Keep cross-repository changes linked in both directions. A stable framework feature is not release-ready until its required consumer documentation is complete.

Contribution expectations

Every contribution should:

• solve a specific developer, operator, or contributor problem;
• remain within the approved product and documentation architecture;
• include appropriate technical and editorial review;
• pass repository validation;
• preserve compatibility and published URLs where applicable;
• avoid exposing secrets, customer information, or embargoed security details.

Report a problem

Use a GitHub issue when you identify incorrect or missing documentation, a broken example, a navigation problem, or a release and compatibility gap. Include the affected page, applicable version, expected information, and sanitized evidence.

See Issue and pull-request workflow for the required details and review process.