MR docs update #4544
MR docs update #4544
Conversation
|
@dberenbaum, got distracted by other things, updated one page here only today. PTAL, it should be quick enough, and let's align on expectations there. |
Link Check ReportThere were no links to check! |
Sounds goo, @aguschin. Let's not make it close #4423 in that case. |
|
@dberenbaum, I've took into account your review and updated MR use case, and Studio's MR User Guide. It's WIP, so I'll be refining. Please TAL, and let's align on the changes again. Few things to mention:
|
|
Thanks @aguschin! Can we separate the PRs (one for the use case and a follow-up for the user guide)? |
|
@dberenbaum, I moved Use case page changes from this PR to #4548 Let's review both and make them mergeable since @shcheklein promised to a customer we're going to release new MR this week. We can refine content later I think. |
content/docs/studio/user-guide/model-registry/what-is-a-model-registry.md
Outdated
Show resolved
Hide resolved
| 3. Enter the path to `dvc.yaml` the model will be added to. Adding your model to | ||
| non-root `dvc.yaml` can be helpful if you develop this ML model in a specific | ||
| subfolder or if this repo is a | ||
| [monorepo](/doc/studio/user-guide/projects-and-experiments/configure-a-project#monorepo). |
There was a problem hiding this comment.
Is this handled already at the project level? Or are we adding an additional option to pick a subfolder when you add a model?
There was a problem hiding this comment.
Yes, Now in "add a model" user select from views => he's selecting repo + subdir
There was a problem hiding this comment.
Is there anywhere with context about this decision? Why did we decouple it from the project?
| 9. At this point, the new model appears in the models dashboard. | ||
|
|
||
| 9. In your Git repository, you will find that an entry for the new model has | ||
| been created in the `dvc.yaml` file in the repository's root. If you had | ||
| committed to a new branch, a new pull request (or merge request in the case | ||
| of GitLab) will also have been created to merge the new branch into the base | ||
| branch. | ||
| 10. If you had added a model from a cloud storage, the following will also | ||
| 10. In your Git repository, you will find that an entry for the new model has | ||
| been created in the `dvc.yaml` file in the repository's root. If you had | ||
| committed to a new branch, a new pull request (or merge request in the case | ||
| of GitLab) will also have been created to merge the new branch into the base | ||
| branch. | ||
| 11. If you had added a model from a cloud storage, the following will also | ||
| happen before the commit is created: |
There was a problem hiding this comment.
Minor: I don't think these are actual steps, and it makes this list longer than it needs to be. Can we take out the numbering and leave these in as an explanation of what you see after you complete these steps?
There was a problem hiding this comment.
Thanks for changing this @aguschin! Again, this is minor and not a blocker, but you could do the same for the register and assign pages (they include steps that are really about explaining what you see afterwards).
content/docs/studio/user-guide/model-registry/download-models.md
Outdated
Show resolved
Hide resolved
content/docs/studio/user-guide/model-registry/download-models.md
Outdated
Show resolved
Hide resolved
|
Thanks @aguschin! I left a bunch of comments, but I don't think there's anything that's so critical that it has to block the PR, so you and @shcheklein can decide when it's in good enough shape to merge. |
Co-authored-by: Dave Berenbaum <dave@iterative.ai>
|
@dberenbaum thanks for the feedback! Made changes, hopefully it's all good now. I have a single TODO item on my own (store images with dvc), but otherwise we can merge this soon. Let's iterate and get this approved :) |
| following ways: | ||
|
|
||
| 1. Log your model during the training process using [dvclive]. | ||
| 2. Edit `dvc.yaml` directly. |
There was a problem hiding this comment.
| 2. Edit `dvc.yaml` directly. | |
| 2. Edit [`dvc.yaml`](/doc/user-guide/project-structure/dvcyaml-files#artifacts) directly. |
|
One more minor, non-blocking suggestion that isn't directly related to these changes. There are a couple places where it looks like we are focusing too much on GTO CLI over Studio: dvc.org/content/docs/studio/user-guide/model-registry/assign-stage.md Lines 14 to 15 in d67341f In both places, we already mention in the intro that Studio relies on GTO to do these actions, so I think it's already implied that you can use the GTO CLI. Saying it again in these paragraphs makes it sound to me like we recommend the CLI over Studio, but I think it's actually preferable to use Studio unless they have some complex scenario that Studio can't handle. |
There was a problem hiding this comment.
Looks good now @aguschin!
Looks good, thanks for making all those changes! Nothing is a blocker as I mentioned before, so I am approving, but I left a few comments for minor cleanup if you have a chance.
|
@aguschin @dberenbaum what are the blockers here? let's publish it please? |
implements a part of #4423