This page provides an overview of Dear ImGui's contribution ecosystem, community norms, and the pathways for participating in the project. It covers the high-level structure of how contributions flow through the repository, the roles of Issues vs Discussions, and the expectations around code ownership and quality standards.
For detailed coding standards, commit conventions, and best practices, see Contribution Guidelines. For the specific mechanics of filing issues and submitting pull requests, see Issue and PR Process.
Dear ImGui is an open-source project that relies on community contributions while maintaining a high bar for code quality and maintainability. The project emphasizes that pull requests are requests for the maintainer to review code and take over its long-term maintenance. This philosophy shapes all contribution processes—PRs must be crafted both for end-users and to ease the maintainer's burden of understanding and accepting changes.
The project uses GitHub Issues as a centralized, cross-referenced knowledge database rather than a simple bug tracker. Questions, feature discussions, and bug reports are all welcome as issues, provided they meet basic quality standards.
Sources: docs/CONTRIBUTING.md1-82
Sources: docs/CONTRIBUTING.md26-82 .github/pull_request_template.md1-11
The project distinguishes between GitHub Issues and GitHub Discussions based on whether Dear ImGui is functioning in your application:
| Situation | Use | Rationale |
|---|---|---|
| Cannot BUILD or LINK examples | Discussions | First-time setup problems |
| Cannot BUILD/LINK/RUN Dear ImGui in custom app | Discussions | Integration issues |
| Cannot LOAD a font | Discussions | Basic configuration |
| Dear ImGui shows successfully + previous experience | Issues | All other questions, bugs, features |
This separation keeps Issues focused on substantive technical content that builds the project's knowledge base, while Discussions handle basic troubleshooting that doesn't need long-term archival.
Sources: docs/CONTRIBUTING.md26-38 .github/ISSUE_TEMPLATE/issue_template.yml6-12
The issue template enforces minimum information requirements to prevent incomplete or ambiguous reports. The issue_template.yml defines required fields that cannot be bypassed, while config.yml disables blank issues entirely.
Key expectations:
IM_ASSERT(false); in main().The guidelines acknowledge that experienced users and community members may not need to fulfill every requirement to the letter, but new or anonymous accounts receive higher scrutiny.
Sources: docs/CONTRIBUTING.md39-65 .github/ISSUE_TEMPLATE/issue_template.yml1-93
The template at .github/pull_request_template.md5 emphasizes: Make sure you're using a special branch just for this pull request. In Git, 1 PR = 1 branch. Updates to the branch automatically update the PR, allowing iterative feedback. Maintainers can cherry-pick individual commits if needed.
From docs/CONTRIBUTING.md73:
local_variable, FunctionName(), MemberName// Text Comment, //CodeComment();examples/ may mimic ecosystem styles (e.g., DirectX samples use Microsoft conventions)The PR template at .github/pull_request_template.md7 encourages contributors to run the imgui_test_suite or add new tests. This external test engine validates expected behaviors across configurations. For more on CI/CD integration, see CI/CD Pipeline.
Sources: docs/CONTRIBUTING.md66-75 .github/pull_request_template.md1-11
Dear ImGui does not require signing a separate CLA document. Instead, submitting code constitutes an implicit agreement with the following terms:
| Right Transferred | Explanation |
|---|---|
| Code ownership | Submitted code becomes part of the repository under the Dear ImGui license |
| Work certification | You certify the code is your work and you can give it to the project |
| Transferable rights | All transferable rights granted to maintainer (re-licensing, modification, distribution) |
| Copyright assignment | Copyright is assigned to the project maintainer |
| No copyright edits | Contributors must not modify copyright statements in files |
This model simplifies the contribution process while ensuring the maintainer retains full control over the codebase's future. The maintainer can re-license, modify, or distribute the code in any form without seeking additional permissions.
Sources: docs/CONTRIBUTING.md76-82
The contributing guidelines emphasize a critical reality: "OPEN-SOURCE SOFTWARE LIVES OR DIES BY THE AMOUNT OF ENERGY MAINTAINERS CAN SPARE." From docs/CONTRIBUTING.md45:
WE HAVE LOTS OF STUFF TO DO. THIS IS AN ATTENTION ECONOMY AND MANY LAZY OR MINOR ISSUES ARE HOGGING OUR ATTENTION AND DRAINING ENERGY, TAKING US AWAY FROM MORE IMPORTANT WORK.
This philosophy underlies all contribution standards:
The project explicitly rejects help from users involved in "cheating schemes (e.g. DLL injection) for competitive online multiplayer games" and will block such accounts regardless of question content.
The guidelines reference Help Vampires at docs/CONTRIBUTING.md24 and encourage users to:
ImGui::ShowDemoWindow() to explore functionalitySources: docs/CONTRIBUTING.md11-65
Contributors submitting changes that affect core functionality should run the imgui_test_suite (external test engine) to validate behavioral correctness. The suite is referenced in:
The CI system automatically builds and tests multiple configurations (see CI/CD Pipeline), but local testing catches issues earlier. Test coverage expectations vary by change type:
Sources: .github/pull_request_template.md7
| Type | Entry Point | Required Info | Testing | Merge Criteria |
|---|---|---|---|---|
| Question (first-time) | Discussions | Build environment, error logs | N/A | Resolution posted |
| Bug Report | Issues | Version, backends, MCVE, callstack | Reproducible locally | Fix + regression test |
| Feature Request | Issues | Usage context, goals, mockups | N/A | Maintainer acceptance |
| Bug Fix PR | Pull Request | Branch, context, test coverage | imgui_test_suite | Code review + style |
| Feature PR | Pull Request | Branch, context, screenshots, rationale | Examples/demo integration | Maintainer acceptance + style |
| Backend PR | Pull Request | Platform/renderer details, compatibility | Example builds | Works with existing examples |
Sources: docs/CONTRIBUTING.md1-82 .github/pull_request_template.md1-11 .github/ISSUE_TEMPLATE/issue_template.yml1-93
Refresh this wiki