Select­ed sam­ples of my tech­ni­cal writ­ing and doc­u­men­ta­tion archi­tec­ture work for Red Hat Satel­lite and CZ.NIC FRED. Each sam­ple explains its audi­ence, pur­pose, my con­tri­bu­tion, and the deci­sions behind it, from orga­niz­ing whole guides to explain­ing sys­tem behav­ior and doc­u­ment­ing tasks and inter­faces. Doc­u­men­ta­tion excerpts are pre­served as snapshots.

Overview

Red Hat Satel­lite: Guide restruc­tur­ing · Light­speed overview · Image Builder provisioning

CZ.NIC FRED: Doc­u­men­ta­tion archi­tec­ture · Non-domains obso­le­tion · Prepar­ing reg­is­trars · EPP: Cre­ate domain

Oth­er: Con­fer­ence presentations

Technical Writing for Red Hat Satellite | 2022–2026

I improved the struc­ture and con­tent of doc­u­men­ta­tion for Red Hat Satel­lite and its upstream com­mu­ni­ty project, Fore­man. My work includ­ed guide restruc­tur­ing, con­cep­tu­al expla­na­tions, and pro­ce­dures, with pri­or­i­ties agreed with Satel­lite prod­uct man­age­ment and Cus­tomer Con­tent Services.

Method­ol­o­gy: Sin­gle-sourced, mod­u­lar docs as code, pub­lished through CI/​CD pipelines to HTML and PDF.

Tool­ing: Asci­iDoc, VS Code/​Cursor, Git, GitHub, Git­Lab, Jira, Bash script­ing, and Claude Code.

Sup­port­ing links: Fore­man doc­u­men­ta­tion · My pull requests on GitHub · Ref­er­ences

Restructuring a guide

Audi­ence: Sys­tem admin­is­tra­tors, espe­cial­ly those new to host provisioning.

Pur­pose: Make the required prepa­ra­tion and order of pro­vi­sion­ing tasks clear.

Start­ing point: The guide made it dif­fi­cult to deter­mine which pro­ce­dures to fol­low at what moment and what had to be pre­pared before cre­at­ing hosts. Some impor­tant pro­ce­dures were lost in large chap­ters. Some head­ings were too tech­ni­cal for beginners.

My con­tri­bu­tion: Owned the table of con­tents redesign and con­tent restruc­tur­ing. Devel­op­ers reviewed tech­ni­cal and ter­mi­no­log­i­cal accu­ra­cy; peer writ­ers reviewed clar­i­ty and style.

Approach: Reor­ga­nized the con­tent to fol­low the sequence in which users need­ed to per­form tasks, plac­ing prepa­ra­tion before host cre­ation. Sim­pli­fied head­ings and made them more descriptive.

Com­par­i­son: Tables of con­tents from Satel­lite 6.15 and 6.19. The lat­er release also includes con­tent updates beyond this restructuring.

➚Open sam­ple as a page

Archived snap­shot, retrieved 2026-10-05

Sample: Red Hat Lightspeed overview

Con­tent type: Concept.

Audi­ence: Satel­lite admin­is­tra­tors choos­ing between host­ed and local Red Hat Light­speed deployments.

Pur­pose: Help admin­is­tra­tors under­stand the data han­dling, capa­bil­i­ties, and lim­i­ta­tions of each deploy­ment mod­el so they can choose an appro­pri­ate option.

My con­tri­bu­tion: I wrote the overview from scratch, informed by dis­cus­sions with devel­op­ers and a prod­uct own­er. They approved the tech­ni­cal con­tent, and peer writ­ers reviewed the style.

Approach: I explained where analy­sis takes place and how host data is han­dled in each deploy­ment mod­el. I used a ser­vice avail­abil­i­ty table and par­al­lel descrip­tions of the two mod­els to make their capa­bil­i­ties and lim­i­ta­tions easy to compare.

➚Open sam­ple as a page

Archived snap­shot, retrieved 2026-10-06

Sample: Provisioning from an Image Builder image

Con­tent type: Procedures.

Audi­ence: Sys­tem administrators.

Pur­pose: Help admin­is­tra­tors con­fig­ure Satel­lite to pro­vi­sion hosts from a Red Hat Image Builder image.

My con­tri­bu­tion: I rewrote the entire sec­tion based on old­er doc­u­men­ta­tion and dis­cus­sions with devel­op­ers. Peer writ­ers reviewed the style, and testers val­i­dat­ed the pro­ce­dures by exe­cut­ing them.

Approach: The orig­i­nal doc­u­men­ta­tion had incom­plete pack­age require­ments and unclear expla­na­tions of image loca­tion for­mats and behav­ior. I sep­a­rat­ed the Cap­sule and HTTP serv­er meth­ods into dis­tinct pro­ce­dures, clar­i­fied pre­req­ui­sites, com­plet­ed the required-pack­age infor­ma­tion, and explained how Satel­lite han­dles a full image URL ver­sus an image file name.

➚Open sam­ple as a page

Archived snap­shot, retrieved 2026-10-05

Technical Writing for CZ.NIC FRED | 2015–2020

