Welcome to HAMi!

• Contributing
• Before you get started
  • Code of Conduct
  • Community Expectations
  • AI Assistance Notice
  • Contribution Gates
• Getting started
• Your First Contribution
  • Find something to work on
    • Find a good first topic
      • Work on an issue
    • File an Issue
• Contributor Workflow
  • Creating Pull Requests
  • Code Review

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.

AI Assistance Notice

If you are using any kind of AI assistance while contributing to HAMi, this must be disclosed in the pull request, along with the extent to which AI assistance was used (e.g. docs only vs. code generation). If PR responses are being generated by an AI, you must still disclose it. This requires special care: you must fully understand the reviewer's point and critically review any AI-generated text to ensure it is accurate and directly addresses the feedback. Never paste AI output verbatim. Failure to engage thoughtfully with reviews may result in your PR being closed. As a small exception, trivial tab-completion doesn't need to be disclosed, so long as it is limited to single keywords or short phrases.

An example disclosure:

This PR was written primarily by Claude Code.

Or a more detailed disclosure:

I consulted ChatGPT to understand the codebase but the solution was fully authored manually by myself.

Failure to disclose this is first and foremost rude to the human operators on the other end of the pull request, but it also makes it difficult to determine how much scrutiny to apply to the contribution.

In a perfect world, AI assistance would produce equal or higher quality work than any human. That isn't the world we live in today, and in many cases AI-generated code can contain subtle bugs or not adhere to project-specific best practices. I say this despite being a fan of and using them successfully myself (with heavy supervision)!

When using AI assistance, we expect contributors to understand the code that is produced and be able to answer critical questions about it. It isn't a maintainer's job to review a PR so broken that it requires significant rework to be acceptable.

Please be respectful to maintainers and disclose AI assistance.

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. Changes scoped to the scheduler extender may use mock or unit testing instead.

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.

Roadmap issues (e.g., the yearly roadmap tracking issue) list many items in one checklist instead of one task per issue, so an item may already be claimed by a comment even if the issue itself has no assignee. Before starting design or implementation work on a roadmap item, comment on the tracking issue to claim it and wait for maintainer confirmation.

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 issue should be opened in Project-HAMi/HAMi.

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 master)
• 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

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 and pass make verify

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
• Separate cosmetics from functional changes. Cosmetic changes (reindentation, whitespace, comment wording, style fixes) must not be mixed with logic changes in the same commit — split them into their own commit. If the cosmetics are unrelated to the PR's purpose, they belong in a separate PR entirely. This keeps diffs reviewable: reviewers should not have to filter out formatting noise to find what actually changed.