Proposal: Move Kubeflow projects outside of components section at the website.

[andreyvelich]

Ref discussion: https://github.com/kubeflow/website/pull/3977#pullrequestreview-2584862336

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:

• Argo: https://argoproj.github.io/
• Ray: https://docs.ray.io/en/latest/index.html
• Knative: https://knative.dev/docs/
• HuggingFace: https://huggingface.co/docs/transformers/index

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]

Regarding @thesuperzapper comment: https://github.com/kubeflow/website/pull/3977#issuecomment-2625794720

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:

---

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]

@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]

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 ?

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]

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.

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.

[juliusvonkohout]

I am also in favor of removing abstraction layers where possible.

[tarilabs]

Thank you @andreyvelich for raising about this. Favourable, especially to more easily and readily highlight the constituents of Kubeflow. Maybe just "Kserve" instead of "Kubeflow KServe" ? Or at least in the first page highlight what is intended for "Kubeflow KServe"

[andreyvelich]

Favourable, especially to more easily and readily highlight the constituents of Kubeflow. Maybe just "Kserve" instead of "Kubeflow KServe" ? Or at least in the first page highlight what is intended for "Kubeflow KServe"

I just wanted to keep branding consistent across all projects from the Kubeflow Ecosystem. The Kubeflow KServe page should just redirect users to the official KServe documentation: https://kserve.github.io/website/0.10/

But if KServe contributors don't want us to put Kubeflow KServe in the website outline, we can keep it as KServe. @yuzisun @johnugeorge @terrytangyuan @sivanantha321 Any thoughts on this ?

[thesuperzapper]

Either way, I still want to highlight what I was saying in https://github.com/kubeflow/website/issues/3982#issuecomment-2629155715.

If we decide to split out the component docs, we should do if "virtually" in the sidebar html template, so we don't have to have to change the http paths by actually moving the markdown files.

[varodrig]

/area website

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[andreyvelich]

/remove-lifecycle stale