Pull Request Process
Relevant source files
The following files were used as context for generating this wiki page:
The Pull Request (PR) process in the OpenHWP project is a structured workflow designed to ensure code quality, consistency, and alignment with the project's roadmap. It emphasizes communication before implementation, requiring external contributors to engage in discussions or issues before submitting code. All contributions must adhere to the project's standards for commit messaging, formatting, and automated testing using the Deno toolchain.
Sources: CONTRIBUTING.md:5-43, README.en.md:76-78
Pre-Submission Workflow
Before a Pull Request is opened, especially by external contributors, a collaborative phase must occur. The project explicitly discourages "drive-by" AI-generated PRs and requires that any new feature or bug fix starts as an Issue or a Discussion.
Initiation Channels
| Contribution Type | Target Platform | Description |
|---|---|---|
| Bug Report / Fix | Issue | Used for reporting reproducible bugs or proposing specific fixes. |
| Feature Request | Discussion | Used for ideas, enhancements, or broader project changes. |
| Security Flaw | Private Reporting | Must follow SECURITY.md guidelines via private vulnerability reporting. |
Sources: CONTRIBUTING.md:33-54, SECURITY.md:11-19
The Approval PR
For external contributors, a maintainer will open an "approval PR" based on the initial Issue or Discussion. Once this approval PR is merged, the contributor's PR will remain open for formal review. PRs submitted without this prior approval are automatically closed.
Sources: CONTRIBUTING.md:33-40
Technical Requirements and Validation
Every PR must pass a set of automated checks powered by Deno. These checks ensure that the code is linted, formatted correctly, and does not break existing functionality.
Validation Commands
deno lint: Checks for common errors and code style violations.deno fmt --check: Verifies that the code adheres to the project's formatting standards.deno test: Executes the test suite to ensure logical correctness.
Sources: CONTRIBUTING.md:20-25
Development Sequence
The following diagram illustrates the typical lifecycle of a contribution from local development to the final PR submission.
The workflow ensures that all logic is verified locally before reaching the Continuous Integration (CI) stage.
Sources: CONTRIBUTING.md:10-25, orca.yaml:16-19
Submission Standards
To maintain a clean and navigable project history, PRs must follow specific formatting and metadata standards.
Commit Messaging
The project enforces Conventional Commits. PR titles should follow the pattern type(scope): subject. This is critical because the PR title becomes the squash-merge commit message and is used to generate the changelog automatically.
Common types include:
feat: New features.fix: Bug fixes.docs: Documentation changes.refactor: Code changes that neither fix a bug nor add a feature.test: Adding missing tests or correcting existing ones.
Sources: CONTRIBUTING.md:27-31, CONTRIBUTING.md:43
PR Content Requirements
- Focused Changes: Each PR should be limited to one logical change to simplify the review process.
- Issue Reference: PRs must reference the issue they address (e.g.,
Closes #123). - CI Status: The CI must be green (all checks passing) before a review is requested.
- Code of Conduct: All participants must abide by the Contributor Covenant.
Sources: CONTRIBUTING.md:18-19, CONTRIBUTING.md:41-45, CODE_OF_CONDUCT.md:1-5
Maintainer Responsibilities
Maintainers act as the final gatekeepers for the codebase. Their responsibilities during the PR process include:
- Clarifying and enforcing standards of behavior.
- Reviewing PRs for technical accuracy and alignment with the roadmap (e.g., transition from
rhwpengine todeno desktopshell). - Merging approved PRs and managing versioning via commit history.
This interaction ensures that the "document engine" concerns (rhwp) and "platform shell" concerns remain properly separated as the project matures.
Sources: CONTRIBUTING.md:33-45, CODE_OF_CONDUCT.md:31-38, README.en.md:19-24
Summary
The OpenHWP Pull Request process prioritizes collaboration over volume. By requiring upfront discussion and enforcing strict automated checks via Deno, the project ensures that every merged change is intentional, well-tested, and consistent with the architectural goal of building a thin desktop shell around the rhwp engine.
Sources: CONTRIBUTING.md:47-51, README.en.md:12-17