chore: add bug report template

[Yicong-Huang]

This PR adds a template for creating an issue with "Bug" type. It will be used by github to render a form. I followed this example to configure it. https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#creating-issue-forms

Here is an example rendering of the form. Note that this is only for reference, the exact content has been customized by me.

[Copilot]

Pull Request Overview

This PR adds a GitHub issue template for bug reports to standardize bug reporting and improve triage efficiency. The template includes structured fields for bug description, reproduction steps, version information, and browser compatibility.

• Adds a comprehensive YAML-based bug report template with required and optional fields
• Includes validation rules to ensure essential information is provided
• Incorporates Code of Conduct agreement as part of the submission process

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[chenlica]

Is it possible to include an example issue and add its link to this PR? The sample YAML can also include the URL.

[chenlica]

Here's a possible issue example: #3821

[aglinxinyuan]

Could you explain how this should be used in the PR description? I’m confused on the purpose of this PR. Is the idea that developers simply copy and paste the template manually? If that’s the case, what does this PR do?

[chenlica]

I think this PR adds a YAML template for future issues to use.

[aglinxinyuan]

I think this PR adds a YAML template for future issues to use.

We don’t typically use YAML to raise issues—or at least, I’m not aware of a way to do that. If the intent is just to provide a template for developers to copy to the GitHub web interface, Markdown (MD) would likely be a more suitable format. Since it's a yaml, and it's under .gitHub folder, I assume it adds some automation to GitHub. Maybe @Yicong-Huang can give information in PR description to avoid confusion.

[Yicong-Huang]

I think this PR adds a YAML template for future issues to use.

We don’t typically use YAML to raise issues—or at least, I’m not aware of a way to do that. If the intent is just to provide a template for developers to copy to the GitHub web interface, Markdown (MD) would likely be a more suitable format. Since it's a yaml, and it's under .gitHub folder, I assume it adds some automation to GitHub. Maybe @Yicong-Huang can give information in PR description to avoid confusion.

I have added more details in the PR description. Hope that can clarify the purpose of the PR!

[Yicong-Huang]

Here's a possible issue example: #3821

I checked the proposed example but it looks different from the format proposed in this PR. I current do not have an example as this is the first time we are adding this exact template. How about the following: let's merge this PR, to render the template on github, then we can create an issue with the template, then after that we can add the issue as an example.

[aglinxinyuan]

Thanks! I understand the change now. That’s a really convenient change.

[chenlica]

I agree with the plan suggested by @Yicong-Huang .

[kunwp1]

I’m trying to file a bug report, but the template requires selecting a version where the bug was found. The issue is that the dropdown only has one option: the official release (v1.0.0). This isn’t very user-friendly for developers, since we usually track bugs by GitHub commit hash rather than just a release version. Could we improve the template to support this?

Screen.Recording.2025-10-03.at.9.48.50.PM.mov

[chenlica]

Is it a question for @Yicong-Huang ?

[Yicong-Huang]

good question!

However I think we should start to use versions to track instead of commits. Because when reporting bugs, the reporter could be developers and users. And even for developers, one may not know the root cause yet, thus it's more make sense to report a coarse grained version, instead of a fine grained commit.

I can think of the following:

1. Add an entry for pre-release versions, for example, our current master always refers to the next pre-release version (I.e., 1.1.0-incubating for now). One can choose this pre-release version to report for master.
2. Add an optional field of commit hash, if developer knows which commit has issue, he/she can include it in the report. Users or developers who do not know exact commit has the issue, can just ignore it.

What do you think?

[kunwp1]

@Yicong-Huang I agree with your design.

[Yicong-Huang]

@Yicong-Huang I agree with your design.

I'm out today. Do you want to file a PR for the change, if it's handy for you?