Templates for Issue creation

[varodrig]

Relates to issue #3935
First PR templating issues with the website.
the implementation follows a similar approach as the kubernetes website: https://github.com/kubernetes/website/blob/main/.github/ISSUE_TEMPLATE/bug-report.md

added a support type following practices from the kubernetes website , the main idea is to guide end users on how to proceed when having issues. I created this since I saw some issues created that were asking for support.

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign james-jwu for approval. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[varodrig]

@andreyvelich and @hbelmiro to review thank you and anyone else from the community who wants to provide feedback.
Also we need to create new labels before merging. Can you help with this?

" /area model-registry "
" /area notebooks "
" /area spark operator "
" /area trainer "
" /area other "

Created an issue
#3967

[varodrig]

/hold

[varodrig]

cc @kubeflow/kubeflow-steering-committee @kubeflow/wg-training-leads @kubeflow/wg-pipeline-leads @kubeflow/wg-notebooks-leads @kubeflow/wg-manifests-leads @kubeflow/release-team @kubeflow/wg-data-leads @kubeflow/wg-deployment-leads

[hbelmiro]

/lgtm

[varodrig]

/hold cancel

[varodrig]

@hbelmiro @andreyvelich @thesuperzapper can you review?

Thanks.

[varodrig]

/hold

[varodrig]

/hold cancel

[hbelmiro]

/lgtm

[varodrig]

Since this is affecting all Working groups, please review

@hbelmiro @thesuperzapper @rimolive @tarilabs @franciscojavierarceo

[andreyvelich]

@varodrig Would it be better to ask users to open website-related issues in the corresponding GitHub repositories for each project?

From our past experience, WG leads tend to triage issues more effectively in their own repos than in kubeflow/website.
cc @jbottum @rimolive

[varodrig]

@varodrig Would it be better to ask users to open website-related issues in the corresponding GitHub repositories for each project?

From our past experience, WG leads tend to triage issues more effectively in their own repos than in kubeflow/website. cc @jbottum @rimolive

I think the issues should be created and maintain on the same repo the source code lives as software development practice. I think it'll be very confusing to move issues to other repo where the website doesn't belong. What will be the value to community on doing this? it seems to me that it'll add so much confusion. Do we have anyone in the CNCF ecosystem doing managing the website issues this way?

For the WG, they could easy triage the issues with the labels we have created in this same repo, where they can select their respective component. Maybe I'm missing what the problem is and what we are trying to solve?

Can we move this discussion to an issue as well if needed? it shouldn't block this PR since the PR is already using the labels already defined.

cc @thesuperzapper @hbelmiro @tarilabs @juliusvonkohout

[tarilabs]

Thanks @varodrig I think if we want to have templates for the GH Issues in the Website itself, I suppose it's fine as you are showing here.

My optional suggestion is to make it even more clear, in the body of the template, that this requests are intended to address the Website itself, more explicitly in addition to the title.

Example: make a checkbox at the top with text ~like "I acknowledge I am proposing changes to the website itself, and not for an individual component (which should be raised in the appropriate repo instead)"

For a example impacting MR WG, this issue #3969 is borderline between a doc change request for MR WG (which should be raised in the KF/model-registry repo) and a comment to the website itself -- OP created the issue here using the button on the website, despite we have this per KSC request:

I believe @andreyvelich is cautioning about making clear that GH Issues raised here must be pertaining to the Website, not the individual WG, otherwise would be difficult to triage.

[andreyvelich]

What will be the value to community on doing this? it seems to me that it'll add so much confusion. Do we have anyone in the CNCF ecosystem doing managing the website issues this way?

This just what worked for our community before. And from the Working Group point of view the development is going on in their repos, not in the kubeflow/website. Thus, it is easier for them to track all work in a single place:

1. Design Proposal
2. Implementation
3. Tests
4. Doc updates.

Maybe I'm missing what the problem is and what we are trying to solve?

As I said, we don't have anyone who will triage issues in kubeflow/website for now. If you can allocate your time to triage issues to the corresponding Working Group, we should be fine.

[varodrig]

Thanks @varodrig I think if we want to have templates for the GH Issues in the Website itself, I suppose it's fine as you are showing here.

My optional suggestion is to make it even more clear, in the body of the template, that this requests are intended to address the Website itself, more explicitly in addition to the title.

Example: make a checkbox at the top with text ~like "I acknowledge I am proposing changes to the website itself, and not for an individual component (which should be raised in the appropriate repo instead)"

For a example impacting MR WG, this issue #3969 is borderline between a doc change request for MR WG (which should be raised in the KF/model-registry repo) and a comment to the website itself -- OP created the issue here using the button on the website, despite we have this per KSC request:

I believe @andreyvelich is cautioning about making clear that GH Issues raised here must be pertaining to the Website, not the individual WG, otherwise would be difficult to triage.

I think maybe we can clarify that if it's a proposal about a functionality itself should be on the component's repo.
I'll add something like:

"Have a proposal about a component's functionality or feedback on a feature? Submit an issue on any of the kubeflow components on their associated repository https://github.com/kubeflow."

We also have a new issue type which about support to help the community to find support by posting the problem on the right place.
@tarilabs let me know what you think

[varodrig]

@andreyvelich @tarilabs @hbelmiro I'm moving this discussion to a new issue I created

#3988

Thank you