Update the page of interactive tutorials #785
Conversation
| - [dvcignore](https://katacoda.com/dvc/courses/examples/dvcignore) <br/> | ||
| Sometimes you might want DVC to ignore some files while working with the | ||
| project. To address this, DVC supports optional `.dvcignore` files, which have | ||
| the same syntax and work similarly to `.gitignore` in Git. | ||
|
|
||
| - [dvc fetch](https://katacoda.com/dvc/courses/examples/fetch) <br/> We will use | ||
| an example project with some data, code, ML models, pipeline stages, as well | ||
| as a few Git tags. Then we will see what happens with dvc fetch as we switch | ||
| from tag to tag. | ||
|
|
||
| - [SSH Remote DVC Storage](https://katacoda.com/dvc/courses/examples/ssh-storage) | ||
| <br/> In this example we assume a central DVC storage server that can be | ||
| accessed through SSH. For the sake of example the central Git repository is | ||
| located in the same server too, but in general it can be anywhere. | ||
|
|
||
| - [Shared Server](https://katacoda.com/dvc/courses/examples/shared-server) <br/> | ||
| Some teams may prefer using one single shared machine to run their | ||
| experiments. In this example we will see how two different users on the same | ||
| host can share data with the help of a local data storage. | ||
|
|
||
| - [Mounted DVC Storage](https://katacoda.com/dvc/courses/examples/mounted-storage) | ||
| <br/> In this example we will see how to share data with the help of a storage | ||
| directory that is network-mounted through SSHFS. Once you understand how it | ||
| works, it should be easy to implement it for other types of mounted storages | ||
| (like NFS, Samba, etc.). | ||
|
|
||
| - [Synchronized DVC Storage](https://katacoda.com/dvc/courses/examples/synced-storage) | ||
| <br/> In this example we will see how to share DVC data with the help of a SSH | ||
| server and `rsync`. Actually there are better ways to use a SSH server for | ||
| data sharing, but we are using it just as an example. Once you understand how | ||
| it works, it should be easy to implement it with other storage types and | ||
| synchronization tools. |
There was a problem hiding this comment.
In general, these example descriptions feel a little long to me. If possible further summarizing would be nice, assuming they're further explained once you open them.
Also, I think most or all of these dscriptions could have links to internal documens like Dvcignore guide, dvc fetch command ref., etc.
There was a problem hiding this comment.
In general, these example descriptions feel a little long to me. If possible further summarizing would be nice, assuming they're further explained once you open them.
The purpose of these descriptions is to give an idea of what the example is about. So, the explanation that is shown once you click on them doesn't count (you should get an idea before clicking on them).
Also, I think most or all of these dscriptions could have links to internal documens like Dvcignore guide,
dvc fetchcommand ref., etc.
I think this would be distracting and not useful.
There was a problem hiding this comment.
However, given that these examples are also referenced from other pages (such as user guides etc.) I wouldn't mind if these descriptions could be made shorter or more compact.
There was a problem hiding this comment.
I wouldn't mind if these descriptions could be made shorter or more compact.
Great, please try.
this would be distracting and not useful
Its just blue text. People can decide to click or not, if they are interested in interactive stuff, they'll click on the link to Katacoda. If they're more interesting in the theory, they'll click on the links to our other refs. Links are useful for people to find further content about topics they're interested on. You know... The purpose of hypertext 😋
There was a problem hiding this comment.
Great, please try.
I thought that you would give it a try, since you prefer them to be more compact. As far as I am concerned descriptive descriptions are Ok :)
There was a problem hiding this comment.
Sorry, I think you are confused. The process as I understand it is that you (or any collaborator) submit changes, they are reviewed (in this case that is my role here), changes are requested, the collaborator address them, we iterate. Once accepted, we merge. Unfortunately I have many other issues to work on and can't prioritize helping you on this one at this time. Thanks
No description provided.