-
Notifications
You must be signed in to change notification settings - Fork 394
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
READMEs vs Docs #2443
Comments
LGTM! :) |
Great proposal! I have two questions:
What is the goal of the features page? It's been previously discussed that the existing dvc features page may not be that useful. Maybe we can take a look at the popularity of this page and decide whether the current format is useful.
Does this mean something like https://github.com/iterative/dvc#comparison-to-related-technologies, where there is a link to each related technology and a short explanation of how it relates? Does it mean a link to a docs page that explains how the product relates to other technologies? I lean towards leaving this out of the README and having a separate doc comparing technologies (if needed) to keep the readme shorter and to allow for a more in-depth comparison elsewhere. Some examples: |
Anything which doesn't exclusively target devs (i.e. purely marketing material targeting managers, and possibly also devs)
yes
That sounds like something for the bottom of the "features" page. Wouldn't necessarily mention it in the README. |
We can probably keep further discussion of the features and related technologies in separate tickets since there seems to be agreement that they don't belong in the readme, or at least should be as minimal as possible there. |
Great topic!
We have been considering merging that with the Use Cases (currently inside docs but unclear whether they belong there), and instead have visual-oriented "features" right in the home page (which we already try to do in dvc.org/, see below). Also the Get Started has an overview of DVC features... But maybe we should further extract this part of the discussion? Rel. #144
Minor: I would personally prefer /docs but lost that battle some time ago ⚔️
Another minor note: guides aren't really tutorials (not meant to be, at least), they're more of an explanation-type doc (ref) and sometimes have even deeper details than the references. Agree about README contents in general 👍 (links may vary as needed)
Wouldn't your proposal imply creating cml.dev/doc to put guides and refs in? |
Sure, I don't have strong opinions on
Yes, but only minimally as an augmented table of contents for its main purpose (i.e. getting started ToC rather than feature overview).
The main point of this issue is about what to put in READMEs. I only mention websites as tangential to prompt ideas. #144 is so longstanding I'm surprised that the tangential discussion here seems to be largely in agreement solving it :)
I don't mind. Slight preference for shorter URLs.
idk what the original plan was, but they look like what I call "advanced tutorials" to me at the moment. Based on the divio ref link, this would be currently labelled "How-Tos" rather than "Explanations." Also in terms of importance I'd say "How-To" is much more important to have than "Explanation," which may be why the original plan wasn't adhered to.
Yup. Working on it. |
We have a how-to section https://dvc.org/doc/user-guide/how-to/stop-tracking-data BTW
There was no original plan, we're improving as we go. The current intention is that Guides contain explanations
Why? Interested in your fresh perspective |
People are much more likely to first ask "How can I solve my problem?" (How-To) rather than "Thanks for solving my problem - how exactly did your solution work, btw?/I'm having an existential crisis. Why does my problem exist?/Where do we come from?/What is the meaning of life, the universe and everything?" (Explanation). |
I'd prefer to know the meaning of life TBH. Otherwise yes, How-tos should get more quick traffic for sure: basically a support FAQ I guess? BTW should we merge this issue with #2433? |
yeah, I like explanations too but I don't think the rest of the world has the same priorities.
I think #2433 is a DVC-specific part of this (more general cross-project) issue so wouldn't merge it. I'd add an |
Good idea, either |
BTW (if this is an epic), is this related too? #234 |
This comment has been minimized.
This comment has been minimized.
Henlo We recently discussed this (and closed #2433) so I wanted to restart the conversation so we have a plan of action with the different core teams that maintain the product repos, starting with @casperdcl's proposal is to follow the pattern in https://github.com/iterative/terraform-provider-iterative#readme:
My feedback on that README is that Also I'd propose adding a ToC near the top if we're going with a long format. Thoughts? |
I would say "my" proposal (with lots of feedback & iterations with @dmpetrov) is: AS COMPLETE_AND_CONCISE AS POSSIBLE, assume readers lack patience no-scroll:
scroll down:
disagree - the "Features" completely describe the solution, and capture attention of appropriate users (acquisition). The "USPs" describe why no other solution is better (retention).
there's a docs website for everything (incl for TPI) but the point is to put a minimal reference in the readme. Links are fine but there should also be a concise summary in the readme for local devs who hate websites (there are a lot).
GH auto-generates ToC - we don't need to add this explicitly. |
I think it should be something like workflows rather than features. We should be focusing on how users interact with the product. |
that... would be "Use cases" instead of "Features?" idk if it's possible to cram all the use cases into the top of the readme. Would be great if possible. Was thinking use cases could be part of Examples further down... |
If we consider Features as on this page https://dvc.org/features then I would prefer to have a short list of Use cases instead, features are not very meaningful if I don't understand why would I want to use the tool. And to clarify, even an entry paragraph can answer "why use it" question. |
I was thinking somewhere in between. Since we are building modular tools, it should be possible to have a paragraph or a few bullets to explain the basic expected workflow. Related:
Yeah, makes sense. IMO the intro should be a lower level explanation of how to interact with the tool, and use cases might still be relevant to describe different high-level scenarios. For TPI, I would expect the intro to be about how to train/run ML jobs in the cloud, while lower down would be use cases like remote Jupyter notebooks. |
To summarize
No-scroll
Scroll
Other notes like current state or future roadmap can be added as needed, we don't need to plan for it in this template. |
Are there org-level issues/discussions? This goes beyond DVC at this point. For now I updated the task list at the bottom of the OP desc ☑️ ☑️ ☑️ |
seems impossible sans diagrams. Spacing would have to be:
|
I just don't think we can expect mandatory diagrams in every README.
It's a separate item in my list but can be in the same paragraph of course. I just wanted to emphasize not to forget this. |
* readme: make intro = value prop + + fancy note * readme: spave between VS and Code per #1816 (review) * readme: reorg existing content per per iterative/dvc.org#2443 (comment) * readme: add features list * readme: extend/fix/link other parts of the structure * readme: fix DVC icon * readme: value prop edited from https://docs.google.com/document/d/10THN0WwvPaDOAnmWd37xMOSWftJrUSIPlA2m0iHGDNI/edit# per #1816 (comment) * Update README.md Co-authored-by: Dave Berenbaum <[email protected]> * Update README.md * readme: rewrap * readme: add list of high-level features from https://docs.google.com/document/d/10THN0WwvPaDOAnmWd37xMOSWftJrUSIPlA2m0iHGDNI/edit# * readme: update features and add competitive advantages based on https://docs.google.com/document/d/10THN0WwvPaDOAnmWd37xMOSWftJrUSIPlA2m0iHGDNI/edit# * readme: mention that it's beta per #1816 (comment) * readme: small improvements to lists * readme: better Quick start * readme: populate Config section * readme: move Useful commands before Config * config: update settings descriptions (readme and package) * contrib: copy edits * readme: fix vs-code commands lnk * contrib: kill link to wiki (outdated) * readme: lint (BROKEN) * Update README.md Co-authored-by: mattseddon <[email protected]> * Update README.md Co-authored-by: mattseddon <[email protected]> * fix linter-broken line * contrib: simpler dev env steps * readme: better intro wording per #1816 (review) * readme: plots view -> dashboard :/ per #1816 (comment) * readme: support should go to Discord first per #1816 (review) and #1816 (review) * readme: exp bookkeeping -> tracking per #1816 (review) * readme: clarify reproducibility feature per #1816 (review) * readme: more specific data mgmt use per #1816 (review) * readme: improve UI components list per #1816 (review) * readme: fix img hack may not work until repo goes public * add badges to README * drop some badges * preview banner * update link to point to main * preview gif * readme: impro feats * contrib: move note about DVC projects * revert to changelog from main and add prettier rule * Update README.md Co-authored-by: mattseddon <[email protected]> * readme: move animation after value prop paragraph * Apply suggestions from code review Co-authored-by: mattseddon <[email protected]> * Update README.md * Restyled by whitespace * Restyled by prettier-markdown * Update README.md * contrib: valid md new line >:( * readme: move images to extension/images and and add screenshot of Get Started page * readme: move images back to extension/docs/ foler per #1816 (review) * swap banner to png * replace outdated walkthrough screenshot * update style of inline dvc png so it does not look bonkers * (fixup) use absolute links for the marketplace and in product Co-authored-by: Dave Berenbaum <[email protected]> Co-authored-by: mattseddon <[email protected]> Co-authored-by: Matt Seddon <[email protected]> Co-authored-by: Restyled.io <[email protected]>
Interesting guidelines: https://github.com/ddbeck/readme-checklist (via @omesser thanks) |
about READMEs, I like the minimal one from deno, i.e.:
|
I think a lot of things here have been done. Closing this. I put a link in Notion to this dicussion. |
We need to decide on a clear scope of README files (and, ahem, cough, cough docs). Right now, https://dvc.org/doc/cml is just a mirror of https://github.com/iterative/cml meaning a lot of duplication - but there may be more things which need addressing too. Related: #2433.
My personal preference is:
I think most agree that https://dvc.org/doc/cml should be a one page blurb containing links to cml.dev
DVC README #2433
DVC badge #234
docs: (re)structuring cml#514
docs: fix README and create documentation entry for dvclive dvclive#45
DVC.org website docs: "definitive" organization #144Update README.md mlem#220
Update README.md gto#149
README rewrite (+ CONTRIB updates) vscode-dvc#1816
The text was updated successfully, but these errors were encountered: