Contributing Guide

We welcome developers to try and contribute to this project. Before contributing, please read the ascend-community code of conduct, complete CLA signing, and understand the contribution workflow for the source repository.

✍️ Signing the Ascend Community Contributor License Agreement (CLA)

You must sign the Ascend Community Contributor License Agreement (CLA) before contributing:

  • Individual contributors: Choose “Sign Individual CLA”, fill in your name and email, then submit your application.

  • Corporations: Choose “Sign Entity CLA”, fill in the corporate information, and submit. The company will then receive a document from the community for signing the entity CLA, follow the instructions in the email to complete the signing.

  • Corporate employees: Choose “Entity Contributor Registration”; after signing you will receive an email with subject “Signing CLA on project of xx”. Contact the Corporation Managers mentioned in the email for approval.

Developer contributions

Common contribution scenarios include:

  • Bug fixes

    If you find a bug and want to fix it, please open an Issue to report and track it.

    You can create a Bug Report Issue to describe the bug, then comment “/assign” or “/assign @yourself” to assign the Issue to yourself.

  • Code contributions

    You can create a Requirement | Feature request Issue to describe a new sample operator and provide your design. Then comment “/assign” or “/assign @yourself” to assign the Issue to yourself.

    For other Issues you browse:

    • If you intend to work on an Issue, leave a comment stating that you will take it.

    • If the Issue has been open for a long time, do a quick check before implementing.

    • If you resolve an Issue you reported, briefly summarize the outcome before closing it.

  • Questions

    If you have questions about using this project or other topics, please open an Issue for discussion.

    You can follow the Question template when creating your Issue.

  • Helping with others’ Issues

    If you have a solution for someone else’s Issue, please share it in the comments to help the community.

    If the Issue requires code changes, you can comment “/assign” or “/assign @yourself” to assign the Issue to yourself and follow up with a fix.

Development guidelines

Code style

This repository follows the LLVM community coding standards and style. See the LLVM Coding Standards. You can use the following tools for style checks:

Submitting a PR

  • Open an Issue on GitCode to propose your idea.

  • If the change involves non-trivial design, submit a design document as well.

  • After the Issue and design (if any) are agreed upon, fork the repo, implement, and open a Pull Request.

  • The PR will be merged, rejected, or closed based on the discussion.

  • Merging requires 2 Reviewers to comment /lgtm (Looks Good To Me) and 1 Approver to comment /approve. The PR author cannot merge their own PR.

Fork–Pull workflow

Before submitting code to AscendNPU-IR, fork the project to your own repository. Develop in your fork and submit a Pull Request to merge your changes into this project.

Self-testing your changes

After making code changes, build and run tests in the build directory to verify:

ninja check-bishengir

Pushing and CI

After your changes pass local tests, push your commits to your remote fork.

Creating a Pull Request to the upstream repo

After pushing to your fork, create a Pull Request from your branch to the AscendNPU-IR master branch. After creating the PR, you can comment compile in the PR to trigger the CI pipeline. We recommend merging your PR into upstream master as soon as it is approved to reduce merge conflicts.

Dealing with CI failures

Common CI failure types and how to address them:

  • Build failure: Check the CI log for the cause, fix the issue, and ensure the project builds locally before pushing again.

  • Static analysis failure: Locate and fix the issues reported by the static checker.

  • CI Pipeline / test failure: Identify the failing tests from the CI output, fix them, and re-trigger CI.

Notes

  • Avoid including changes unrelated to the PR in your commits.

  • Keep commit history clear and logical (squash or rebase when appropriate).

  • Rebase your branch onto the latest upstream master before opening a PR.

  • For bug-fix PRs, reference all related Issues and PRs in the PR description.