We are enthusiastic about contributions to our code and documentation.
The project is still in its early days, so please feel free to file issues where documentation or functionality is lacking or even better volunteer to help contribute to help close these gaps!
Tip
For contribution guidelines to other parts of ROCm outside of TheRock, please see ROCm/CONTRIBUTING.md.
This is currently covered by the ROCm Project Governance, which also defines the code of conduct.
TheRock is focused on making it easy for developers to contribute. In order to facilitate this, the source of truth for all issue tracking, project planning, and code contributions are in GitHub and we leverage an open source stack for all development tools and infrastructure so that it they can be easily leveraged in any fork.
We are also active on the AMD Developer Community Discord Server
in channels like #therock-contributors and #rocm-build-install-help.
Before filing a new issue, please search through existing issues to make sure your issue hasn't already been reported.
General issue guidelines:
- Use your best judgement for issue creation. If your issue is already listed, upvote the issue and comment or post to provide additional details, such as how you reproduced this issue.
- If you're not sure if your issue is the same, err on the side of caution and file your issue. You can add a comment to include the issue number (and link) for the similar issue. If we evaluate your issue as being the same as the existing issue, we'll close the duplicate.
- When filing an issue, be sure to provide as much information as possible, including script output so we can collect information about your configuration. This helps reduce the time required to reproduce your issue.
- Check your issue regularly, as we may require additional information to successfully reproduce the issue.
Discussion about new features is welcome via
- Filing a GitHub issue
- Reaching out on Discord
- Posting a GitHub discussion (discussions are not as active)
When you create a pull request, you should target the main branch.
- Identify the issue you want to fix
- Target the main branch
- Ensure your code has all workflows pass
- Submit your PR and work with the reviewer or maintainer to get your PR approved
- If you don't know who to add to a PR as a maintainer, please review the git history to see recently approved PRs in the same file or folder.
Important
By creating a PR, you agree to allow your contribution to be licensed under the terms of the LICENSE file.
We use pre-commit to run automated "hooks" like lint
checks and formatters on each commit. See the list of hooks we currently
run at .pre-commit-config.yaml. Contributors are
encouraged to download pre-commit and run it on their commits before sending
pull requests for review.
Tip
The pre-commit tool can also be "installed" as a git hook to run automatically
on every git commit.
For example:
# Download (note: this is already included in requirements.txt).
pip install pre-commit
# Run locally on staged files.
pre-commit run
# Run locally on all files.
pre-commit run --all-files
# Install git hook.
pre-commit installIf creating a branch in the shared repository (and not a fork), prefer to choose a branch name following one of these patterns:
users/[USERNAME]/[feature-or-bug-name]shared/[feature-or-bug-name]
These naming schemes allow for long-lived branches to be more easily sorted and possibly cleaned up by repository maintainers.
List of long-lived branches:
Tip
Most developer workflows are compatible with pull requests coming from forks. Some good reasons to create branches in the shared repository are:
- Collaborating on changes on a shared branch
- Stacking a series of pull requests by setting the base branches for each PR
- Triggering custom workflows such as "dev" release builds using workflow_dispatch and running on our self-hosted GitHub Actions runners
We have project-wide style guides with recommendations to follow at
docs/development/style_guides/: