Photo by Aliaksei Semirski on Pexels. We’ve all been there. The team is firing on all cylinders, cranking out innovative new features. The documentation is perfect! It’s comprehensive, clear, and included right in the Pull Request. Then, six months later, a bug report comes in. Somewhere along the way, a developer changed a timeout value, renamed a key in a JSON response, or updated a UI label, and…the documentation didn’t move an inch. ...
Photo by Pixabay on Pexels. AI tools are everywhere in documentation conversations right now, but most of the discussion stays abstract. This is a concrete account of how I integrated Claude into MinIO’s documentation workflow: what I used it for. how I structured that use. what it measurably changed about how the team worked. The Starting Point Technical documentation for a product like MinIO lives close to the codebase. Keeping it accurate means tracking software releases, triaging GitHub issues, auditing existing content, and staying current with a fast-moving engineering team. All while writing new content and updating existing content. The surface area is large and the feedback loops are long. ...
Modernizing Documentation at Cloud Scale In the world of high-performance distributed systems, documentation is more than just a manual. Instead, the docs serve as a critical component of the user’s infrastructure. During my tenure as a Senior Technical Writer at MinIO, I transitioned from being a content creator to a “Documentation Architect.” My GitHub contributions reflect the level of work: My GitHub metric contributions for the year leading up to February 2026. ...
MinIO introduced a new feature to AIStor for taking a node offline for maintenance. For this feature, I needed to explain how the feature works. As an AIStor feature applicable both in Kubernetes and non-Kubernetes environments, it was also important to distinguish it from the similar kubectl cordon functionality system administrators would also be familiar with. Some notes: The quote block text used a shortcode in the theme we used to create admonitions. For the diagram, I used a skill another team member had created for Claude to use for creating SVG diagrams. Links in the text here are intentionally broken, but would have cross-linked to other pages in the docs. AIStor allows you to temporarily remove nodes from active service for planned maintenance operations. Removing nodes allows administrators to gracefully take nodes offline without disrupting cluster operations, similar to the cordon functionality in Kubernetes. A cordoned node finishes in-flight operations and marks itself as unavailable for any other operation. Use this to do hardware maintenance on a node, complete operating system updates, or perform troubleshooting. ...
MinIO Warp is an open-source tool for testing storage performance. It allows you to plan capacity and make sure the infrastructure meets requirements. After MinIO’s migration to Hugo for documentation, I went about the task of adding documentation for Warp that previously only existed in the upstream code repositories. This particular document covers two types of tests Warp provides. I put it together using some existing documentation and code examples in the repository combined with a deep dive analysis of the code using Claude, a review by a MinIO team member that uses the product regularly during support calls, and my own testing. ...
In planning out a new feature, the Product Manager wrote out an issue card in GitHub for developers to reference. The card included the PM’s notes from visits on site with customers. I updated the card by: Removing extraneous verbiage Adding sections and rearranging content Updating references to existing product features Some portions of the issue make sense within the broader product portfolio. Those have been left without further explanation in the edited card, as such additional information is already known to the development team. ...
About this sample The information below is about a fictitious software product, “Assetly.” I based Assetly on a real product I documented, though many details have changed in this document. I wrote the original product document in Madcap Flare in consultation with a number of subject matter experts, including: Product Manager Developers Quality Assurance team Sales team members who championed the product Product Team Executives This sample reimagines the original document, now written in Markdown for use in this blog. ...
About this sample The information below is about a task a user would need to complete in a fictitious software product, “Assetly.” I based Assetly on a real product I documented, though many details have changed in this document. I wrote the original document in Madcap Flare based on my own use of the software. During my use of the real product, I occasionally uncovered bugs or more complicated problems. When discovered, I created issue cards in the development team’s issue tracking system. ...
About this sample For a job application process, I was asked to revise a sample business requirements document. The provided example was a template purporting to be notes from several different meetings. I left the headings from the template as they were, but edited and formatted the contents of each section. While the original sample was done in Word, I have recreated it here with Markdown, published by my SSG, Hugo. ...
My first job at a software company landed me in a software training role. While I learned a great deal about adult learning and best practices for knowledge transfer, my proudest achievement while I was there involved project management. Our department had a catalog of 160 course manuals. These manuals varied in length from 20 pages to several hundred pages. These were course guides for the various training classes taught by everyone in our department. ...