-
Notifications
You must be signed in to change notification settings - Fork 12
Conversation
Link Check Report
2/24 links failed. |
Great Qs cc @aguschin . Relates to discussion in #58 (comment) (in fact this PR may close that issue). |
For the record, what I originally recommended was similar:
Though I also think that the saving part is pretty good for the index of the section, as is now. (Does that answer "where should I start?" or do we mean"where to go after saving?") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the saving part is pretty good for the index of the section, as is now.
Comparing with the new index page, my conviction that the existing one is preferable increases. Specific reasons:
I love the intention in this PR however other than the changes I reviewed above, we're mainly regrouping existing content. The grouping is probably good but should be combined with summarizing things because in this proposal one of the pages is pretty short and the second one kind of long (they don't seem to be at the same conceptual level). We also add notes and paragraphs making it even longer which worries me. Get Started's are tricky 😓 |
This comment was marked as resolved.
This comment was marked as resolved.
### Why do it the MLEM way | ||
|
||
Saving models to files or loading them back into python objects may seem like a | ||
deceptively simple task at first. For example, `pickle` and `torch` libraries | ||
can serialize/deserialize model objects to/from files, but we will see that MLEM | ||
adds some "special sauce" in the form of metadata files that will help us a lot | ||
down the line in the heavier operations like packaging and serving of the models | ||
in various ways. MLEM allows us to automate a lot of the pain points we would | ||
hit later on in our ML workflow by codifying metadata about your models (and | ||
other objects) and intelligently using it later on. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also add notes and paragraphs making it even longer which worries me
@jorgeorpinel, does your comment refers to the sections like these? I understand your intention, but I think those make things much clear. Besides, we "sell" MLEM. We can hide them in <details>
as an option, but I believe these can be very helpful. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also add notes and paragraphs making it even longer
does your comment refers to the sections like these?
Yes. The intention is good but we need the GS to be as brief and direct as possible. If we need to clarify something with an entire new section then it probably wasn't written properly in the first place (or there's an underlying product design issue).
p.s. sorry for late reply. Will check #238 post-merge.
b2732cb
to
86cd744
Compare
https://mlem-ai-simplify-get-st-gwz7i9.herokuapp.com/doc/get-started
I've identified some issues which in my mind make the get started not as appealing and simple to understand as it could be
The get started workflows today are "actions" - applying/serving/building/deploying. New users might not understand what those mean, in what order should they "put the pieces to gether" and this might lose apeal.
Some questions I can imagine here for new ysers:
"productionization" term is not a clear / common enough in my mind. It's a big catch-all term. it's the umbrella for all current get-started guides.
My Suggestion here - let's have full scenarios drive the GS structure - so less scenarios (2), more stages in each
Suggested Structure: