We welcome contributions to the OpenVINO™ Intel® NPU Compiler project from both Intel employees and the open-source community.
This document provides guidelines to help you make successful contributions and ensure a smooth review and integration process.
If you want to contribute to OpenVINO NPU plugin or have general questions about OpenVINO Toolkit contributions, refer to the OpenVINO Contributing Guide
- Ways to Contribute
- Code Contribution Process
- Pull Request Requirements
- Review Process
- Responsibilities
- Additional Resources
- If you experience unexpected behavior or have ideas for improvement:
- Submit a GitHub issue with a clear description, logs, and steps to reproduce.
- Or join the OpenVINO GitHub Discussions if it's exploratory or architectural.
- For major proposals or POCs, open a Draft Pull Request and mark it as such to initiate discussion without triggering full review flow.
- Start from a Good First Issue or any open item in the issue tracker.
- Follow our Pull Request Process.
The OpenVINO™ Intel® NPU Compiler project inherits its contribution process from the main OpenVINO PR Contributing Guidelines. We recommend familiarizing yourself with them before submitting a PR.
-
Fork the Repository
All contributions must come from forks, not branches in the main repository. This helps streamline CI and maintain stability. -
Create a Draft PR for Early Feedback
- Draft PRs will not auto-assign codeowners.
- Use this to share ideas, work-in-progress or early architecture.
-
Mark as Ready for Review
- Remove "Draft" status
- Apply
READY_FOR_REVIEW
label - Follow PR Requirements
-
Get Review and Approval
- Request reviews from relevant Codeowners
- Address feedback, rebase your branch, and rerun validation
-
Ready for Merge
- Apply
READY_FOR_MERGE
label - Assign to a Maintainer once validation passes and approvals are in place
- Apply
Your PR must:
✅ Target a single purpose (Feature / Bug / Refactor / etc.)
✅ Be tied to a JIRA ticket or GitHub issue with a clear description and acceptance criteria
✅ Include a meaningful title, summary, and platform/classification
✅ Be rebased on the target branch (no merge commits)
✅ Contain logically separated commits with descriptions (avoid "squash-all" style)
✅ Add test coverage for all new or affected behavior
✅ Use proper GitHub labels, milestones, and assignees
✅ Contain validation results, either:
- Automatic CI logs
- Links to manual test runs if auto-checks are not applicable
- Request initial review from subject matter experts
- Make sure all discussions are resolved, especially blocking ones
- PR can only be assigned to a Maintainer once:
- All codeowners have approved
- CI is green or justified in PR comments
- Discussions are closed
- Maintainer performs final review and merge
Note: For large PRs (e.g. refactor, submodule bump), mark it explicitly in the header so maintainers can manage merge conflicts accordingly.
- Own the PR lifecycle from creation to merge
- Rebase, resolve comments, and ensure validation
- Escalate blockers proactively
- Ensure functionality lands in the correct branches
- Provide timely, constructive feedback
- Approve only when confident in change scope and correctness
- Confirm all merge conditions are satisfied
- Avoid conflicts with other recent changes
- Merge only when CI + review criteria are met
💬 Got Questions?
Submit a GitHub issue or start a GitHub Discussion or reach out to the development team through internal channels (for Intel employees).
By contributing to this repository, you agree that your work will be licensed under the terms of the LICENSE.