refactor docs structure #77
Conversation
There was a problem hiding this comment.
This looks great!
One nitpick is should we check the images into the repo? One concern I have always had about this practice is that these images may be updated pretty frequently, but they will stay in the history of the codebase forever, making the size of the codebase unnecessary large. Personally I think that uploading them to GitHub issues (without creating the issue) and reference the links generated by GitHub is better.
|
My main problem with the GitHub links was the lack of a file-like management system or an easy way to tell which files were which. I ended up uploading to a stoat-dev/static directory on the s3 bucket so they can be accessed with: Then we have an understandable URL, we store the images by reasonable names, and we have a place where we can update images in place and have them appear in docs if we want a new version. |
Refactor our docs to separate out pitching to different personas, core concepts, and use-case-based tutorials. Also quite a few cleanups.