I designed the doc­u­men­ta­tion archi­tec­ture and wrote most of the orig­i­nal user-fac­ing doc­u­men­ta­tion for FRED, CZ.NIC’s open-source domain reg­istry man­age­ment sys­tem. My work cov­ered con­cep­tu­al expla­na­tions, sys­tem archi­tec­ture, admin­is­tra­tion pro­ce­dures, and pro­to­col ref­er­ences. I con­tributed through ver­sion 2.40.

Method­ol­o­gy: Sin­gle-sourced, mod­u­lar docs as code, pub­lished through CI/​CD pipelines to HTML.

Tool­ing: reStruc­tured­Text, Sphinx Doc, Atom, Git, and GitLab.

Sup­port­ing link: FRED doc­u­men­ta­tion

Designing FRED documentation architecture

Pur­pose: Cre­ate a doc­u­men­ta­tion sys­tem orga­nized around the needs of FRED’s audiences.

Start­ing point: No user-fac­ing doc­u­men­ta­tion exist­ed. Sources includ­ed most­ly out­dat­ed inter­nal devel­op­er notes, a pro­duc­tion sys­tem to observe, a test envi­ron­ment cov­er­ing some fea­tures, and dis­cus­sions with devel­op­ers and administrators.

My con­tri­bu­tion: Mapped audi­ences and their needs, defined pub­li­ca­tion pur­pos­es, and designed the archi­tec­ture, with super­vi­sion and feed­back from a QA manager.

Approach: Sep­a­rat­ed capa­bil­i­ty descrip­tions, con­cep­tu­al expla­na­tions, sys­tem archi­tec­ture, admin­is­tra­tion tasks, and pro­to­col ref­er­ences. A required fea­ture list became the Fea­tures pub­li­ca­tion; Con­cepts pro­vid­ed deep­er explanations.

Pub­li­ca­tionAudi­encePur­pose
Fea­turesAcquir­ers, testers; also admin­is­tra­tors and developersPresent the required list of prod­uct capabilities.
Con­ceptsAcquir­ers, testers; also admin­is­tra­tors and developersExplain the behav­ior and rules behind those capabilities.
Archi­tec­ture DescriptionDevel­op­ers, admin­is­tra­tors, cus­tomer supportExplain top-lev­el sys­tem com­po­nents and relationships.
Admin­is­tra­tion ManualAdmin­is­tra­tors, cus­tomer supportSup­port set­up, oper­a­tion, cus­tomiza­tion, and maintenance.
EPP Ref­er­ence ManualDevel­op­ers, testersSup­port imple­men­ta­tion and debug­ging of EPP clients for the reg­is­trar-only interface.
RDAP REST API ReferenceDevel­op­ers, testersSup­port imple­men­ta­tion and debug­ging of RDAP clients for the pub­lic interface.

Sample: Non-domains obsoletion

Con­tent type: Concept.

Audi­ence: Reg­istry admin­is­tra­tors and cus­tomer support.

Pur­pose: Explain when unused reg­istry objects become eli­gi­ble for dele­tion and what can pre­vent it.

My con­tri­bu­tion: Researched the behav­ior through dis­cus­sions with devel­op­ers and cre­at­ed the expla­na­tion and state-tran­si­tion diagram.

Approach: Clar­i­fied how flags define object states and how con­di­tions and restric­tions gov­ern tran­si­tions. Used a state-tran­si­tion dia­gram to make these rela­tion­ships vis­i­ble along­side the writ­ten explanation.

➚ Open sam­ple as a page

Archived snap­shot, retrieved 2026-10-05

Sample: Preparing registrars

Con­tent type: Procedures.

Audi­ence: Reg­istry admin­is­tra­tors set­ting up a new instal­la­tion or onboard­ing registrars.

Pur­pose: Guide admin­is­tra­tors through cre­at­ing reg­is­trars, con­fig­ur­ing authen­ti­ca­tion, and grant­i­ng access to reg­istry zones.

My con­tri­bu­tion: Wrote the pro­ce­dure, test­ed the com­mands and checked their results, and ver­i­fied the behav­ior with developers.

Approach: Dis­tin­guished com­mon and sys­tem reg­is­trars, orga­nized the set­up into three stages, and paired com­mand exam­ples with para­me­ter expla­na­tions and rel­e­vant notes.

➚Open sam­ple as a page

Archived snap­shot, retrieved 2026-10-05

Sample: Create domain

Con­tent type: Reference.

Audi­ence: Devel­op­ers imple­ment­ing reg­is­trar clients.

Pur­pose: Define the XML request and response struc­tures for reg­is­ter­ing a domain through FRED’s EPP interface.

My con­tri­bu­tion: Wrote the ref­er­ence using XML schemas, EPP spec­i­fi­ca­tions, and dis­cus­sions with devel­op­ers. Incor­po­rat­ed XML exam­ples sup­plied by developers.

Approach: Described nest­ed XML struc­tures using con­sis­tent nota­tion for ele­ment occur­rences, attrib­ut­es, and data types, clear­ly dis­tin­guish­ing required and option­al elements.

➚Open sam­ple as a page

Archived snap­shot, retrieved 2026-10-05

Conference presentations