Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal to move issues related to components to the components repository and not website repository #3988

Open
varodrig opened this issue Feb 7, 2025 · 1 comment

Comments

@varodrig
Copy link
Contributor

varodrig commented Feb 7, 2025

I'm creating this issue on behalf of @hbelmiro and with the aim of helping facilitate the WG triage issues but also keeping the community in mind if we do this change.

From @hbelmiro

he's proposing to move the issues related with Pipelines to the pipelines repository. Here is some examples:

  • The page "how to compile a pipeline" tells users to use a deprecated function - this should be in the pipelines repo
  • The page "how to compile a pipeline" has a broken link - this should be in the pipelines repo
  • The page "How to get started with notebooks" has a broken link - this should be in the notebooks repo
  • The "Future Events" page includes an event that already happened - this should be in the website repo
  • Menus are not rendering correctly in - this should be in the website repo
  • Add a new distribution to the distributions page - this should be in the website repo

Comments from PR #3964

From @andreyvelich
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

From @tarilabs

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:
Screenshot 2025-02-06 at 09 36 20

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.

from @varodrig
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.

@varodrig
Copy link
Contributor Author

varodrig commented Feb 7, 2025

my proposal is to keep the issues related to content in the website repo and the ones related to component's functionality or feedback on a feature should go into each component's repo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant