RFC से ADR तक: निर्णय तक पहुँचना और तर्क को बनाए रखना
RFC आमतौर पर सहमति तक पहुँचने के बारे में होता है; एक ADR सहमति को रिकॉर्ड करता है जब वह पहुँच जाती है — और ADRs का सड़ना इस कारण होता है कि बहस चैट और पुल-रिक्वेस्ट टिप्पणियों में जीवित रहती है जबकि रिकॉर्ड बाद में, एक व्यक्ति द्वारा, याददाश्त से लिखा जाता है। RFC-से-ADR प्रवाह को इस तरह चलाने के लिए कि रिकॉर्ड बहस से बाहर निकल जाए: प्रस्ताव को एक मूल दावा के रूप में प्रस्तुत करें (भविष्य के ADR का शीर्षक); संदर्भ को अलग प्रो-आर्गुमेंट के रूप में जोड़ें ताकि प्रत्येक बल को व्यक्तिगत रूप से चुनौती दी जा सके; प्रत्येक विचारित विकल्प को अपने स्वयं के भाई-नोड के साथ उसके अपने फायदे और नुकसान के साथ दें — जिसमें अस्वीकृत विकल्प भी शामिल हैं; RFC टिप्पणी दौर को श्रृंखलाओं के रूप में चलाएँ (स्पष्टता के लिए प्रश्न-उत्तर श्रृंखलाएँ, आपत्तियों के लिए समीक्षा श्रृंखलाएँ — प्रत्येक एक चार-टर्न संवाद है समीक्षक और विकल्प लेखक के बीच, जिसमें N समीक्षक का मतलब N समानांतर श्रृंखलाएँ हैं; विभाजन को सुलझाने के लिए समझौता श्रृंखलाएँ, जहाँ एक पूर्ण श्रृंखला प्रयास को रिकॉर्ड करती है चाहे वह हल हुआ हो या नहीं); निर्णय लेने वालों को विकल्पों को इस प्रमाण के रूप में रेट करने दें कि कमरे की स्थिति क्या थी — रेटिंग निर्णय नहीं है, एक नामित व्यक्ति इसे बुलाता है; स्वीकृत परिणामों को चुने गए विकल्प के कॉन-चाइल्ड के रूप में रिकॉर्ड करें; और एक बाद के निर्णय को उस निर्णय से जोड़कर अधिनियम का मॉडल बनाएं जिसे यह प्रतिस्थापित करता है, पुराने को पठनीय रखते हुए। मौजूदा मार्कडाउन ADRs या निर्णय-भारी ट्रांसक्रिप्ट से बीज बोना AI निष्कर्षण के माध्यम से काम करता है जिसमें प्रॉविनेंस स्टैम्प होता है। ईमानदार सीमाएँ: यह रिपो-ट्रैक्ड ADRs को प्रतिस्थापित नहीं करता (रिकॉर्ड को निर्यात और कमिट करें); कोई अंतर्निहित ADR स्थिति क्षेत्र नहीं है, इसलिए प्रस्तावित/स्वीकृत/प्रतिस्थापित एक परंपरा है जिसे आप बनाए रखते हैं; एक पूर्ण श्रृंखला का मतलब यह नहीं है कि पक्षों ने सहमति दी — जो कि असहमत और प्रतिबद्ध को पठनीय बनाता है।
एक RFC आमतौर पर सहमति तक पहुँचने के बारे में होता है; एक ADR सहमति को रिकॉर्ड करता है जब वह पहुँच जाती है। ADRs सड़ जाते हैं क्योंकि सहमति तक पहुँचने की प्रक्रिया चैट में होती है और रिकॉर्डिंग बाद में, याददाश्त से होती है। दोनों को एक संरचना में चलाएँ:
- प्रस्ताव एक मूल दावा है; संदर्भ बल अलग हैं, चुनौती देने योग्य समर्थक तर्क हैं; हर विकल्प - जिसमें अस्वीकृत विकल्प भी शामिल हैं - को अपना खुद का नोड मिलता है
- RFC राउंड श्रृंखलाएँ हैं: स्पष्टता के लिए प्रश्नोत्तर, आपत्ति के लिए समीक्षा, सुलह के लिए समझौता — चार-चरण संवाद, N समीक्षक = N समानांतर श्रृंखलाएँ
- रेटिंग निर्णय नहीं है: निर्णय लेने वाले इसे साक्ष्य के रूप में रेट करते हैं; एक नामित व्यक्ति इसे कहता है — और लिखता है कि क्यों, विशेष रूप से कमरे के खिलाफ
- एडीआर पेड़ है: कुछ भी ट्रांसक्राइब नहीं किया गया है, इसलिए ट्रांसक्रिप्शन में कुछ भी नहीं खोता — यदि आपकी संगठन को इसकी आवश्यकता है तो इसे रिपॉजिटरी में निर्यात करें
जिसका निर्णय कोई पुनर्निर्माण नहीं कर सका
नया तकनीकी लीड एक उचित सवाल पूछता है: हर सेवा उस कतार के माध्यम से बिलिंग सिस्टम से क्यों बात करती है? एक ADR है — ADR-014, चार वाक्य, ग्यारह महीने पहले लिखा गया। संदर्भ: "हमें विश्वसनीय बिलिंग एकीकरण की आवश्यकता थी।" निर्णय: "कतार का उपयोग करें।" परिणाम: "कुछ अतिरिक्त विलंब।" यह तकनीकी रूप से एक रिकॉर्ड है। यह कुछ भी नहीं बताता।
आप वहाँ थे, इसलिए आप जानते हैं कि ADR-014 क्या नहीं कहता: दो स्लैक चैनलों में तीन सप्ताह की बहस और एक गर्म PR थ्रेड; समकालिक-API विकल्प जो एक दर सीमा के कारण हार गया जो अब बढ़ा दी गई है; स्टाफ इंजीनियर का आपत्ति जिसका उत्तर एक बेंचमार्क से दिया गया जिसे अब कोई नहीं ढूंढ सकता। बहस हुई। रिकॉर्ड बाद में, एक व्यक्ति द्वारा, शुक्रवार को, याददाश्त से लिखा गया।
यह एक प्रलेखित, लगभग सार्वभौमिक विफलता मोड है जो वास्तव में एक अच्छे अभ्यास का है। AWS की निर्देशात्मक मार्गदर्शिका और Microsoft के Well-Architected दस्तावेज दोनों ADRs की सिफारिश करते हैं — और दोनों दर्द को नोट करते हैं: उन्हें अद्यतित रखना समय लेता है, और प्रबंधन जटिल हो जाता है जब टीमें और विकल्प बढ़ते हैं। इसकी जड़ संरचनात्मक है: बहस और रिकॉर्ड अलग-अलग स्थानों पर रहते हैं, इसलिए रिकॉर्ड हमेशा एक हानिकारक प्रतिलिपि होता है। समाधान यह है कि उन्हें एक ही स्थान पर बनाया जाए। न ही यह अभ्यास इंजीनियरिंग-विशिष्ट है, और न ही ADR-विशिष्ट। Google एक डिज़ाइन डॉक की आवश्यकता करता है — समस्या, प्रस्तावित दृष्टिकोण, विचार किए गए विकल्प, व्यापार-बंद — जिसे महत्वपूर्ण तकनीकी कार्य शुरू होने से पहले लिखा और समीक्षा की जाती है, यह एक अभ्यास है जो कंपनी के अपने Software Engineering at Google में निर्धारित किया गया है। यह एक ADR के समान अनुशासन है, जो एक कदम पहले लागू होता है: ADR उस विकल्प को रिकॉर्ड करता है जिस पर डिज़ाइन डॉक ने तर्क किया। दोनों एक ही कारण से एक ही तरीके से विफल होते हैं, और दोनों को एक ही कदम से ठीक किया जाता है — तर्क को उस स्थान पर रखें जहां रिकॉर्ड रहता है, बजाय इसके कि एक को बाद में दूसरे में प्रतिलिपि करें। नीचे हर कदम को दोनों कलाकृतियों को कवर करने के रूप में पढ़ें।
ADRs क्यों सड़ते हैं
ADR समुदाय के अपने सामग्री से एक वाक्य पूरी निदान को दर्शाता है: एक RFC आमतौर पर सहमति तक पहुँचने के बारे में होता है; एक ADR सहमति को रिकॉर्ड करता है जब वह पहुँच जाती है। दो कलाकृतियाँ, दो क्षण — और उनके बीच सब कुछ लीक हो जाता है। जो विकल्प "स्पष्ट रूप से" गलत थे, वे रिकॉर्ड नहीं होते (जब तक कि वे स्पष्ट रहना बंद न कर दें)। अंतिम डिज़ाइन को आकार देने वाला आपत्ति केवल एक बंद थ्रेड पर एक PR टिप्पणी के रूप में जीवित रहती है। संदर्भ अनुभाग सबसे अंत में, सबसे खराब तरीके से लिखा जाता है, जो भी खेल हार गया। बैठकें जो निर्णय उत्पन्न करनी चाहिए थीं, सारांश उत्पन्न करती हैं, और वह तर्क जो निर्णय को स्थायी बनाता है — वह चीज़ जिस पर पूरा निर्णय गुणवत्ता श्रृंखला निर्भर करती है — ठीक वही है जो ट्रांसक्रिप्शन छोड़ देता है।
आपको क्या चाहिए
प्रत्येक RFC के लिए एक Argumentree चर्चा। यदि आपके पास मौजूदा मार्कडाउन ADRs या निर्णय-भारी बैठक के ट्रांसक्रिप्ट हैं, तो उन्हें अपलोड करें — AI निष्कर्ष इसे संरचित पक्ष/विपक्ष के तर्कों में बदल देता है, जिसमें स्रोत अंश जुड़े होते हैं, जिन्हें निकाले गए के रूप में मुहरबंद किया जाता है ताकि आयातित दावे कभी भी जीवित दावों के रूप में गलत न समझे जाएं (निष्कर्ष कैसे काम करता है)।
चरण 1–3: प्रस्ताव, संदर्भ, विकल्प
- 1प्रस्ताव को मूल दावा के रूप में बताएं — प्रस्तावित निर्णय, कोई प्रश्न नहीं: "हम सभी बिलिंग लेखनों को एक स्थायी कतार के माध्यम से मार्गदर्शित करेंगे।" यह वाक्य भविष्य के ADR का शीर्षक है। चेकपॉइंट: मूल मौजूद है, एक वाक्य, प्रस्तावक द्वारा लिखा गया।
- 2संदर्भ को अलग-अलग प्रो-तर्कों के रूप में। प्रत्येक शक्ति जो निर्णय को आवश्यक बनाती है — विश्वसनीयता की आवश्यकता, बिलिंग-प्रणाली की दर सीमा, ऑडिट अनिवार्यता — अपनी जड़ के तहत अपना स्वयं का तर्क है। एक एकीकृत "संदर्भ" पैराग्राफ को चुनौती नहीं दी जा सकती; तीन अलग-अलग संदर्भ दावे प्रत्येक को व्यक्तिगत रूप से प्रश्नित, पुष्टि या खारिज किया जा सकता है। चेकपॉइंट: ≥2 संदर्भ तर्क, प्रत्येक एक शक्ति।
- 3हर विकल्प को अपना खुद का नोड मिलता है। कतार, समकालिक एपीआई, बैच कार्य - भाई-बहन के तर्क, प्रत्येक के अपने फायदे और नुकसान हैं। फायदे/नुकसान माता-पिता के सापेक्ष होते हैं, इसलिए एक विकल्प के नुकसान उस विकल्प से जुड़े होते हैं, निर्णय से नहीं। उन विकल्पों को शामिल करें जिन्हें आप अस्वीकार करने की उम्मीद करते हैं: अस्वीकृत भाई-बहन अगले वर्ष के "हमने ऐसा क्यों नहीं किया..." का उत्तर देते हैं। चेकपॉइंट: हर विकल्प जिसके बारे में पाठक पूछ सकता है, मौजूद है।
चरण 4–6: RFC राउंड जो एक रिकॉर्ड छोड़ता है
अब समीक्षा दौर — सामान्यतः यह चैट, टिप्पणियों और हॉलवे में बिखर जाता है। यहाँ यह तीन प्रकार के संरचित आदान-प्रदान के रूप में चलता है, प्रत्येक एक चार-चरण संवाद समीक्षक और विकल्प के लेखक के बीच:
प्रश्नोत्तर श्रृंखला — स्पष्ट करें
"मौजूदा समकालिक ग्राहकों के साथ क्या होता है?" विकल्प के लेखक का उत्तर है, समीक्षक आगे बढ़ता है, लेखक फिर से उत्तर देता है — पूरा। कोई भी विकल्प निर्णय में अनुत्तरित प्रश्न नहीं ले जाना चाहिए।
समीक्षा श्रृंखला — वस्तु
एक समीक्षक एक विकल्प को अस्वस्थ मानता है; लेखक प्रतिक्रिया देता है; फॉलो-अप; प्रतिक्रिया। N समीक्षक = N समानांतर श्रृंखलाएँ उसी विकल्प पर — हर आपत्ति अपनी स्वयं की जिम्मेदार अदला-बदली है, साझा थ्रेड में खोई हुई टिप्पणी नहीं।
समझौता श्रृंखला — सामंजस्य स्थापित करें
दो शिविर विभाजित? एक दूसरे लेखक को मध्य विकल्प का प्रस्ताव देता है। यदि यह हल हो जाता है, तो आपके पास एक नया विकल्प नोड है। यदि नहीं, तो पूरा किया गया श्रृंखला यह रिकॉर्ड है कि इसे आजमाया गया था — जो लगभग उतना ही मूल्यवान है।
पूर्ण ≠ सहमति
एक श्रृंखला जो पूर्ण हुई, इसका मतलब है कि विनिमय ने अपना पाठ्यक्रम पूरा किया — प्रश्न पूछा गया और दो बार उत्तर दिया गया — इसका मतलब यह नहीं है कि पक्षों ने सहमति व्यक्त की। इस भेद को बनाए रखें; यह महत्वपूर्ण होने वाला है।
चरण 7: निर्णय लेना — और रेटिंग क्या नहीं है
निर्णय लेने वाले विकल्पों को रेट करते हैं: प्रत्येक के लिए एक लेबल वाला रेटिंग। वितरण वास्तविक साक्ष्य है — जहां कमरा खड़ा था, रिकॉर्ड पर, कॉल से पहले। लेकिन रेटिंग निर्णय नहीं है। एक नामित व्यक्ति अभी भी निर्णय लेता है, और यदि कॉल वितरण के खिलाफ जाता है, तो निर्णय नोड वही है जहां इसे समझाया जाता है। (वह नामित व्यक्ति कौन होना चाहिए, और बहस से पहले भूमिका कैसे सौंपनी है, न कि बाद में, यह अपनी खुद की अनुशासन है — देखें निर्णय-अधिकार ट्यूटोरियल।)
आपकी टीम के लिए प्रश्न
आपके अंतिम वास्तुशिल्प निर्णय का निर्णय किसने लिया — और क्या आप इसे साबित कर सकते हैं? यह नहीं कि बैठक में कौन था: निर्णय किसका था, और उनका तर्क कहाँ लिखा है?
चरण 8–9: एडीआर जिसे आपको लिखने की आवश्यकता नहीं थी
यहाँ भुगतान है। रिकॉर्ड एक ऐसा दस्तावेज़ नहीं है जिसे आप बाद में लिखते हैं — यह चुने हुए विकल्प का नोड है और इसके साथ पहले से जुड़े सभी चीजें: संदर्भ तर्क (Context), अस्वीकृत भाई-बहन (Options Considered), पूर्ण श्रृंखलाएँ (चर्चा, लेखकों के साथ), रेटिंग (जहाँ कमरा खड़ा था), और निर्णय तर्क इसके तर्क के साथ (Decision)। कुछ भी लिप्यंतरित नहीं किया गया है, इसलिए लिप्यंतर में कुछ भी नहीं खोता।
- 1आप जिन परिणामों को स्वीकार कर रहे हैं, उन्हें रिकॉर्ड करें। ज्ञात नुकसान — अतिरिक्त विलंब, कतार का संचालन बोझ — चुने गए विकल्प के सह-परिणाम के रूप में चलते हैं, जिन्हें निर्णय लेने वाले द्वारा स्वीकार किया गया है। उन्हें लिखना इसे एक निर्णय बनाता है न कि एक पसंद। चेकपॉइंट: रिकॉर्ड पर ≥1 स्वीकार किया गया परिणाम।
- 2यदि आपकी संगठन को रेपो-ट्रैक्ड ADRs की आवश्यकता है, तो निर्यात करें। कई को सही तरीके से इसकी आवश्यकता होती है — कोड के बगल में मार्कडाउन ADR अनुपालन आर्टिफैक्ट बना रहता है। पेड़ से चार-खंड का सारांश लिखें (पांच मिनट, शुक्रवार नहीं), पूर्ण बहस के लिए चर्चा से लिंक करें। चेकपॉइंट: रेपो ADR पेड़ का उल्लेख करता है; पेड़ तर्क को रखता है।
असहमत हों और प्रतिबद्ध रहें, रिकॉर्ड पर
Amazon ने जो पैटर्न प्रसिद्ध किया — असहमत होना और प्रतिबद्ध होना — उसका एक पठनीयता समस्या है: कोई बाद में कैसे जानता है कि असहमति वास्तविक, सुनी गई और उत्तर दी गई थी, न कि दबा दी गई? श्रृंखला तंत्र इसका उत्तर देता है। एक समीक्षा श्रृंखला जो अपने पूरे चार चक्रों को चलाती है और बिना सहमति के पूरी होती है, वास्तव में रसीद है: आपत्ति की गई, उत्तर दिया गया, दबाव डाला गया, और फिर से उत्तर दिया गया, रिकॉर्ड पर, पहले कि असहमत व्यक्ति प्रतिबद्ध हो। असहमत व्यक्ति को सुने जाने के रूप में दस्तावेजित किया गया है — जो बाद में प्रतिबद्ध होना तर्कसंगत बनाता है, न कि केवल आज्ञाकारी।
पूर्णता को सहमति के रूप में न पढ़ें
पूर्ण हुआ का मतलब है कि विनिमय समाप्त हो गया, यह नहीं कि किसी ने अपना मन बदल लिया। यदि आप श्रृंखला पूर्णता को सहमति के रूप में रिपोर्ट करते हैं, तो आप झूठा सहमति बनाएंगे और उस विश्वास को नष्ट करेंगे जिसके लिए यह तंत्र मौजूद है। ईमानदार पढ़ाई: परामर्श किया, उत्तर दिया, फिर भी विरोध किया, फिर भी प्रतिबद्ध — सभी चार तथ्य स्पष्ट हैं।
चरण 10: हटाए बिना प्रतिस्थापित करना
निर्णय उम्र। जब वह दर सीमा जो समकालिक विकल्प को समाप्त करती है, बढ़ाई जाती है, तो सही कदम एक नया निर्णय है जो उसका संदर्भ देता है जिसे यह प्रतिस्थापित करता है — एक नया तर्क जो ADR-014 के नोड से जुड़ा है, यह बताते हुए कि क्या बदला। पुराना निर्णय पढ़ने योग्य बना रहता है; इसका तर्क ही यह है कि नया निर्णय जानता है कि यह किसे पलट रहा है।
एक ईमानदार अंतर को स्पष्ट रूप से प्रबंधित करने के लिए: कोई अंतर्निहित ADR स्थिति फ़ील्ड नहीं है. प्रस्तावित / स्वीकृत / प्रतिस्थापित एक तर्क पर एक प्रथम श्रेणी की स्थिति नहीं है — प्रतिस्थापन को लिंक करके मॉडल किया गया है, और यह परंपरा आपके बनाए रखने के लिए है। इसे आपकी टीम के कार्य समझौते में स्पष्ट करें बजाय इसके कि आप मान लें कि उत्पाद इसे लागू करता है।
ईमानदार सीमाएँ
- ✗यह आपके रिपॉजिटरी में ADRs को प्रतिस्थापित नहीं करता यदि आपकी संगठन को कोड के बगल में संस्करण-नियंत्रित की आवश्यकता है। सारांश को निर्यात और कमिट करें; उस भाग के लिए ट्री का उपयोग करें जिसमें मार्कडाउन खराब है — बहस।
- ✗कोई ADR स्थिति क्षेत्र नहीं। प्रस्तावित/स्वीकृत/प्रतिस्थापित एक लिंकिंग परंपरा है जिसे आप बनाए रखते हैं, यह कुछ ऐसा नहीं है जिसे उत्पाद लागू करता है।
- ✗एक श्रृंखला चार मोड़ है। गहरे वास्तुशिल्प असहमति के लिए एक कॉल की आवश्यकता होगी; श्रृंखला उस रिकॉर्ड है जो पहले ही आजमाया जा चुका है।
- ✗रेटिंग एक एकल लेबल वाला मान है, न कि भारित बहु-मानदंड स्कोरिंग।
- ✗यह किसी को भी अच्छा संदर्भ लिखने के लिए प्रेरित नहीं करता। संरचना एक अच्छे रिकॉर्ड की लागत को कम करती है; यह निर्णय प्रदान नहीं करती।
व्यावहारिक पाठ
- ✓एक RFC, एक चर्चा। पूरे क्वार्टर की आर्किटेक्चर को कवर करने वाले मेगा-ट्री का विरोध करें — सुपरसेशन लिंक निर्णयों को नेस्टिंग की तुलना में बेहतर तरीके से जोड़ते हैं।
- ✓जो मौजूद है उससे बीज बोओ। एक निर्णय-भारी ट्रांसक्रिप्ट या आपका पुराना ADR फ़ोल्डर, निकाला गया, बहस को एक तेज़ शुरुआत देता है — आयातित के रूप में लेबल किया गया, ताकि जीवित तर्क स्पष्ट रूप से अलग रह सकें।
- ✓समीक्षकों के नाम उनकी श्रृंखलाओं पर डालें और उन्हें वहीं छोड़ दें। श्रेय ही जिम्मेदारी है; गुमनाम वास्तु संबंधी आपत्तियाँ लोककथाओं में बदल जाती हैं।
- ✓परिणामों का अनुभाग निर्णयकर्ता का है, किसी और का नहीं। जिन नकारात्मक पहलुओं को उस व्यक्ति ने स्वीकार किया है, जिन्होंने उन्हें स्वीकार किया है, वे समीक्षक की चेतावनियों की तुलना में एक अलग महत्व रखते हैं।
ADR-014, वह संस्करण जो उत्तर देता है
नई तकनीकी लीड के सवाल पर वापस आते हैं। पुनर्निर्मित संस्करण में, ADR-014 एक नोड है: इसके तर्क के साथ कतार निर्णय, तीन संदर्भ बल (एक अब पुराना — स्पष्ट रूप से), एक अस्वीकृत समकालिक-API भाई जिसका घातक नाम पुरानी दर सीमा है, चार पूर्ण समीक्षा श्रृंखलाएँ जिसमें स्टाफ इंजीनियर की भी शामिल है, और सबूत के रूप में संलग्न बेंचमार्क। तकनीकी लीड दस मिनट तक पढ़ता है, दर सीमा में बदलाव देखता है, और पुराने नोड से जुड़े एक प्रतिस्थापन प्रस्ताव को खोलता है। कोई भी स्लैक की खुदाई नहीं करता। यही पूरी वादा है: श्रृंखलाएँ सहमति तक पहुँचती हैं, पेड़ इसे रिकॉर्ड करता है — और रिकॉर्ड उन सवालों के जवाब देता है जिनके बारे में आपको नहीं पता था कि पूछे जाएंगे।
स्रोत और आगे की पढ़ाई
- Nygard, M. (2011). आर्किटेक्चर निर्णयों का दस्तावेजीकरण। Cognitect ब्लॉग।जिस निबंध ने ADRs को लोकप्रिय बनाया: संदर्भ, निर्णय, परिणाम, कोड के साथ रखा गया।
- AWS प्रिस्क्रिप्टिव गाइडेंस — आर्किटेक्चरल निर्णय रिकॉर्ड।यह ट्यूटोरियल RFC-vs-ADR ढांचे और प्रलेखित रखरखाव की समस्याओं को ठीक करने के लिए मौजूद है।
- माइक्रोसॉफ्ट एज़्योर वेल-आर्किटेक्टेड फ्रेमवर्क — आर्किटेक्चर निर्णय रिकॉर्ड।सुसंगठित समीक्षा संदर्भ में ADR प्रथा।
- ADR GitHub संगठन (adr.github.io)।टेम्पलेट, उपकरण और समुदाय द्वारा संचित परंपराएँ — जिसमें स्थिति-क्षेत्र प्रथा शामिल है जिसे यह ट्यूटोरियल लिंक करके मॉडल करता है।
अक्सर पूछे जाने वाले प्रश्न
RFC और ADR में क्या अंतर है?
RFC (टिप्पणियों के लिए अनुरोध) सहमति तक पहुँचने की प्रक्रिया है: एक प्रस्ताव प्रसारित किया जाता है, विकल्पों पर बहस की जाती है, आपत्तियाँ उठाई जाती हैं और उनका उत्तर दिया जाता है। ADR (आर्किटेक्चर निर्णय रिकॉर्ड) सहमति को दर्ज करता है जब यह प्राप्त हो जाती है: संदर्भ, विचार किए गए विकल्प, निर्णय, परिणाम, स्थिति। उन्हें अलग-अलग कलाकृतियों के रूप में चलाने का विफलता मोड यह है कि उनके बीच सब कुछ लीक हो जाता है — बहस चैट और PR टिप्पणियों में जीवित रहती है जबकि रिकॉर्ड बाद में स्मृति से लिखा जाता है। RFC को एक संरचित तर्क वृक्ष के रूप में चलाने से ADR बहस से बाहर निकल जाता है: कुछ भी ट्रांसक्राइब नहीं किया जाता है, इसलिए ट्रांसक्रिप्शन में कुछ भी खोता नहीं है।
ADRs क्यों बासी हो जाते हैं या लिखना बंद कर देते हैं?
क्योंकि उन्हें लिखना एक ट्रांसक्रिप्शन काम है। असली तर्क स्लैक थ्रेड्स, समीक्षा टिप्पणियों और बैठकों में होता है; उसके बाद एक व्यक्ति याददाश्त से एक संदर्भ अनुभाग का पुनर्निर्माण करता है, आमतौर पर संक्षेप में और अंत में। AWS और Microsoft की अपनी मार्गदर्शिका इस दर्द को नोट करती है: ADRs को लिखने और अपडेट करने में समय लगता है, और निर्णयों की संख्या बढ़ने पर प्रबंधन जटिल हो जाता है। टीमें ADRs में विश्वास करना नहीं छोड़तीं — वे ट्रांसक्रिप्शन कर लगाने से रोकती हैं। बहस और रिकॉर्ड को एक ही संरचना बनाना कर को हटा देता है।
आप एक रिकॉर्ड के साथ RFC समीक्षा राउंड कैसे चलाते हैं?
तीन संरचित कदम, प्रत्येक चार-टर्न संवाद विकल्प के लेखक के साथ। स्पष्टीकरण के लिए प्रश्नोत्तर श्रृंखलाएँ: प्रश्न, उत्तर, फॉलो-अप, उत्तर। आपत्तियों के लिए समीक्षा श्रृंखलाएँ: मूल्यांकन, प्रतिक्रिया, फॉलो-अप, प्रतिक्रिया — जिसमें N समीक्षक एक ही विकल्प पर N समानांतर श्रृंखलाएँ खोलते हैं, न कि एक साझा धागा, ताकि हर आपत्ति का श्रेय दिया जा सके और उसका उत्तर दिया जा सके। विभाजन के लिए समझौता श्रृंखलाएँ: एक पक्ष दूसरे को मध्य स्थिति का प्रस्ताव देता है, और चाहे यह हल हो या न हो, पूर्ण श्रृंखला यह रिकॉर्ड करती है कि इसे आजमाया गया था। निर्णय लेने से पहले का चेकपॉइंट: कोई विकल्प बिना उत्तरित प्रश्न के नहीं है, और हर महत्वपूर्ण आपत्ति एक पूर्ण श्रृंखला के रूप में मौजूद है।
'असहमत होना और प्रतिबद्ध होना' निर्णय रिकॉर्ड के साथ कैसे काम करता है?
श्रृंखला तंत्र इसे पढ़ने योग्य बनाते हैं। एक समीक्षा श्रृंखला जो अपने पूरे पाठ्यक्रम को चलाती है - आपत्ति, प्रतिक्रिया, अनुवर्ती, प्रतिक्रिया - और बिना सहमति के समाप्त होती है, यह प्रमाण है कि असहमति वास्तविक थी, सुनी गई और उत्तर दी गई थी इससे पहले कि असहमत व्यक्ति प्रतिबद्ध हो। महत्वपूर्ण रूप से, पूरा होना सहमत होना नहीं है: इसका मतलब है कि आदान-प्रदान समाप्त हो गया। सहमति के रूप में पूर्णता की रिपोर्ट करना झूठी सहमति का निर्माण करता है और तंत्र के मूल्य को नष्ट करता है। ईमानदार रिकॉर्ड एक साथ चार तथ्यों को दर्शाता है: परामर्श किया, उत्तर दिया, अभी भी विरोध किया, फिर भी प्रतिबद्ध - जो कि असहमति के बाद प्रतिबद्धता को उचित बनाता है।
क्या निर्णय रिकॉर्ड कोड रिपॉजिटरी में ADRs की जगह लेनी चाहिए?
नहीं — और यह ट्यूटोरियल स्पष्ट रूप से ऐसा कहता है। यदि आपकी संगठन को कोड के बगल में संस्करण-नियंत्रित ADRs की आवश्यकता है (कई को, सही ढंग से, अनुपालन और ऑफ़लाइन पहुंच के लिए), तो उन्हें रखें: पेड़ से चार-खंडीय मार्कडाउन सारांश लिखें और इसे चर्चा से लिंक करें। श्रम का विभाजन स्पष्ट है: रेपो ADR स्थायी अनुपालन वस्तु है; पेड़ में वह है जिसमें मार्कडाउन कमजोर है — जीवित बहस, अस्वीकृत विकल्पों के साथ उनके तर्क, आपत्तियाँ और उनके उत्तर, और रेटिंग।
आप एक ADR को कैसे पूर्ववत करते हैं?
परंपरा द्वारा, किसी क्षेत्र द्वारा नहीं — और यह ईमानदार होना महत्वपूर्ण है कि किसी तर्क पर कोई अंतर्निहित प्रस्तावित/स्वीकृत/प्रतिस्थापित स्थिति नहीं है। नए निर्णय को उसके द्वारा प्रतिस्थापित किए गए तर्क से जोड़कर एक नया तर्क बनाकर प्रतिस्थापन का मॉडल बनाएं, यह बताते हुए कि क्या बदला (उठाई गई दर सीमा, नई आवश्यकता)। पुराना निर्णय पठनीय बना रहता है — इसे हटाने से ठीक वही तर्क नष्ट हो जाएगा जिसका नए निर्णय को संदर्भित करने की आवश्यकता है। अपनी टीम के कार्य समझौते में परंपरा को स्पष्ट करें ताकि इसे जानबूझकर बनाए रखा जा सके।
निर्णयों को लिप्यंतरित करना बंद करें। उन्हें रखना शुरू करें।
अपने अगले RFC को एक पेड़ के रूप में चलाएँ: उनके तर्क के साथ विकल्प, उत्तरित श्रृंखलाओं के रूप में आपत्तियाँ, और एक ADR जो अपने आप लिखता है।
14 दिन का मुफ्त परीक्षण शुरू करें