कवर स्टोरी

AI ने दस्तावेज़ लिखना सीख लिया है। अब technical writer क्या करे?

तीन वर्षों में generative AI ने first draft को महँगे output से सस्ती operation में बदल दिया। अब मुख्य प्रश्न यह नहीं कि model लिख सकता है या नहीं, बल्कि facts, structure, review, updates और quality का owner कौन है।

लेख पढ़ें →5 मिनट

AI ने दस्तावेज़ लिखना सीख लिया है। अब technical writer क्या करे?

Docs-as-Code बिना कट्टरता के

Docs-as-Code का अर्थ यह नहीं कि हर technical writer को IDE में धकेल दिया जाए। अच्छा workflow versioned text, browser editing, preview, उपयोगी automated checks, human review और predictable publishing को जोड़ता है।

REST API को सही तरह document कैसे करें

अच्छी API documentation machine-readable contract, मानवीय explanation, runnable examples और स्पष्ट error behavior को जोड़ती है। REST API documentation की दो audiences हैं: machine और human.

2006 के technical writer से आज क्या बचा है?

Tools पूरी तरह बदल गए, लेकिन पेशे का core अभी भी पहचाना जा सकता है: audience, evidence, structure, terminology और responsibility. 2006 में desktop publishing, office formats और manually maintained help systems अधिक सामान्य थे। Git collaboration, continuous delivery और AI-assisted drafting सामान्य assumptions नहीं थे।

प्रैक्टिस

सभी लेख →

टूल्स

सभी लेख →

Documentation generator कैसे चुनें, religion कैसे नहीं

Sphinx, MkDocs, Astro और दूसरे generators अलग content models और teams के लिए बने हैं। Authoring workflow, extensibility, localization और maintenance cost के आधार पर चुनें, demo की चमक के आधार पर नहीं।

डॉक्यूमेंटेशन search चुनना: failures से शुरुआत करें

“डॉक्यूमेंटेशन search चुनना: failures से शुरुआत करें” पर एक व्यावहारिक और जाँच योग्य मार्गदर्शिका, जिसे documentation team लंबे समय तक बनाए रख सके। “डॉक्यूमेंटेशन search चुनना: failures से शुरुआत करें” को तकनीकी दस्तावेज़ीकरण के लिए व्यावहारिक, जाँच योग्य और टिकाऊ तरीके से समझाया गया है। शुरुआत में वास्तविक उपयोगकर्ता समस्या को टीम की आंतरिक पसंद से अलग करें और ऐसी शर्तें लिखें जिन्हें…

Diagrams as code: कब उपयोगी, कब नहीं

“Diagrams as code: कब उपयोगी, कब नहीं” पर एक व्यावहारिक और जाँच योग्य मार्गदर्शिका, जिसे documentation team लंबे समय तक बनाए रख सके। “Diagrams as code: कब उपयोगी, कब नहीं” को तकनीकी दस्तावेज़ीकरण के लिए व्यावहारिक, जाँच योग्य और टिकाऊ तरीके से समझाया गया है। शुरुआत में वास्तविक उपयोगकर्ता समस्या को टीम की आंतरिक पसंद से अलग करें और ऐसी शर्तें लिखें जिन्हें पाठक बिना आंतर…

CI/CD में documentation

Documentation को build artifact की तरह लें: publish होने से पहले structure, links, examples और rules validate करें। CI usefulness तय नहीं कर सकता, लेकिन human review से पहले predictable defects रोक सकता है। Documentation build को quality gate मानें।