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: Move Kubeflow projects outside of components section at the website. #3982

Open
andreyvelich opened this issue Feb 1, 2025 · 4 comments

Comments

@andreyvelich
Copy link
Member

Ref discussion: #3977 (review)

I propose moving Kubeflow projects out of the components section to enhance their visibility in the website outline.
From my point of view, adding another level to the outline offers no clear benefit, even if more projects will join Kubeflow ecosystem in the future. Moreover, since KFP and Kubeflow Trainer already defines a Component concept, this change will help reduce user confusion.

About
Getting Started
Kubeflow Notebooks
Kubeflow Model Registry
Kubeflow Spark Operator
Kubeflow Trainer
Kubeflow Katib
Kubeflow KServe
Kubeflow Pipelines
Kubeflow Dashboard
Distributions
Releases / Kubeflow Platform Releases

Looking at other projects, every sub-project has clear representation at the website outline:

Please let us know what do you think ?
@kubeflow/wg-pipeline-leads @kubeflow/wg-data-leads @kubeflow/kubeflow-steering-committee @StefanoFioravanzo @juliusvonkohout @franciscojavierarceo @kubeflow/wg-training-leads @kubeflow/wg-notebooks-leads @varodrig @hbelmiro @jbottum @kubeflow/wg-manifests-leads @astefanutti @saileshd1402

@andreyvelich
Copy link
Member Author

Regarding @thesuperzapper comment: #3977 (comment)

It will just clutter the website and make it harder to browse, especially as we add more components.

Why it is clutter the website ? Even today if user wants to check docs for any project, they will see all components at the left side:

Image


There are also technical reasons why it would be ill-advised, mainly around the fact that the HTTP paths come from the folders, and historical redirects.

Can you explain more please ? Every project will still have dedicated folder under /docs path.

@thesuperzapper
Copy link
Member

@andreyvelich can you clarify what your goal with this change is?

If your issue is just highlighting the components more, we can probably just change the way we display the components section on the sidebar (visually, without moving the files).

E.g. we could move them under a heading similar to how there is a "documentation" heading at the top with an underline right now.

I think your current proposal will just make it harder to find the non-component sections (e.g. "about", "getting started", "external add-ons" and "releases").

@andreyvelich
Copy link
Member Author

andreyvelich commented Feb 2, 2025

The goal is to highlight the documentation section for Kubeflow projects since these are the most important sections user should look into.
As I mentioned, many other communities which have multiple projects under same ecosystem (e.g. Ago) do the same.

E.g. we could move them under a heading similar to how there is a "documentation" heading at the top with an underline right now.

Do you mean always keep components section expanded, like how Istio is doing it ?
Image

I think your current proposal will just make it harder to find the non-component sections (e.g. "about", "getting started", "external add-ons" and "releases").

I don't think these are essential sections users should look into at the website. About and Getting Started stays at the top, so if they want to just understand What is Kubeflow, they can always jump into it.

Also, I would prefer to remove external add-ons, since we don't have clear ownership of these docs and it is hard to maintain them.

The release, I think we should rename it to Kubeflow Platform Releases to make it clearer.

cc @rimolive @kubeflow/release-team

@varodrig
Copy link
Contributor

varodrig commented Feb 3, 2025

Thanks @andreyvelich for creating this issue. I think this discussion is interesting, my two cents on this:

1- I like the idea of making the components more accessible and removing some menu options to make it more user friendly. Looking at at the Kubernetes website, they have everything under Concepts.

Image

2- However, I do have concerns since I think the components is also a way for us to articulate that the kubeflow is composable.
but nothing stop us to continue this messaging in other sections.

I want to add these two perspectives into the conversation.

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

3 participants