🌱 Add failing/flaking test issue templates to the repository

[furkatgofurov7]

What this PR does / why we need it:
While we can still modify existing issue templates when reporting CI related issues, it would be very helpful if we could have issue templates ready while opening failing/flaking test issues in the repository (especially handy for relase team CI signal members) similar to the one used in the k8s repo, as IMO it helps to:

• gather all the required and additional information needed to tackle the issue regardless of whoever opens it
• standardize the issues of the same kind in the future

Note: I am still using the markdown formatted issue templates for new failing/flaking-test templates in this PR but we have a possibility to move all existing templates from markdown format to GitHub forms for issue templates which basically YAML representation of the template.
Example issue template in kubernetes repo to get the idea how it looks like: https://github.com/kubernetes/kubernetes/issues/new?assignees=&labels=kind%2Ffailing-test&template=failing-test.yaml
k/k repo has already switched to the GitHub forms in kubernetes/kubernetes#104468. We can replace all templates with the GitHub forms if agreed and if not we could still stick to the markdown format as well (since the feature itself seems still in beta).

[killianmuldoon]

I think this is a good idea and something successive release teams can refine over time. Can we also add a task for the release team (maybe as the responsibility of the CI lead but the team can decide that) to maintain and review these templates?

I'm happy with adding them, but it's a good idea to have a defined role for maintaining and keeping these up to date as needed.

[furkatgofurov7]

I think this is a good idea and something successive release teams can refine over time. Can we also add a task for the release team (maybe as the responsibility of the CI lead but the team can decide that) to maintain and review these templates?

I'm happy with adding them, but it's a good idea to have a defined role for maintaining and keeping these up to date as needed

@killianmuldoon thanks for the review, I totally agree with the point. I have added it as part of the CI lead responsibilities which makes more sense IMO, PTAL, but I will wait for others' opinions as well.

/cc @fabriziopandini
@kubernetes-sigs/cluster-api-release-team

[ykakarap]

This is a good idea. 👍🏼
We can refine the template over time as we start using them but this is a great start.

[furkatgofurov7]

Labels were added automatically after review comment, removing them.
/remove-kind flake

[furkatgofurov7]

/remove-kind failing-test

[fabriziopandini]

Let's give it a try!
/lgtm
/approve

Also +1 from my side to switch to GitHub forms in a follow-up PR

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: bbcee8bea0c0df9b44dfc9eb52b810c09ad5a0df

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fabriziopandini

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [fabriziopandini]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[furkatgofurov7]

Also +1 from my side to switch to GitHub forms in a follow-up PR

@fabriziopandini great to hear that, I created a separate issue #7815 to track it.

[CecileRobertMichon]

I'm late to the party but I love this, thanks for doing this @furkatgofurov7 🙏