Docs/Community: add issue forms

[Panquesito7]

Things added/changed:

• Add issue forms.
  • Remove the old issue template.
• Closes Github: Convert all issue templates to issue forms #5915.

[ocornut]

Thank you!
Do you think it would be possible to enable Issues and PR on your forked branch so I can user test this in your repository?

[Panquesito7]

You can take a look at them here https://github.com/Panquesito7/imgui/tree/issue_forms/.github/ISSUE_TEMPLATE

[ocornut]

Thank you. I can see the individual templates formatted by Github, but I suspect enabling Issues on your repo would allow testing the entire flow?

@PathogenDavid reminded me they experimented with this a while ago too:
https://github.com/PathogenGymnasium/GitHubPlayground2/issues/new/choose

Will investigate both!

[ocornut]

General feedback:

• I don't think we need to overly split things in buckets "Feature request vs Report bug vs Documentation error. etc.". People very frequently report what they think are bug which is a usage issue, or feature request for things which are already possible to do. As thus, this I think the categorization may do more harm than good and maybe a single template is good.
• Need to rework to blur the lines between Issues/Questions: I intimately believe they are the same thing and even thought we are unfortunately swimming against the tide of github forcefully calling them "Issues" (and defaulting search to "open" issues), we are building a database of knowledge here. Our labeling scheme adds value.
• (Addendum: I genuinely think it would be better if the "Issues" tab was called "Forums" or "Discussions", but nope, GitHub preferred to create a Discussion tab encouraging lower-quality contributions and gamification of answers).
• Worth checking David versions for ideas https://github.com/PathogenGymnasium/GitHubPlayground2/issues/new?assignees=&labels=&template=0.dear_imgui_issue.yml and https://github.com/PathogenGymnasium/GitHubPlayground2/issues/new?assignees=&labels=bug&template=1.dear_imgui_bug_report.yml .
• David's version have more fields (renderer backend, compiler etc), which I think is desirable as we can provide clearer placeholder, and we can make filling mandatory and encourage more people to fill. However, this is less compatible with pasting the auto-generated block from Tools->About... so I don't know what's best here. If someone past the data from Tools->About the information is more complete and accurate than anything else, yet that information can't fit in separate fields.
• Perhaps for anyone who can run Dear ImGui we should encourage pasting the block from Tools->About. We could technically rework that block into a separate function emitting to TTY or Clipboard if needed, so it can be emitted without GUI running. But we still have a problem for people who e.g. can't build, or can't extract the info via TTY or Clipboard.
• I don't think using dropdown selections (like in David's version) is desirable as it creates confusion when fields can contains more than one value or a custom value. That's unless GitHub allows the "custom" thing to become a text box, but I assume if it allowed this David would have used it already.
• The library is called "Dear ImGui" not "ImGUI".

My thought on the "separate mandatory fields vs pasting from Tools->About is the following:

• We simplify/reduce the mandatory fields but ask for both.
• We should make it easy for people pasting from Tools->About to extract required info for mandatory fields. Aka the output fro Tools->About should have the first few lines in same order and format as mandatory fields.

Fields:

Single-line, free-form, mandatory

• Version "1.89 WIP (18901)" or git hash or "n/a"
• Branch "e.g. "master"/"docking" or "n/a"
• Platform backend, e.g. "imgui_impl_xxxx" or custom (specify) or "n/a"
• Renderer backend, e.g. "imgui_impl_xxxx" or custom (specify) or "n/a"
• Compiler(s)
• System

Multi-line:

• Config/Build Information (with info/links to wiki about how to get this from Tools->About)
• Your Issue/Question
• Screenshots/videos
• Standalone, minimal, complete, and verifiable example / Steps to reproduce

Each section should have markdown info/links to explain things. Perhaps the biggest value of this template system is our ability to interleave those details inside the form.

For a start I suggest we bundle "Your Issue/Question" as a single field BUT the description + placeholder should put an emphasis on importants sections from the guidelines: Intent, Context, Expected Behavior, Actual Behavior. etc.

How about pull requests?

Thank you!

[Panquesito7]

I'm kinda confused now 😅 If I understand well, you want to:

• Combine various sections to make it shorter.
• Have only one template for everything (?).
• Fix various issues (such as the Dear ImGui naming).
• Make a template for pull requests. This cannot be a .yml file, only .md, I think.

Not sure what else should be done. 🤔

[ocornut]

Combine various sections to make it shorter.

Not necessarily shorter, but I listed the fields which I thought seemed like a good compromise. One-liner field are more likely to be filled correctly than multi-line fields with variety of infos. But multi-line fields desirable for expressiveness.

Have only one template for everything (?).

Yes or at least until we find a more meaningful reason to split them.

Fix various issues (such as the Dear ImGui naming).

Yes.

Make a template for pull requests. This cannot be a .yml file, only .md, I think

Yes, but that can be addressed later indeed, no need to worry about this now.

[Panquesito7]

Hey! It's been a lot of time now 👀 been really busy lately.
I'll see if I can re-work on this soon. If not, I would recommend re-opening the issue and closing this PR in case anyone else wants to take it. Thank you. 🙂

[ocornut]

@Panquesito7 could you make "issue_forms" the default/main branch of your work, so clicking "New Issue" would reflect the changes in that branch?

No worry I copied it to a private repo of mine.

[ocornut]

I've returned back to this and pushed a new issue template:

Commit c528b68
Template in action
https://github.com/ocornut/imgui/issues/new?assignees=&labels=&projects=&template=issue_template.yml

I experimented for several hours with details to try to get things right.
I don't believe in hard separation between "bugs" "features request" "questions" and thus created a single template.
I'm not even super happy by the separation into 3 textarea at the bottom currently.

It turns out that IMHO the most useful feature is being able to inject markdown, links and comments in the template, making various information easier to access. I have copied selected parts of Guidelines into the issue templates.

Issues imho:

• text area are small height by default which is incredibly annoying (compared to old issue template where single textarea was larger).
• there's a checkbox system but it leads to checkboxes being copied to the issue and treated as a task-list, so it's unusable for this sorts of things:

  - type: checkboxes
    attributes:
      label: Prerequisites
      options:
      - label: I have read [Frequently Asked Questions](https://github.com/ocornut/imgui/blob/master/docs/FAQ.md).
        required: true
      - label: I have read [Contributing Guidelines -> General Advices](https://github.com/ocornut/imgui/blob/master/docs/CONTRIBUTING.md#getting-started--general-advice).
        required: true
      - label: I have read [Contributing Guidelines -> How to open an Issue](https://github.com/ocornut/imgui/blob/master/docs/CONTRIBUTING.md#how-to-open-an-issue).
        required: true
      - label: I have searched [Github Issues and PR](https://github.com/ocornut/imgui/issues?q=) for discussion of similar topics.
        required: true
      - label: I have put some effort at not clicking those five checkboxes in a hurry :)
        required: true

Instead I have used a non-checkable bullet list in markdown. I tried to use markdown checkboxes but there weren't editable.

Thanks!