Bug Reports & Feature Requests
Relevant source files
The following files were used as context for generating this wiki page:
OpenHWP utilizes a structured approach to community contributions, distinguishing between bugs, feature requests, and security vulnerabilities to ensure efficient project maintenance. The project emphasizes clear communication and high-quality reports to minimize the overhead of review, especially concerning AI-generated content.
Sources: CONTRIBUTING.md:46-62, README.en.md:76-78
Contribution Channels
The project maintains specific channels for different types of feedback. While bugs and fixes are handled via Issues, feature requests and enhancements are initially directed to GitHub Discussions.
| Contribution Type | Platform | Location/Link |
|---|---|---|
| Bug Report | GitHub Issue | New Issue |
| Feature Request | GitHub Discussion | Ideas Category |
| Security Vulnerability | Private Reporting | GitHub Security Tab / security@pleaseai.dev |
Sources: CONTRIBUTING.md:46-55, SECURITY.md:12-21
Triage and Promotion Flow
The project follows a strict policy where external Pull Requests (PRs) must originate from a maintainer-approved Issue or Discussion. Accepted proposals from the community are promoted to formal Issues before implementation begins.
This diagram illustrates the lifecycle from community submission to formal implementation.
Sources: CONTRIBUTING.md:33-44, CONTRIBUTING.md:57-60
Bug Reporting Process
Bug reports must provide the "full context" to allow maintainers to guide the work. For technical bugs, the project provides templates to ensure all necessary data is captured.
Standard Bug Report Structure
A valid bug report typically includes:
- A clear and concise description of the bug.
- Steps to reproduce the behavior.
- The expected behavior versus the actual behavior observed.
- Screenshots or log outputs if applicable.
- Environment details (OS, Deno version).
Sources: CONTRIBUTING.md:57-60, .github/ISSUE_TEMPLATE/bug_report.md
Feature Request Lifecycle
Feature requests are treated as collaborative discussions. The project prioritizes "well-framed problems" over finished code, as deciding what and how to build is a shared responsibility between contributors and maintainers.
- Submission: User posts a proposal in the "Ideas" category of GitHub Discussions.
- Deliberation: Maintainers and the community discuss the use case and technical feasibility.
- Promotion: If accepted, the maintainers promote the discussion to a formal Issue.
- Implementation: Development begins, referencing the promoted Issue.
Sources: CONTRIBUTING.md:46-55, CONTRIBUTING.md:57-60
Security Vulnerability Handling
Security concerns are strictly separated from public bugs and feature requests. Publicly disclosing vulnerabilities via Issues or PRs is prohibited.
This sequence shows the private communication path for security-sensitive reports.
Sources: SECURITY.md:12-32
Standards and Enforcement
All bug reports and feature requests must comply with the Contributor Covenant Code of Conduct. Community leaders have the authority to edit or reject issues and comments that do not align with these standards.
- Inappropriate Behavior: Trolling, personal attacks, or harassment in issue comments.
- Enforcement: Consequences range from private warnings to permanent bans from the repository.
Sources: CODE_OF_CONDUCT.md:12-40, CODE_OF_CONDUCT.md:54-94
Summary
OpenHWP manages project growth through a tiered feedback system. By requiring initial discussions for features and private reporting for security, the project maintains a stable development environment. Technical bug reporting is standardized through GitHub Issues, ensuring that all necessary context is provided for maintainers to effectively address regressions or errors in the HWP/HWPX engine and desktop shell.