[meta] Clean up issue templates in this repository

[amisevsk]

Description

The issue templates used in this repository are very long and a confusing mix of comments, headings, and bolded text. In addition, they request information that can be confusing or irrelevant to the issue being reported. For example, in the bug template, the "What versions of software are you using?" contains the following to be filled out (highlighting intentionaly disabled as that's what the editor shows currently):

## What versions of software are you using?

### Go project

**Operating System and version:**

**Go Pkg Version:**

### Node.js project

<!--
    Please paste the text output of the console in the error output section with a screenshot
-->

**Operating System and version:** 

**Node.js version:**

**Yarn version:**

**Project.json:**

### Web browser

<!--
    Please paste the text output of the console in the error output section with a screenshot
-->

**Operating System and version:**

**Browser name and version:**

It's not clear how to fill this out, or why it's requesting logs in a section listing versions.

In total, this makes filing issues (and reading issues) in this repository rather difficult. If the level of detail above is actually required, we should use an issue form to prompt for required information in an easy to understand way.

[michael-valdron]

If the level of detail above is actually required, we should use an issue form to prompt for required information in an easy to understand way.

This is an interesting direction for creating issues rather than using raw templates, it would certainly make creating issues more simpler and also much faster. I will bring this up with the rest of the devfiles team to investigate this further.

The issue templates used in this repository are very long and a confusing mix of comments, headings, and bolded text. In addition, they request information that can be confusing or irrelevant to the issue being reported.

I can also suggest is to break up the templates further into subtopics. For example, instead of having one large bug issue template, we could have a bug issue template for the registry and a bug issue template for devfile landing page. I find the most common case I ran into for not using the whole template is when fields are not applicable, breaking down the templates might make this simpler as an alternative to using the issue forms.

[michael-valdron]

/kind user-story
/area releng

[amisevsk]

To get a sense of what a form-based issue template might look like, the Eclipse Che project might be an example (I'm familiar with it as I contribute there as well): https://github.com/eclipse/che/issues/new?assignees=&labels=kind%2Fbug&projects=&template=bug_report.yml

Blocks like

### Which area this bug is related to?

<!--
    Uncomment appropriate `/area` lines, and delete the rest.
    For example, `> /area api` would simply become: `/area api`
-->

> /area ci
> /area api
> /area library
> /area registry
> /area devworkspace
> /area integration-tests
> /area test-automation
> /area releng
> /area landing-page

could potentially be replaced with e.g. a dropdown menu

[github-actions]

This issue is stale because it has been open for 90 days with no activity. Remove stale label or comment or this will be closed in 60 days.

[michael-valdron]

Would like to reopen this issue for review of the outside effort I did to convert our issue templates into issue forms: #1703

[michael-valdron]

To get a sense of what a form-based issue template might look like, the Eclipse Che project might be an example (I'm familiar with it as I contribute there as well): https://github.com/eclipse/che/issues/new?assignees=&labels=kind%2Fbug&projects=&template=bug_report.yml

Blocks like

### Which area this bug is related to?

<!--
    Uncomment appropriate `/area` lines, and delete the rest.
    For example, `> /area api` would simply become: `/area api`
-->

> /area ci
> /area api
> /area library
> /area registry
> /area devworkspace
> /area integration-tests
> /area test-automation
> /area releng
> /area landing-page

could potentially be replaced with e.g. a dropdown menu

Unfortunately I had to leave this a textarea due to technical limitation with both issue forms and openshift-ci: #1703 (comment)

Issue forms locked to comma separated value for multi-choice dropdowns and openshift-ci errors no matter how I format it.

[michael-valdron]

To get a sense of what a form-based issue template might look like, the Eclipse Che project might be an example (I'm familiar with it as I contribute there as well): https://github.com/eclipse/che/issues/new?assignees=&labels=kind%2Fbug&projects=&template=bug_report.yml
Blocks like

### Which area this bug is related to?

<!--
    Uncomment appropriate `/area` lines, and delete the rest.
    For example, `> /area api` would simply become: `/area api`
-->

> /area ci
> /area api
> /area library
> /area registry
> /area devworkspace
> /area integration-tests
> /area test-automation
> /area releng
> /area landing-page

could potentially be replaced with e.g. a dropdown menu

Unfortunately I had to leave this a textarea due to technical limitation with both issue forms and openshift-ci: #1703 (comment)

Issue forms locked to comma separated value for multi-choice dropdowns and openshift-ci errors no matter how I format it.

Opened github/issue-parser#17 for a feature request to override the delimiter.

[michael-valdron]

Opened a discussion post for a feature request to override the delimiter: https://github.com/orgs/community/discussions/157091