Contributing

July 6, 2026 ยท View on GitHub

Welcome to HAMi-core!

Before you get started

Code of Conduct

Please make sure to read and observe our Code of Conduct.

Community Expectations

HAMi is a community project driven by its community which strives to promote a healthy, friendly and productive environment.

Contribution Gates

The following rules are enforced on all contributions.

1. Author-understanding gate. If a maintainer asks how a change works and the author cannot explain it, the PR is closed. Repeated cases may result in interaction limits.

2. Hardware validation. Changes affecting device allocation or in-container isolation must be validated on real GPU hardware before submitting. Record in the PR what was tested, the device type, and the driver version.

3. Scope and commit messages. Large AI-generated PRs are not accepted. For AI-assisted contributions, anything beyond a small fix must start as an issue and be split into reviewable commits. Write your own commit messages; AI-generated commit messages are not accepted.

4. Review replies. The reply you post must be written by you and must address the specific point raised. Verbatim or canned AI replies, or replies that do not engage the comment, lead to the PR being closed.

5. Commit trailer hygiene. Do not list AI as a co-author. No assisted-by, co-developed-by, or similar trailers. Disclosure belongs in the PR description only.

6. AI-generated comments. Do not post AI-generated comments in review threads. Remove any filler or redundant AI-generated text before posting. Exceptions apply only when the underlying technical assessment is entirely your own and AI is used solely to assist with language translation or formatting, provided you have fully verified and edited the output.

Getting started

  • Fork the repository on GitHub
  • Make your changes in your forked repository
  • Submit a Pull Request (PR)

Your First Contribution

We will help you contribute in different areas such as filing issues, developing features, fixing critical bugs and getting your work reviewed and merged.

If you have questions about the development process, feel free to file an issue.

Find something to work on

We are always in need of help, whether it's fixing documentation, reporting bugs, or writing code. Look for places where best coding practices aren't followed, code refactoring is needed, or tests are missing. Here's how you can get started.

Find a good first topic

There are multiple repositories within the HAMi organization. Each repository has beginner-friendly issues marked as "good first issues". For example, Project-HAMi/HAMi has help wanted and good first issue labels for issues that should not require deep knowledge of the system. We can help new contributors who wish to work on such issues.

Another good way to contribute is to find documentation improvements, such as fixing missing or broken links. Please see Contributing below for the workflow.

Work on an issue

When you are willing to take on an issue, simply reply to the issue and a maintainer will assign it to you.

File an Issue

While we encourage everyone to contribute code, we also appreciate when someone reports an issue. Issues should be filed under the appropriate HAMi sub-repository.

Example: A HAMi-core issue should be opened in Project-HAMi/HAMi-core.

Please follow the provided submission guidelines when opening an issue.

Contributor Workflow

Please never hesitate to ask questions or submit a pull request.

This is a rough outline of what a contributor's workflow looks like:

  • Create a topic branch from where you want to base the contribution (usually main)
  • Make commits of logical units
  • Push changes in your topic branch to your personal fork of the repository
  • Submit a pull request to Project-HAMi/HAMi-core

Creating Pull Requests

Pull requests are often called simply "PRs". HAMi generally follows the standard GitHub pull request process. To submit a proposed change, please develop the code/fix and add new test cases. Before submitting a pull request, run these local verifications to predict whether continuous integration will pass or fail:

  • Run make build-in-docker

Issue and PR Lifecycle

To keep the project manageable, we apply the following policy to all open issues and pull requests:

  • If a maintainer or contributor leaves a comment or review requesting a response, the author has two weeks to reply.
  • If there is no response within two weeks, the issue or PR will be closed.
  • Closing is not permanent. If the issue is still relevant or the PR is still needed, it can be reopened or submitted again at any time.

This policy helps us keep the backlog focused and avoids letting stale work block active contributors.

Code Review

To make it easier for your PR to receive reviews, consider that reviewers will need you to:

  • Follow good coding guidelines
  • Write good commit messages
  • Break large changes into a logical series of smaller patches which individually make easily understandable changes, and in aggregate solve a broader issue