Update pyproject.toml project links #40
Conversation
Signed-off-by: Saad Zaher <szaher@redhat.com>
google-oss-prow
bot
requested review from
Electronic-Waste,
andreyvelich and
astefanutti
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Electronic-Waste 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:
Approvers can indicate their approval by writing |
| Documentation = "https://www.kubeflow.org/docs/components/trainer/" | ||
| Source = "https://github.com/kubeflow/trainer" | ||
| Homepage = "https://github.com/kubeflow/sdk" | ||
| Documentation = "https://www.kubeflow.org/docs/components" |
There was a problem hiding this comment.
Should we plan to add a dedicated section for the SDK in the doc?
There was a problem hiding this comment.
Currently, we planned to add SDK related section in each component (like "how to use BuiltinTrainer" in kubeflow/trainer#2401 (comment)). But I think it should be a great idea to add a dedicated section for SDK in the doc. Since users do not care about the component they use, they only care about how to use it.
There was a problem hiding this comment.
Actually, I feel that we should use the project docs for the SDK for now.
Given that SDK is a primary interface for users to interact with Kubeflow projects APIs, why do we want to separate them in the website ? For example, KFP doesn't separate SDK docs from its section.
SDK implements various clients to talk to Kubeflow projects (e.g. TrainerClient, PipelinesClient, OptimizerClient), so users understand with which project they interact with, and know which docs to check.
Additionally, since we say that Python SDK is the primary interface for Kubeflow Trainer, all of the users guides will be using the Kubeflow SDK: https://www.kubeflow.org/docs/components/trainer/user-guides/
We should also talk about it during our Training WG call.
There was a problem hiding this comment.
I agree that we should have a dedicated SDK section once we're ready for the first SDK release. We'll need a central place to provide an overview of the Kubeflow SDK, what components are included, installation steps and links to each component's user guides. I'm not saying we duplicate content or separate the SDK docs from their components, but we should create one main place where users can start.
We want to promote adoption and if someone asks "how do I get started with the Kubeflow SDK" we don't have a clear page to point them to. Do you want to point them to README from SDK repo instead?
Dedicated SDK section will be a starting point to help users understand the scope and capabilities of the SDK before they dive into specific component documentation.
+1 to discuss this during Training WG call
5 participants
What this PR does / why we need it:
Fix Links in pyproject.toml to point to this repo
Which issue(s) this PR fixes (optional, in
Fixes #<issue number>, #<issue number>, ...format, will close the issue(s) when PR gets merged):Fixes #
Checklist: