diff --git a/.github/ISSUE_TEMPLATE/bug_fix.yml b/.github/ISSUE_TEMPLATE/bug_fix.yml deleted file mode 100644 index 94ea882..0000000 --- a/.github/ISSUE_TEMPLATE/bug_fix.yml +++ /dev/null @@ -1,112 +0,0 @@ -name: Bug Fix -description: Track implementation of a bug fix with detailed planning and requirements -title: "[Bug Fix]: " -labels: ["bug"] -assignees: [] -body: - - type: markdown - attributes: - value: | - Thanks for taking the time to plan and track a bug fix! Please fill out the following sections to document the implementation approach, requirements, and supporting details. - - - type: input - id: overview - attributes: - label: Overview - description: Detailed description of the bug including purpose and intent as well as intended use cases - placeholder: Enter a clear and concise description of what the bug is - validations: - required: true - - - type: textarea - id: definition-of-terms - attributes: - label: Definition of Terms - description: Detailed table of terms not considered 'common English' related to this bug - placeholder: | - | Term | Meaning | Reference | - | ---- | ------- | --------- | - | | | | - render: markdown - validations: - required: false - - - type: textarea - id: architectural-considerations - attributes: - label: Architectural Considerations and Constraints - description: Detailed model of the bug's architectural consideration and flow of data within the system - placeholder: | - - Include constraints such as performance considerations or affected components - - Include ASCII-art or mermaid diagrams where appropriate - - Include KaTeX math where relevant, with plain-English explanations - render: markdown - validations: - required: false - - - type: textarea - id: implementation-guide - attributes: - label: Implementation Guide - description: Detailed step-by-step implementation guide for fixing this bug, including code snippets, unit tests and benchmarks - placeholder: | - If requested, write steps to follow Test Driven Development principles, leading with a minimal breaking test, followed by a minimal change to fix the test, followed by refactor, repeating until the fix is complete. - - If the fix is extensive and complex, create multiple subsections to make these steps more legible. - render: markdown - validations: - required: false - - - type: textarea - id: plan-requirements - attributes: - label: Plan Requirements - description: Detailed description of the fix and its requirements - placeholder: | - A list of plan-level requirements in Given/When/Then syntax. - - If a fix is considered complete then indicate with a ***COMPLETE*** prefix. - - ```markdown - - (***requirement status***) Requirement descriptive text - - GIVEN a precondition - - WHEN an event happens - - THEN an action is taken / a result property is true - - > Details of missing implementation / link to phase with missing implementation - ``` - render: markdown - validations: - required: false - - - type: textarea - id: related-plan-docs - attributes: - label: Related Plan Documentation - description: Link to related plan documentation files in the repository - placeholder: | - If this issue is part of a larger plan, link to the related documentation: - - - Parent plan: `docs/plans/.md` - Overall plan this issue is part of - - Related plans: `docs/plans/.md` - Related work or dependent plans - - For complex fixes, corresponding detailed documentation may exist in: - - `docs/plans//` - Folder containing detailed planning documents - - `docs/plans//.md` - Specific topic documentation - - Reference the existing plan structure when linking related documentation. - render: markdown - validations: - required: false - - - type: textarea - id: references - attributes: - label: References - description: A list of links to external resources such as library documentation or articles about relevant techniques - placeholder: | - - Link 1 - - Link 2 - render: markdown - validations: - required: false diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml deleted file mode 100644 index a48dc38..0000000 --- a/.github/ISSUE_TEMPLATE/config.yml +++ /dev/null @@ -1,8 +0,0 @@ -blank_issues_enabled: false -contact_links: - - name: GameEngineAdapter Documentation - url: https://github.com/JohnLudlow/GameEngineAdapter/blob/main/README.md - about: Please check the documentation for questions about how to use the library. - - name: Discussion Forum - url: https://github.com/JohnLudlow/GameEngineAdapter/discussions - about: Ask and answer questions about the GameEngineAdapter. \ No newline at end of file diff --git a/.github/ISSUE_TEMPLATE/epic.yml b/.github/ISSUE_TEMPLATE/epic.yml deleted file mode 100644 index d4df4c7..0000000 --- a/.github/ISSUE_TEMPLATE/epic.yml +++ /dev/null @@ -1,135 +0,0 @@ -name: Epic/Parent Issue -description: Track a large feature or body of work that will be broken down into multiple child issues -title: "[Epic]: " -labels: ["epic"] -assignees: [] -body: - - type: markdown - attributes: - value: | - Thanks for proposing a large body of work! Please fill out the following sections to help us understand and track this epic. - - - type: input - id: overview - attributes: - label: Overview - description: Detailed description of the epic including purpose and intent as well as intended use cases - placeholder: Enter a clear and concise description of what this epic encompasses - validations: - required: true - - - type: textarea - id: definition-of-terms - attributes: - label: Definition of Terms - description: Detailed table of terms not considered 'common English' related to this epic - placeholder: | - | Term | Meaning | Reference | - | ---- | ------- | --------- | - | | | | - render: markdown - validations: - required: false - - - type: textarea - id: architectural-considerations - attributes: - label: Architectural Considerations and Constraints - description: Detailed model of the epic's architectural consideration and flow of data within the system - placeholder: | - - Include constraints such as performance considerations or affected components - - Include ASCII-art or mermaid diagrams where appropriate - - Include KaTeX math where relevant, with plain-English explanations - render: markdown - validations: - required: false - - - type: textarea - id: implementation-guide - attributes: - label: Implementation Guide - description: Detailed step-by-step implementation guide for this epic, including code snippets, unit tests and benchmarks - placeholder: | - If requested, write steps to follow Test Driven Development principles, leading with a minimal breaking test, followed by a minimal change to fix the test, followed by refactor, repeating until the epic is complete. - - If the epic is extensive and complex, create multiple subsections to make these steps more legible. - render: markdown - validations: - required: false - - - type: textarea - id: epic-requirements - attributes: - label: Epic Requirements - description: Detailed description of the epic and its requirements - placeholder: | - A list of epic-level requirements in Given/When/Then syntax. - - If the epic is considered complete then indicate with a ***COMPLETE*** prefix. - - ```markdown - - (***requirement status***) Requirement descriptive text - - GIVEN a precondition - - WHEN an event happens - - THEN an action is taken / a result property is true - - > Details of missing implementation / link to phase with missing implementation - ``` - render: markdown - validations: - required: false - - - type: textarea - id: child-issues - attributes: - label: Child Issues - description: Break this epic down into child issues with appropriate links - placeholder: | - List the child issues that make up this epic. For each child issue: - - [ ] Child issue title - Brief description - - When child issues are created, link them here and update their status. - - Example structure: - - [ ] Child Issue 1: Description - - Link: https://github.com/JohnLudlow/GameEngineAdapter/issues/XXX - - Status: Not started/In progress/Completed - - - [ ] Child Issue 2: Description - - Link: https://github.com/JohnLudlow/GameEngineAdapter/issues/XXX - - Status: Not started/In progress/Completed - render: markdown - validations: - required: false - - - type: textarea - id: related-plan-docs - attributes: - label: Related Plan Documentation - description: Link to related plan documentation files in the repository - placeholder: | - If this epic is part of a larger plan or body of work, link to the related documentation: - - - Parent plan: `docs/plans/.md` - Overall plan this epic is part of - - Related plans: `docs/plans/.md` - Related work or dependent plans - - For large epics, detailed documentation may exist in a well-ordered file structure: - - `docs/plans//` - Folder containing detailed planning documents - - `docs/plans//.md` - Specific topic documentation - - This mirrors the hierarchy of related GitHub issues, with epic-level plans linking to child work. Reference the existing plan structure when linking related documentation. - render: markdown - validations: - required: false - - - type: textarea - id: references - attributes: - label: References - description: A list of links to external resources such as library documentation or articles about relevant techniques - placeholder: | - - Link 1 - - Link 2 - render: markdown - validations: - required: false \ No newline at end of file diff --git a/.github/ISSUE_TEMPLATE/refactor.yml b/.github/ISSUE_TEMPLATE/refactor.yml deleted file mode 100644 index 8d1e128..0000000 --- a/.github/ISSUE_TEMPLATE/refactor.yml +++ /dev/null @@ -1,112 +0,0 @@ -name: Refactoring -description: Request for code refactoring to improve structure without changing behavior -title: "[Refactor]: " -labels: ["refactor"] -assignees: [] -body: - - type: markdown - attributes: - value: | - Thanks for suggesting a refactoring! Please fill out the following sections to help us understand and evaluate your request. - - - type: input - id: overview - attributes: - label: Overview - description: Detailed description of the refactoring including purpose and intent as well as intended use cases - placeholder: Enter a clear and concise description of what should be refactored - validations: - required: true - - - type: textarea - id: definition-of-terms - attributes: - label: Definition of Terms - description: Detailed table of terms not considered 'common English' related to this refactoring - placeholder: | - | Term | Meaning | Reference | - | ---- | ------- | --------- | - | | | | - render: markdown - validations: - required: false - - - type: textarea - id: architectural-considerations - attributes: - label: Architectural Considerations and Constraints - description: Detailed model of the refactoring's architectural consideration and flow of data within the system - placeholder: | - - Include constraints such as performance considerations or affected components - - Include ASCII-art or mermaid diagrams where appropriate - - Include KaTeX math where relevant, with plain-English explanations - render: markdown - validations: - required: false - - - type: textarea - id: implementation-guide - attributes: - label: Implementation Guide - description: Detailed step-by-step implementation guide for this refactoring, including code snippets, unit tests and benchmarks - placeholder: | - If requested, write steps to follow Test Driven Development principles, leading with a minimal breaking test, followed by a minimal change to fix the test, followed by refactor, repeating until the refactoring is complete. - - If the refactoring is extensive and complex, create multiple subsections to make these steps more legible. - render: markdown - validations: - required: false - - - type: textarea - id: plan-requirements - attributes: - label: Plan Requirements - description: Detailed description of the refactoring and its requirements - placeholder: | - A list of plan-level requirements in Given/When/Then syntax. - - If a refactoring is considered complete then indicate with a ***COMPLETE*** prefix. - - ```markdown - - (***requirement status***) Requirement descriptive text - - GIVEN a precondition - - WHEN an event happens - - THEN an action is taken / a result property is true - - > Details of missing implementation / link to phase with missing implementation - ``` - render: markdown - validations: - required: false - - - type: textarea - id: related-plan-docs - attributes: - label: Related Plan Documentation - description: Link to related plan documentation files in the repository - placeholder: | - If this issue is part of a larger plan, link to the related documentation: - - - Parent plan: `docs/plans/.md` - Overall plan this issue is part of - - Related plans: `docs/plans/.md` - Related work or dependent plans - - For complex refactorings, corresponding detailed documentation may exist in: - - `docs/plans//` - Folder containing detailed planning documents - - `docs/plans//.md` - Specific topic documentation - - Reference the existing plan structure when linking related documentation. - render: markdown - validations: - required: false - - - type: textarea - id: references - attributes: - label: References - description: A list of links to external resources such as library documentation or articles about relevant techniques - placeholder: | - - Link 1 - - Link 2 - render: markdown - validations: - required: false \ No newline at end of file diff --git a/.github/ISSUE_TEMPLATE/technical_debt.yml b/.github/ISSUE_TEMPLATE/technical_debt.yml deleted file mode 100644 index f60cb5f..0000000 --- a/.github/ISSUE_TEMPLATE/technical_debt.yml +++ /dev/null @@ -1,112 +0,0 @@ -name: Technical Debt -description: Report technical debt that needs to be addressed -title: "[Tech Debt]: " -labels: ["technical debt"] -assignees: [] -body: - - type: markdown - attributes: - value: | - Thanks for reporting technical debt! Please fill out the following sections to help us understand and prioritize the work. - - - type: input - id: overview - attributes: - label: Overview - description: Detailed description of the technical debt including purpose and impact - placeholder: Enter a clear and concise description of the technical debt - validations: - required: true - - - type: textarea - id: definition-of-terms - attributes: - label: Definition of Terms - description: Detailed table of terms not considered 'common English' related to this technical debt - placeholder: | - | Term | Meaning | Reference | - | ---- | ------- | --------- | - | | | | - render: markdown - validations: - required: false - - - type: textarea - id: architectural-considerations - attributes: - label: Architectural Considerations and Constraints - description: Detailed model of the technical debt's architectural consideration and flow of data within the system - placeholder: | - - Include constraints such as performance considerations or affected components - - Include ASCII-art or mermaid diagrams where appropriate - - Include KaTeX math where relevant, with plain-English explanations - render: markdown - validations: - required: false - - - type: textarea - id: implementation-guide - attributes: - label: Implementation Guide - description: Detailed step-by-step implementation guide for addressing this technical debt, including code snippets, unit tests and benchmarks - placeholder: | - If requested, write steps to follow Test Driven Development principles, leading with a minimal breaking test, followed by a minimal change to fix the test, followed by refactor, repeating until the debt is resolved. - - If the work is extensive and complex, create multiple subsections to make these steps more legible. - render: markdown - validations: - required: false - - - type: textarea - id: plan-requirements - attributes: - label: Plan Requirements - description: Detailed description of the work and its requirements - placeholder: | - A list of plan-level requirements in Given/When/Then syntax. - - If the work is considered complete then indicate with a ***COMPLETE*** prefix. - - ```markdown - - (***requirement status***) Requirement descriptive text - - GIVEN a precondition - - WHEN an event happens - - THEN an action is taken / a result property is true - - > Details of missing implementation / link to phase with missing implementation - ``` - render: markdown - validations: - required: false - - - type: textarea - id: related-plan-docs - attributes: - label: Related Plan Documentation - description: Link to related plan documentation files in the repository - placeholder: | - If this issue is part of a larger plan, link to the related documentation: - - - Parent plan: `docs/plans/.md` - Overall plan this issue is part of - - Related plans: `docs/plans/.md` - Related work or dependent plans - - For complex technical debt items, corresponding detailed documentation may exist in: - - `docs/plans//` - Folder containing detailed planning documents - - `docs/plans//.md` - Specific topic documentation - - Reference the existing plan structure when linking related documentation. - render: markdown - validations: - required: false - - - type: textarea - id: references - attributes: - label: References - description: A list of links to external resources such as library documentation or articles about relevant techniques - placeholder: | - - Link 1 - - Link 2 - render: markdown - validations: - required: false \ No newline at end of file diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..e9125e9 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,33 @@ +# Contributing + +This repository uses a lightweight workitem convention to keep issues useful and discoverable. + +## Workitem basics + +- Minimal required fields for every issue: type, title, description +- Every workitem must include at least one label. Use the expanded taxonomy: type (bug/feature/idea), priority (priority-high/priority-medium/priority-low), and area (area-*) labels. Use `scale-epic` to mark large umbrella items. + +## Who can create and label workitems + +- Only maintainers may set labels and create workitems. If you need a new label, open a discussion or contact a maintainer. + +### Bug reports + +- Required: clear reproduction steps and severity (Low/Medium/High). +- Use the provided Bug Report template (.github/ISSUE_TEMPLATE/bug_report.md). + +### Feature requests + +- Required: user story and acceptance criteria. +- Use the Feature Request template (.github/ISSUE_TEMPLATE/feature_request.md). + +### Triage + +- Triage is performed on-demand by maintainers. Use the `needs-triage` label to flag items. + +### Workflow notes + +- Keep issues small and focused; large efforts should be tracked with `scale-epic` and child issues. +- Use cross-references to link related work and PRs. + +If you have questions about this policy, open an issue and tag a maintainer. diff --git a/actions b/actions index e50e664..7fe1749 160000 --- a/actions +++ b/actions @@ -1 +1 @@ -Subproject commit e50e664cfcd77d42b3746c6f495c186d46034269 +Subproject commit 7fe17499dde8d46b480e340087b4bc1b7f957338