टैग वाले लेख: गुणवत्ता
Generative text पूरा और confident लग सकता है जबकि defaults, guarantees या citations invent कर रहा हो। Verification को authoritative sources, executable examples और explicit uncertainty पर बनाएं। Documentation में dangerous AI error अक्सर grammar नहीं होता। वह plausible लेकिन unsupported statement होता है: default timeout, undocumented parameter, compatibility promise या गलत citation।
Technically valid request जरूरी नहीं कि useful example हो। Realistic values और ऐसी sequence चुनें जो API का mental model दिखाए और developer को अगला कदम समझने दे। Schema से निकला example syntactically correct हो सकता है लेकिन कुछ सिखाए नहीं। string, 123 और foo validator pass कर लेते हैं, पर domain meaning छिपा देते हैं। अच्छा example बताता है कि request क्यों है और success के बाद क्या किया जा सकता है…
“डॉक्यूमेंटेशन search चुनना: failures से शुरुआत करें” पर एक व्यावहारिक और जाँच योग्य मार्गदर्शिका, जिसे documentation team लंबे समय तक बनाए रख सके। “डॉक्यूमेंटेशन search चुनना: failures से शुरुआत करें” को तकनीकी दस्तावेज़ीकरण के लिए व्यावहारिक, जाँच योग्य और टिकाऊ तरीके से समझाया गया है। शुरुआत में वास्तविक उपयोगकर्ता समस्या को टीम की आंतरिक पसंद से अलग करें और ऐसी शर्तें लिखें जिन्हें…
“डॉक्यूमेंटेशन कर्ज़: वास्तव में उपयोगकर्ता को क्या नुकसान पहुँचा रहा है” पर एक व्यावहारिक और जाँच योग्य मार्गदर्शिका, जिसे documentation team लंबे समय तक बनाए रख सके। “डॉक्यूमेंटेशन कर्ज़: वास्तव में उपयोगकर्ता को क्या नुकसान पहुँचा रहा है” को तकनीकी दस्तावेज़ीकरण के लिए व्यावहारिक, जाँच योग्य और टिकाऊ तरीके से समझाया गया है। शुरुआत में वास्तविक उपयोगकर्ता समस्या को टीम की आंतरिक पसंद से अलग करें और ऐसी…
Documentation को build artifact की तरह लें: publish होने से पहले structure, links, examples और rules validate करें। CI usefulness तय नहीं कर सकता, लेकिन human review से पहले predictable defects रोक सकता है। Documentation build को quality gate मानें।
“Page views से अधिक उपयोगी डॉक्यूमेंटेशन metrics” पर एक व्यावहारिक और जाँच योग्य मार्गदर्शिका, जिसे documentation team लंबे समय तक बनाए रख सके। “Page views से अधिक उपयोगी डॉक्यूमेंटेशन metrics” को तकनीकी दस्तावेज़ीकरण के लिए व्यावहारिक, जाँच योग्य और टिकाऊ तरीके से समझाया गया है। शुरुआत में वास्तविक उपयोगकर्ता समस्या को टीम की आंतरिक पसंद से अलग करें और ऐसी शर्तें लिखें जिन्हें पाठ…
अच्छा review process ownership साफ़ करता है, waiting घटाता है और factual, editorial तथा product approval को अलग रखता है। Author, factual reviewer, editor और final owner स्पष्ट करें। Roles combine हो सकते हैं, ownership छिपना नहीं चाहिए।
“API errors को इस तरह लिखें कि developer recover कर सके” पर एक व्यावहारिक और जाँच योग्य मार्गदर्शिका, जिसे documentation team लंबे समय तक बनाए रख सके। “API errors को इस तरह लिखें कि developer recover कर सके” को तकनीकी दस्तावेज़ीकरण के लिए व्यावहारिक, जाँच योग्य और टिकाऊ तरीके से समझाया गया है। शुरुआत में वास्तविक उपयोगकर्ता समस्या को टीम की आंतरिक पसंद से अलग करें और ऐसी शर्तें लिखें जिन्…
अच्छी API documentation machine-readable contract, मानवीय explanation, runnable examples और स्पष्ट error behavior को जोड़ती है। REST API documentation की दो audiences हैं: machine और human.
Glossary तब उपयोगी है जब वह product, interface और docs में decisions control करे, केवल words collect न करे। Useful entry में preferred term, definition, deprecated variants, context और owner होना चाहिए।
“Trick tests के बिना technical writers की hiring” पर एक व्यावहारिक और जाँच योग्य मार्गदर्शिका, जिसे documentation team लंबे समय तक बनाए रख सके। “Trick tests के बिना technical writers की hiring” को तकनीकी दस्तावेज़ीकरण के लिए व्यावहारिक, जाँच योग्य और टिकाऊ तरीके से समझाया गया है। शुरुआत में वास्तविक उपयोगकर्ता समस्या को टीम की आंतरिक पसंद से अलग करें और ऐसी शर्तें लिखें जिन्हें पाठ…
पचास पेज पर काम करने वाली संरचना पाँच सौ पेज पर टूट सकती है। नेविगेशन को user tasks, content types और स्थायी concepts के आधार पर बनाइए, संगठन के chart के आधार पर नहीं। छोटी documentation लगभग किसी भी navigation के साथ चल सकती है। बीस पेज हों तो reader पूरा menu देख सकता है, writers को याद रहता है कि क्या कहाँ है और duplicate content भी दिख जाता है। पाँच सौ पेज पर ये फायदे खत्म हो जाते हैं। तब structure खु…