diff --git a/.github/ISSUE_TEMPLATE/bug_report.yml b/.github/ISSUE_TEMPLATE/bug_report.yml index 6d45432d50..74d00712a3 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.yml +++ b/.github/ISSUE_TEMPLATE/bug_report.yml @@ -1,24 +1,22 @@ name: Bug Report description: Report a bug in DimOS -labels: ["bug"] +type: Bug body: - type: textarea id: description attributes: label: Description + description: Describe what happened and include any details that seem relevant. value: | - ## System - + ## What happened? - ## Robot/Sim/Hardware (including firmware version) - + ## What did you expect? ## Steps to reproduce - ## DimOS version - + ## Environment + ## Logs / screenshots - validations: - required: true + required: false diff --git a/.github/ISSUE_TEMPLATE/feature_request.yml b/.github/ISSUE_TEMPLATE/feature_request.yml index 9a1c6ed03f..db3d88d7d3 100644 --- a/.github/ISSUE_TEMPLATE/feature_request.yml +++ b/.github/ISSUE_TEMPLATE/feature_request.yml @@ -3,10 +3,27 @@ description: Suggest a new feature or improvement for DimOS labels: ["feature"] body: - type: textarea - id: description + id: motivation attributes: - label: Description + label: Problem or motivation description: What do you want and why? - validations: required: true + - type: textarea + id: request-or-plan + attributes: + label: Request or implementation plan + description: If this is a request, describe the desired behavior. If you plan to implement it, describe your proposed approach. + validations: + required: false + - type: dropdown + id: contribution-intent + attributes: + label: How would you like to help? + options: + - "I can implement this" + - "I can test or review this" + - "Request only" + - "Not sure yet" + validations: + required: false diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 61ffabc38d..0aefbe1c69 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -1,21 +1,30 @@ +## Contribution path + + + +- [ ] Small, safe change that does not need a tracking issue +- [ ] Linked issue/discussion: DIM-XXX / #XXX / URL + ## Problem - - + -Closes DIM-XXX +Closes # ## Solution - - - + ## How to Test - - + -## Contributor License Agreement +## Checklist +- [ ] I followed the contribution path above. +- [ ] This PR is scoped to one issue or clearly stated problem. +- [ ] I have run the relevant checks for the files I changed. +- [ ] I have reviewed and understand the changes in this PR. +- [ ] I disclosed AI assistance if it materially helped prepare this PR. - [ ] I have read and approved the [CLA](https://github.com/dimensionalOS/dimos/blob/main/CLA.md). diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000000..74199545e9 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,53 @@ +# Contributing to DimOS + +DimOS welcomes community contributions. This guide explains how to start work, communicate scope, and submit a pull request that maintainers can review efficiently. + +## Before you code + +Choose the path that keeps discussion focused: + +- Small, safe changes can go straight to a pull request. +- Non-trivial changes should start with a GitHub issue before implementation. +- If you already have a draft pull request for a non-trivial change, open or link an issue for the design discussion and keep the PR focused on the implementation. +- Core architecture changes should start with a GitHub issue or discussion before implementation. + +New contributors can start with issues labeled `good first issue`. + +Core architecture includes modules, streams, transports, blueprints, agents, public APIs, robot/platform support, and major dependency changes. + +## Pull requests + +Before opening a pull request, make sure it is: + +- scoped to one issue or clearly stated problem +- linked to the relevant issue or discussion, unless it is a small, safe change +- focused, without unrelated cleanup or formatting changes +- clear about what changed and why +- validated with the checks relevant to the files you changed + +The pull request template asks for the details maintainers need. Keep deeper design discussion in the issue or discussion that the PR links to, not in the PR thread. + +## Validation + +Run the relevant local checks before submitting. Pre-commit and CI will also guide you toward the required checks for the files you changed. + +For test guidance, see [docs/development/testing.md](docs/development/testing.md). + +## AI-assisted contributions + +AI-assisted contributions are welcome when the human contributor owns the result. + +If AI materially helped prepare a pull request, disclose that in the PR. You are responsible for understanding the change, checking it against the agreed scope, and running relevant validation. + +If you use an AI coding agent, review its work before submitting. Do not submit an agent-generated PR that you cannot explain yourself. If the PR is not ready for human review, keep it as a draft. + +Before submitting, make sure you can explain in your own words: + +- what changed and why +- which issue or discussion scope the PR follows +- what checks you ran and the results +- any risks, assumptions, or follow-up work + +## Contributor License Agreement + +Before submitting a pull request, read and approve the [Contributor License Agreement](CLA.md).