Adding "synced" prefix
I was totally confused on where I was supposed to put the .stignore file and treated it like a .gitignore file that can be placed in any folder-level-hierarchy and lower hierarchies overwrite higher hierarchies. I was not aware that I need to put the .stignore file into the synced folder's root.
Three things would have helped me understand better:
- Backlinks: Actually linking the "getting started" page that would help me understand concepts. There are rarely links in between docs articles
- Using a custom term for a "Syncthing synced folder" (just like we have a "Dropbox folder" or a "OneDrive folder") - I know it can be multiple folders that are synced, it is still a special thing. The documentation and everything else always just talks about "folders" (and sometimes "directories" interchangeably, maybe also something to be improved?) - a Syncthing folder is not just any folder in the system, it is treated differently hence makes it a "Syncthing folder" or "synced folder" or whatever you want to call it
- Have the
.stignorefile included in the directory structure so I would see where it goes
Deploy request for syncthing-docs pending review.
Visit the deploys page to approve it
| Name | Link |
|---|---|
| Latest commit | 7db06497a3d6f5c945e33f9a6d257516e946ac87 |
I agree the terminology can be clearer, but we generally mean "Syncthing folder" by "folder", and use "directory" for meaning just any directory on disk. Hence the "at the root of the folder" in the thing you're editing.
Not a fan of "synced folder" personally, as I can very well edit .stignore before even sharing the folder, i.e. in the "unshared" state. There's nothing "synced" about it at that point yet. "Syncthing folder" is indeed very clear and specific, but changing all instances of "folder" to "Syncthing folder" would be very repetitive…
How about adding a short glossary to the Docs welcome screen that would very briefly explain the main concepts (e.g. folder, device, directory, etc.).
:robot: beep boop
I'm going to close this pull request as it has been idle for more than 90 days.
This is not a rejection, merely a removal from the list of active pull requests that is periodically reviewed by humans. The pull request can be reopened when there is new activity, and merged once any remaining issues are resolved.
I have nothing against rejecting this pull request, but just closing it due to inactivity I think is counter productive.
I think there is an outstanding point that needs to be addressed before this can be merged.
Do you plan on addressing it?
You are right, I didn't know that I was the one who had to commit that suggestion, thanks for bringing it to my attention.