NG-ZORRO Issue Reply
First read the issue body, labels, linked issues or pull requests, and discussion. Classify the report as a reproducible bug, feature request, usage question, duplicate, or insufficient/invalid report. Check existing component documentation, APIs, demos, issues, and changelog entries before deciding that functionality is absent or a regression is unresolved.
Write in the language used by the reporter's issue body. Keep the response specific, polite, and actionable. Do not promise an implementation date or acceptance of a feature.
Apply the repository's community policy from CONTRIBUTING.md and .github/nz-boot.yml:
- For a bug without a minimal reproduction, request a StackBlitz reproduction or minimal repository and use the configured
Need Reproduce / Need More Info flow.
- For a valid reproducible bug, recommend the appropriate component label; use
Component: <component> where the report is clearly owned by one component.
- For a feature request, check whether an existing API already solves the scenario before discussing a new API. Major features need an issue discussion; small features may be proposed as a PR.
- For a usage question, help with a documented API when possible; otherwise direct support questions to the channels named in
CONTRIBUTING.md.
- For a duplicate, point to the canonical issue and explain the closure succinctly.
- Do not close uncertain bugs, active discussions, or valid feature requests. The repository's no-response automation handles stale
Need More Info issues after seven days.
For any request that would comment, label, assign, reopen, or close an issue, first produce a triage summary and proposed response/actions. Perform GitHub mutations only after the user confirms the proposal.
1---2name: issue-reply3description: Triage and draft replies for NG-ZORRO GitHub issues. Use when asked to review, answer, label, close, or maintain issues.4---56# NG-ZORRO Issue Reply78First read the issue body, labels, linked issues or pull requests, and discussion. Classify the report as a reproducible bug, feature request, usage question, duplicate, or insufficient/invalid report. Check existing component documentation, APIs, demos, issues, and changelog entries before deciding that functionality is absent or a regression is unresolved.910Write in the language used by the reporter's issue body. Keep the response specific, polite, and actionable. Do not promise an implementation date or acceptance of a feature.1112Apply the repository's community policy from `CONTRIBUTING.md` and `.github/nz-boot.yml`:1314- For a bug without a minimal reproduction, request a StackBlitz reproduction or minimal repository and use the configured `Need Reproduce` / `Need More Info` flow.15- For a valid reproducible bug, recommend the appropriate component label; use `Component: <component>` where the report is clearly owned by one component.16- For a feature request, check whether an existing API already solves the scenario before discussing a new API. Major features need an issue discussion; small features may be proposed as a PR.17- For a usage question, help with a documented API when possible; otherwise direct support questions to the channels named in `CONTRIBUTING.md`.18- For a duplicate, point to the canonical issue and explain the closure succinctly.19- Do not close uncertain bugs, active discussions, or valid feature requests. The repository's no-response automation handles stale `Need More Info` issues after seven days.2021For any request that would comment, label, assign, reopen, or close an issue, first produce a triage summary and proposed response/actions. Perform GitHub mutations only after the user confirms the proposal.
ng-zorro