]> BookStack Code Mirror - website/commitdiff
Rough initial draft of documentation methods post doc_method_post lahoje/doc_method_post twindscheif/doc_method_post
authorDan Brown <redacted>
Wed, 24 Aug 2022 14:49:34 +0000 (15:49 +0100)
committerDan Brown <redacted>
Wed, 24 Aug 2022 14:49:34 +0000 (15:49 +0100)
content/blog/interesting-methods-of-documentation.md [new file with mode: 0644]
static/images/blog-cover-images/writing-rafael-leao.jpg [new file with mode: 0644]

diff --git a/content/blog/interesting-methods-of-documentation.md b/content/blog/interesting-methods-of-documentation.md
new file mode 100644 (file)
index 0000000..425b63e
--- /dev/null
@@ -0,0 +1,45 @@
++++
+categories = ["Community"]
+tags = ["Documentation"]
+title = "Interesting Methods of Documentation"
+date = 2022-08-24T20:00:00Z
+author = "Dan Brown"
+image = "/images/blog-cover-images/writing-rafael-leao.jpg"
+slug = "interesting-methods-of-documentation"
+draft = false
++++
+
+TODO - Update post image
+
+As the maintainer of a documentation platform, I find myself taking a particular interest into the exact methods of how people go about creating documentation. 
+I this post I'd like to step out the specific context of BookStack and take a look at a few interesting methods of documentation that have piqued my interest.
+
+### Jeff Geerling - GitHub Issues
+
+Jeff Geerling, commonly known for his Raspberry Pi and Ansible expertise, is what I'd consider a master community documenter on many fronts. He's published books, produces videos and maintains a blog; All rich with valueable documentation content.
+
+An additional method that Jeff uses, which I want to specifically look at here, is documenting through GitHub issues. As Jeff works on a project he'll open an equivilent GitHub project, then open issues for specific problems he comes across, then update that issue with information as he progresses. This essentially provides a timeline of how particular tasks are worked through, while also providing an open location for community input & feedback.
+
+Many projects use something like GitHub issues, of which can build as a repository of documentation over time, but the difference here is that it's the project author themselves going the extra mile to write clear detail for others to consume. Jeff will often reference one of his issue pages within his videos, and I notice a keen sense of pride when he does this which I love to see.
+
+### Wendell from Level One Techs - Forum Posts
+
+Wendell is well known in the YouTube tech space for his Computer Tech and Linux knowledge mainly relayed through the Level1Techs and Level1Linux YouTube channels.
+While watching his videos, I've been intrigued by his referencing of forum posts.
+
+The Level One team maintains an active forum for their community.
+When working on a solution, Wendell will often document the process within a forum post, as can be [seen in this example](https://forum.level1techs.com/t/truenas-scale-ultimate-home-setup-incl-tailscale/186444).
+Much like Jeff's GitHub issues, this provides opportunity for community interaction and involvement which can add further value in itself to future readers. 
+Compartively, I think posting within a forum in this manner has a double benefit of adding value directly the community, to help it grow, while putting the content directly into the view of an active audience.
+
+### Video Guides
+
+The value of video to document processess is well established, with both of my previous examples featuring great examples of video-based documeters. 
+It's only since I've been making videos myself for BookStack that I've come to understand their value from an author's perspective. The ability to send someone a timestamped video link, showing the steps or process they need to follow, has been extremely handy for me, especially for more complicated subjects. 
+
+I think video has a lot of value in being able to visually provide a lot of context very quickly, which you'd have to otherwise establish with a lot more text in written content, adding a little more friction. Being able to look back on a full end-to-end process, with every detail included, provides the entire picture compared to which is essentially a second-hand abstraction with written content. For example, If an interface has changed since the documentation has been made, that's instantly visible within a video wheras, unless that has been specifically screenshotted, such as change can add a significant poiint of confusion in written content.
+
+----
+
+<span style="font-size: 0.8em;opacity:0.9;">Header Image Credits: <span>Photo by <a href="https://unsplash.com/@raflfc?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Rafael Leão</a> on <a href="https://unsplash.com/s/photos/writing?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a></span></span>
+  
\ No newline at end of file
diff --git a/static/images/blog-cover-images/writing-rafael-leao.jpg b/static/images/blog-cover-images/writing-rafael-leao.jpg
new file mode 100644 (file)
index 0000000..7fe1c53
--- /dev/null
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:efc2f21ef206da37f913d5b60682f4ab1099eb36d15a6553805b60236ab1ffe4
+size 455120