chore: improve GitHub issue templates with structured forms#528
chore: improve GitHub issue templates with structured forms#528
Conversation
- Replace installer-failure.yml with unified bug_report.yml (component dropdown includes CLI/installer) - Add feature_request.yml (lightweight: description + motivation) - Add config.yml chooser (blank issues disabled, links to docs/discussions/security policy) - Tag-style title prefixes: [Bug], [Feature] - Optional synthorg doctor output field on bug reports - Severity and OS dropdowns on bug reports Closes #522
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the issue reporting experience by introducing structured GitHub issue forms. The changes aim to streamline the process for users to report bugs and request features, ensuring that necessary information is collected upfront. This improves the quality of submitted issues, making them easier for maintainers to triage and resolve, ultimately fostering a more efficient development workflow. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughSummary by CodeRabbit
WalkthroughAdds structured GitHub issue forms: Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
📝 Coding Plan
Comment |
There was a problem hiding this comment.
Code Review
This pull request improves the GitHub issue templates by introducing structured forms for bug reports and feature requests, and by configuring the issue chooser to guide users. The changes are a great step towards more structured and actionable issues. My review includes a few suggestions to further improve the quality of the submitted issues: making the version field mandatory in bug reports to aid debugging, re-introducing the install-method field from the old installer failure template as an optional field in the new bug report form, and making the motivation field mandatory for feature requests to ensure the value proposition is clear.
| built: 2026-03-15T12:00:00Z | ||
| render: shell | ||
| validations: | ||
| required: false |
There was a problem hiding this comment.
The version field is crucial for debugging, but it's currently optional. This can lead to incomplete bug reports that are difficult to reproduce. Please consider making this field required to ensure you always get the version information. Users who have installation failures can specify the version they were attempting to install.
required: true| - type: dropdown | ||
| id: component | ||
| attributes: | ||
| label: Component | ||
| description: Which part of SynthOrg is affected? | ||
| options: | ||
| - Backend (Python API / engine) | ||
| - Dashboard (Vue web UI) | ||
| - CLI (Go binary / installer) | ||
| - Docker (compose / containers) | ||
| - Docs | ||
| validations: | ||
| required: true |
There was a problem hiding this comment.
The removed installer-failure.yml template had a helpful install-method dropdown. This information is lost in the new unified bug report, which is a regression for debugging installation issues. While conditional fields aren't supported in GitHub Issue forms, you could add this back as an optional dropdown to gather this crucial information for CLI/installer-related bugs.
I'd suggest adding the following block after this component dropdown:
- type: dropdown
id: install-method
attributes:
label: Installation method (if applicable)
description: If this bug is about the CLI/installer, how did you install it?
options:
- Homebrew (brew install)
- Scoop (scoop install)
- curl | sh (Linux/macOS)
- PowerShell installer (Windows)
- Manual download from GitHub Releases
- Built from source (go build)
validations:
required: false| label: Motivation | ||
| description: Why is this needed? What's the current workaround (if any)? | ||
| validations: | ||
| required: false |
There was a problem hiding this comment.
The motivation field is key to understanding the value of a feature request. Making it optional might lead to suggestions without a clear purpose or problem statement. To improve the quality of feature requests, please consider making this field required.
required: trueThere was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/ISSUE_TEMPLATE/bug_report.yml:
- Around line 12-50: The unified bug form lacks an installer-specific intake for
the CLI component: add a required dropdown field with id: installation_method
(options like package manager, installer script, binary download, Docker image,
other) and validations.required: true, and update the routing/metadata so when
id: component selects "CLI (Go binary / installer)" the issue is directed to or
loads a dedicated CLI-installer template/path for further installer triage;
reference the existing fields id: component, id: severity and id: os when adding
the new installation_method field and ensure the new field appears near line
where id: component is defined so installer info is captured before submission.
- Around line 81-107: Make the version and doctor blocks (ids "version" and
"doctor") required-with-fallback by changing validations.required from false to
true and adding an explicit installation-status selector (e.g., new field id
"installation_status" with options "installed" and "not_installed"); enforce
conditional validation so "version" and "doctor" are required only when
installation_status == "installed" and allowed to be empty when "not_installed",
and update their placeholders to instruct users to pick "Not installed" if
SynthOrg isn't present.
In @.github/ISSUE_TEMPLATE/feature_request.yml:
- Around line 12-56: The feature request template is missing required intake
fields referenced by the objective: add three new form blocks with unique ids
design_spec, dependencies, and scope_assessment (similar to existing blocks like
component, description, motivation) so triage captures design spec reference,
related/dependency issues, and a scope self-assessment; each block should
include an attributes.label and attributes.description and set
validations.required: true (or required:false for dependencies if you prefer
optional linking), and place them after the existing description/component
sections to satisfy issue `#522` acceptance criteria.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 26184af4-679b-440b-9483-8116c6e1b20e
📒 Files selected for processing (4)
.github/ISSUE_TEMPLATE/bug_report.yml.github/ISSUE_TEMPLATE/config.yml.github/ISSUE_TEMPLATE/feature_request.yml.github/ISSUE_TEMPLATE/installer-failure.yml
💤 Files with no reviewable changes (1)
- .github/ISSUE_TEMPLATE/installer-failure.yml
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Analyze (python)
🔇 Additional comments (1)
.github/ISSUE_TEMPLATE/config.yml (1)
1-11: Chooser configuration looks correct.
blank_issues_enabled: falseand the three contact links are set up cleanly and align with the issue-routing objective.
| - type: dropdown | ||
| id: component | ||
| attributes: | ||
| label: Component | ||
| description: Which part of SynthOrg is affected? | ||
| options: | ||
| - Backend (Python API / engine) | ||
| - Dashboard (Vue web UI) | ||
| - CLI (Go binary / installer) | ||
| - Docker (compose / containers) | ||
| - Docs | ||
| validations: | ||
| required: true | ||
|
|
||
| - type: dropdown | ||
| id: severity | ||
| attributes: | ||
| label: Severity | ||
| options: | ||
| - Crash / data loss | ||
| - Wrong behavior (feature broken) | ||
| - Performance issue | ||
| - Cosmetic / minor | ||
| validations: | ||
| required: true | ||
|
|
||
| - type: dropdown | ||
| id: os | ||
| attributes: | ||
| label: Operating system | ||
| options: | ||
| - macOS (Apple Silicon / arm64) | ||
| - macOS (Intel / amd64) | ||
| - Linux (amd64) | ||
| - Linux (arm64) | ||
| - Windows (amd64) | ||
| - Windows (arm64) | ||
| validations: | ||
| required: true |
There was a problem hiding this comment.
Installer triage requirements are under-specified in this unified bug form.
Line [20] includes “CLI (Go binary / installer)”, but there is no required installation method field and no dedicated CLI-installation template path. This regresses the linked requirement for installer-specific intake and makes install failures harder to classify.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/ISSUE_TEMPLATE/bug_report.yml around lines 12 - 50, The unified bug
form lacks an installer-specific intake for the CLI component: add a required
dropdown field with id: installation_method (options like package manager,
installer script, binary download, Docker image, other) and
validations.required: true, and update the routing/metadata so when id:
component selects "CLI (Go binary / installer)" the issue is directed to or
loads a dedicated CLI-installer template/path for further installer triage;
reference the existing fields id: component, id: severity and id: os when adding
the new installation_method field and ensure the new field appears near line
where id: component is defined so installer info is captured before submission.
| - type: textarea | ||
| id: version | ||
| attributes: | ||
| label: Version info | ||
| description: "Output of `synthorg version`, or the version you tried to install." | ||
| placeholder: | | ||
| synthorg v0.3.0 | ||
| commit: abc1234 | ||
| built: 2026-03-15T12:00:00Z | ||
| render: shell | ||
| validations: | ||
| required: false | ||
|
|
||
| - type: textarea | ||
| id: doctor | ||
| attributes: | ||
| label: Doctor output | ||
| description: | | ||
| If SynthOrg is installed, paste the output of `synthorg doctor`. | ||
| This collects OS, architecture, Docker version, container status, health checks, | ||
| and config (secrets are redacted). It makes debugging much faster. | ||
| placeholder: | | ||
| Paste `synthorg doctor` output here (optional but very helpful) | ||
| render: json | ||
| validations: | ||
| required: false | ||
|
|
There was a problem hiding this comment.
version and doctor should be required-with-fallback, not optional.
Per the linked objective, reporters should provide version and doctor diagnostics (or explicitly state “not installed”). Current optional fields at Line [81] and Line [94] will lead to low-signal bug reports.
Suggested patch
- type: textarea
id: version
@@
validations:
- required: false
+ required: true
- type: textarea
id: doctor
attributes:
label: Doctor output
description: |
- If SynthOrg is installed, paste the output of `synthorg doctor`.
+ Paste output of `synthorg doctor`.
+ If not installed yet, write: `not installed`.
This collects OS, architecture, Docker version, container status, health checks,
and config (secrets are redacted). It makes debugging much faster.
placeholder: |
- Paste `synthorg doctor` output here (optional but very helpful)
+ {
+ "os": "linux",
+ "arch": "amd64",
+ "docker": "24.x",
+ "status": "healthy"
+ }
+ # or: not installed
render: json
validations:
- required: false
+ required: true🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/ISSUE_TEMPLATE/bug_report.yml around lines 81 - 107, Make the
version and doctor blocks (ids "version" and "doctor") required-with-fallback by
changing validations.required from false to true and adding an explicit
installation-status selector (e.g., new field id "installation_status" with
options "installed" and "not_installed"); enforce conditional validation so
"version" and "doctor" are required only when installation_status == "installed"
and allowed to be empty when "not_installed", and update their placeholders to
instruct users to pick "Not installed" if SynthOrg isn't present.
| - type: dropdown | ||
| id: component | ||
| attributes: | ||
| label: Component | ||
| description: Which part of SynthOrg does this affect? | ||
| options: | ||
| - Backend (Python API / engine) | ||
| - Dashboard (Vue web UI) | ||
| - CLI (Go binary) | ||
| - Docker (compose / containers) | ||
| - Docs | ||
| validations: | ||
| required: true | ||
|
|
||
| - type: textarea | ||
| id: description | ||
| attributes: | ||
| label: Description | ||
| description: What do you want and what problem does it solve? | ||
| validations: | ||
| required: true | ||
|
|
||
| - type: textarea | ||
| id: motivation | ||
| attributes: | ||
| label: Motivation | ||
| description: Why is this needed? What's the current workaround (if any)? | ||
| validations: | ||
| required: false | ||
|
|
||
| - type: textarea | ||
| id: alternatives | ||
| attributes: | ||
| label: Alternatives considered | ||
| description: Other approaches you thought of and why this one is better. | ||
| validations: | ||
| required: false | ||
|
|
||
| - type: textarea | ||
| id: context | ||
| attributes: | ||
| label: Additional context | ||
| description: "Mockups, links, research, related issues, etc." | ||
| validations: | ||
| required: false |
There was a problem hiding this comment.
Missing required product-intake fields from the linked objective.
From Line [12] onward, the form omits: (1) design spec reference, (2) dependency/related-issues field, and (3) scope self-assessment. That reduces triage quality and does not fully meet issue #522 acceptance criteria.
Suggested patch
- type: textarea
id: alternatives
@@
validations:
required: false
+ - type: input
+ id: design_spec
+ attributes:
+ label: Design spec / RFC reference
+ description: Link to spec, RFC, mock, or proposal (if available).
+ placeholder: https://...
+ validations:
+ required: false
+
+ - type: textarea
+ id: dependencies
+ attributes:
+ label: Dependencies / related issues
+ description: Related issues, blockers, or upstream dependencies.
+ placeholder: "#123, `#456`, depends on ..."
+ validations:
+ required: false
+
+ - type: dropdown
+ id: scope
+ attributes:
+ label: Scope self-assessment
+ options:
+ - Small (localized change)
+ - Medium (cross-component changes)
+ - Large (architecture/major workflow impact)
+ validations:
+ required: true
+
- type: textarea
id: context📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - type: dropdown | |
| id: component | |
| attributes: | |
| label: Component | |
| description: Which part of SynthOrg does this affect? | |
| options: | |
| - Backend (Python API / engine) | |
| - Dashboard (Vue web UI) | |
| - CLI (Go binary) | |
| - Docker (compose / containers) | |
| - Docs | |
| validations: | |
| required: true | |
| - type: textarea | |
| id: description | |
| attributes: | |
| label: Description | |
| description: What do you want and what problem does it solve? | |
| validations: | |
| required: true | |
| - type: textarea | |
| id: motivation | |
| attributes: | |
| label: Motivation | |
| description: Why is this needed? What's the current workaround (if any)? | |
| validations: | |
| required: false | |
| - type: textarea | |
| id: alternatives | |
| attributes: | |
| label: Alternatives considered | |
| description: Other approaches you thought of and why this one is better. | |
| validations: | |
| required: false | |
| - type: textarea | |
| id: context | |
| attributes: | |
| label: Additional context | |
| description: "Mockups, links, research, related issues, etc." | |
| validations: | |
| required: false | |
| - type: dropdown | |
| id: component | |
| attributes: | |
| label: Component | |
| description: Which part of SynthOrg does this affect? | |
| options: | |
| - Backend (Python API / engine) | |
| - Dashboard (Vue web UI) | |
| - CLI (Go binary) | |
| - Docker (compose / containers) | |
| - Docs | |
| validations: | |
| required: true | |
| - type: textarea | |
| id: description | |
| attributes: | |
| label: Description | |
| description: What do you want and what problem does it solve? | |
| validations: | |
| required: true | |
| - type: textarea | |
| id: motivation | |
| attributes: | |
| label: Motivation | |
| description: Why is this needed? What's the current workaround (if any)? | |
| validations: | |
| required: false | |
| - type: textarea | |
| id: alternatives | |
| attributes: | |
| label: Alternatives considered | |
| description: Other approaches you thought of and why this one is better. | |
| validations: | |
| required: false | |
| - type: input | |
| id: design_spec | |
| attributes: | |
| label: Design spec / RFC reference | |
| description: Link to spec, RFC, mock, or proposal (if available). | |
| placeholder: https://... | |
| validations: | |
| required: false | |
| - type: textarea | |
| id: dependencies | |
| attributes: | |
| label: Dependencies / related issues | |
| description: Related issues, blockers, or upstream dependencies. | |
| placeholder: "#123, `#456`, depends on ..." | |
| validations: | |
| required: false | |
| - type: dropdown | |
| id: scope | |
| attributes: | |
| label: Scope self-assessment | |
| options: | |
| - Small (localized change) | |
| - Medium (cross-component changes) | |
| - Large (architecture/major workflow impact) | |
| validations: | |
| required: true | |
| - type: textarea | |
| id: context | |
| attributes: | |
| label: Additional context | |
| description: "Mockups, links, research, related issues, etc." | |
| validations: | |
| required: false |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/ISSUE_TEMPLATE/feature_request.yml around lines 12 - 56, The feature
request template is missing required intake fields referenced by the objective:
add three new form blocks with unique ids design_spec, dependencies, and
scope_assessment (similar to existing blocks like component, description,
motivation) so triage captures design spec reference, related/dependency issues,
and a scope self-assessment; each block should include an attributes.label and
attributes.description and set validations.required: true (or required:false for
dependencies if you prefer optional linking), and place them after the existing
description/component sections to satisfy issue `#522` acceptance criteria.
- Make version field required on bug reports (with "not installed" fallback) - Add install-method dropdown to bug report (restores info from old installer-failure template, optional) - Add design spec reference and dependencies fields to feature request - Update #522 AC: dedicated CLI template merged into unified bug report per user decision Addresses review feedback from CodeRabbit, Gemini, and local agents.
There was a problem hiding this comment.
♻️ Duplicate comments (2)
.github/ISSUE_TEMPLATE/feature_request.yml (1)
59-75:⚠️ Potential issue | 🟠 MajorAdd required scope self-assessment to complete feature intake.
design-specanddependencieswere added, but thescope self-assessmentfield is still missing, so linked objective#522is not fully satisfied.Suggested patch
- type: textarea id: dependencies @@ validations: required: false + - type: dropdown + id: scope-assessment + attributes: + label: Scope self-assessment + description: How large is the expected change? + options: + - Small (localized change) + - Medium (cross-component change) + - Large (architecture / major workflow impact) + validations: + required: true + - type: textarea id: context🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/ISSUE_TEMPLATE/feature_request.yml around lines 59 - 75, Add a required "scope self-assessment" textarea field to the template (similar to the existing entries like id: design-spec and id: dependencies) so the feature intake satisfies linked objective `#522`; create a new block with id: scope_self_assessment, attributes.label: "Scope self-assessment", attributes.description: a short prompt to evaluate complexity/risks/impact, a placeholder example, and validations.required: true to enforce completion before submission..github/ISSUE_TEMPLATE/bug_report.yml (1)
113-120:⚠️ Potential issue | 🟡 MinorDoctor field help text should include explicit fallback + concrete example format.
The template asks for doctor output but doesn’t show a concrete expected example or a clear
not installedfallback in this field’s guidance.Suggested patch
- type: textarea id: doctor attributes: label: Doctor output description: | - If SynthOrg is installed, paste the output of `synthorg doctor`. + Paste the output of `synthorg doctor`. + If SynthOrg is not installed yet, write: `not installed`. This collects OS, architecture, Docker version, container status, health checks, and config (secrets are redacted). It makes debugging much faster. placeholder: | - Paste `synthorg doctor` output here (optional but very helpful) + { + "os": "linux", + "arch": "amd64", + "docker": "24.x", + "status": "healthy" + } + # or: not installed render: json🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/ISSUE_TEMPLATE/bug_report.yml around lines 113 - 120, The "Doctor output" field's guidance (label "Doctor output") lacks an explicit fallback if SynthOrg isn't installed and doesn't show a concrete example format; update the description and placeholder for this field to explicitly state what to paste when SynthOrg is not installed (e.g., "If SynthOrg is not installed, paste 'not installed' or your OS and Docker info") and include a short concrete example snippet of expected `synthorg doctor` output format (OS, architecture, Docker version, container statuses, redacted secrets) so users know how to fill the field; modify the description and placeholder entries in the YAML (the "description" and "placeholder" for the Doctor output label) accordingly.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In @.github/ISSUE_TEMPLATE/bug_report.yml:
- Around line 113-120: The "Doctor output" field's guidance (label "Doctor
output") lacks an explicit fallback if SynthOrg isn't installed and doesn't show
a concrete example format; update the description and placeholder for this field
to explicitly state what to paste when SynthOrg is not installed (e.g., "If
SynthOrg is not installed, paste 'not installed' or your OS and Docker info")
and include a short concrete example snippet of expected `synthorg doctor`
output format (OS, architecture, Docker version, container statuses, redacted
secrets) so users know how to fill the field; modify the description and
placeholder entries in the YAML (the "description" and "placeholder" for the
Doctor output label) accordingly.
In @.github/ISSUE_TEMPLATE/feature_request.yml:
- Around line 59-75: Add a required "scope self-assessment" textarea field to
the template (similar to the existing entries like id: design-spec and id:
dependencies) so the feature intake satisfies linked objective `#522`; create a
new block with id: scope_self_assessment, attributes.label: "Scope
self-assessment", attributes.description: a short prompt to evaluate
complexity/risks/impact, a placeholder example, and validations.required: true
to enforce completion before submission.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: bbf7c1fb-0813-4c40-bf38-822ca50c4183
📒 Files selected for processing (2)
.github/ISSUE_TEMPLATE/bug_report.yml.github/ISSUE_TEMPLATE/feature_request.yml
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Analyze (python)
🔇 Additional comments (2)
.github/ISSUE_TEMPLATE/feature_request.yml (1)
50-68: Good addition of design-spec and dependency intake fields.These fields materially improve triage quality for feature requests.
.github/ISSUE_TEMPLATE/bug_report.yml (1)
97-109: Version intake is correctly required with a clear fallback.This is a strong improvement for bug triage consistency.
Remove Homebrew and Scoop options (no formula/manifest exists). Clarify the dropdown is for CLI installation specifically.
Add concrete JSON example matching actual synthorg doctor output format. Add explicit "not installed" fallback instruction.
🤖 I have created a release *beep* *boop* --- ## [0.3.2](v0.3.1...v0.3.2) (2026-03-17) ### Features * **settings:** route structural data reads through SettingsService ([#525](#525)) ([289f604](289f604)) ### Bug Fixes * **cli:** add fallback arch detection in PowerShell installer ([#529](#529)) ([0250afb](0250afb)), closes [#521](#521) ### CI/CD * bump the minor-and-patch group with 2 updates ([#517](#517)) ([46bdd1a](46bdd1a)) * bump wrangler from 4.73.0 to 4.74.0 in /.github in the minor-and-patch group ([#511](#511)) ([903b71a](903b71a)) ### Maintenance * bump node from `7a4ef57` to `44bcbf4` in /docker/sandbox ([#515](#515)) ([3cbddd1](3cbddd1)) * bump python from `6a27522` to `584e89d` in /docker/backend ([#513](#513)) ([0715910](0715910)) * bump python from `6a27522` to `584e89d` in /docker/sandbox ([#514](#514)) ([787dfe1](787dfe1)) * bump the minor-and-patch group across 1 directory with 2 updates ([#527](#527)) ([e96c0d4](e96c0d4)) * bump the minor-and-patch group across 2 directories with 3 updates ([#512](#512)) ([b95ba3d](b95ba3d)) * **docker:** disable Mem0 telemetry in container config ([#531](#531)) ([9fc29eb](9fc29eb)) * improve GitHub issue templates with structured forms ([#528](#528)) ([4fb66cf](4fb66cf)), closes [#522](#522) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
Summary
installer-failure.ymlwith unifiedbug_report.yml— component dropdown includes CLI/installer, so a dedicated template is no longer neededfeature_request.yml— lightweight form with description, motivation, and alternativesconfig.ymltemplate chooser — blank issues disabled, external links to docs, discussions, and security policy[Bug],[Feature]synthorg doctoroutput field on bug reports for faster debuggingTest plan
Closes #522