शुरुआत में पाठक को क्या सत्यापित करने देना चाहिए?
एक-वाक्य का उद्देश्य कथन पाठक को पूरे पेपर के लिए एक परीक्षण देता है। इसे प्रोजेक्ट, उसके इच्छित पाठक, और उस निर्णय या समझ की पहचान करनी चाहिए जो दस्तावेज़ समर्थन करता है। उस उद्देश्य को उत्पाद के लिए विशिष्ट रखें, बाजार के बारे में व्यापक वादे के लिए नहीं।
ड्राफ्टिंग से पहले, प्राथमिक पाठक चुनें। एक डेवलपर को घटक व्यवहार और एकीकरण धारणाओं की आवश्यकता हो सकती है। एक संभावित उपयोगकर्ता को उत्पाद प्रवाह और उसकी वर्तमान सीमाओं की आवश्यकता हो सकती है। एक टोकन धारक को दस्तावेजित टोकन कार्यों और शासन नियमों की आवश्यकता हो सकती है। पेपर कई समूहों की सेवा कर सकता है, लेकिन पहले दर्शक का नाम बताएं और तदनुसार विवरण का क्रम निर्धारित करें।
इन 4 संकेतों के साथ एक छोटा इनटेक नोट बनाएं:
- प्रोजेक्ट किस समस्या को संबोधित करता है, और किसके लिए?
- एक उपयोगकर्ता या डेवलपर आज क्या कर सकता है?
- कौन सी क्षमताएं प्रस्तावित या विकास में रहती हैं?
- पढ़ने के बाद पाठक क्या आकलन करने में सक्षम होना चाहिए?
प्रत्येक उत्तर को लाइव, परीक्षित, योजनाबद्ध या अनसुलझे के रूप में चिह्नित करें। यह स्थिति शब्दावली एक रोडमैप आइटम को उपलब्ध सुविधा की तरह पढ़ने से रोकने में मदद करती है। यदि प्रोजेक्ट प्रारंभिक है, तो बताएं कि अभी भी क्या अज्ञात है। फिर उद्देश्य कथन का उपयोग उन अंशों को हटाने के लिए करें जो नामित पाठक को प्रोजेक्ट को समझने या आकलन करने में मदद नहीं करते हैं।
व्हाइटपेपर के दस्तावेज़ मानचित्र में कौन से भाग शामिल होने चाहिए?
एक 7-भाग की रूपरेखा पाठक को प्रोजेक्ट समस्या से उसके खुले प्रश्नों तक ले जा सकती है। इसे एक कार्यशील मानचित्र के रूप में मानें, अनिवार्य टेम्पलेट के रूप में नहीं। कोई अनुभाग तभी जोड़ें जब वह इस प्रोजेक्ट के बारे में कुछ महत्वपूर्ण समझाता हो।
एक उपयोगी अनुक्रम है:
- सारांश: समस्या, दृष्टिकोण और वर्तमान विकास स्थिति।
- समस्या और संदर्भ: किसे समस्या का सामना करना पड़ता है और मौजूदा दृष्टिकोण क्या अनसुलझा छोड़ते हैं।
- उत्पाद या प्रोटोकॉल: घटक, उपयोगकर्ता प्रवाह और सिस्टम सीमाएं।
- तकनीकी डिज़ाइन: प्रासंगिक आर्किटेक्चर, निर्भरताएं और सुरक्षा धारणाएं।
- टोकन डिज़ाइन, यदि लागू हो: कार्य, आपूर्ति नियम, आवंटन और शासन मैकेनिक्स।
- रोडमैप और जिम्मेदारियां: नियोजित कार्य, निर्णय जिम्मेदार व्यक्ति और निर्भरताएं।
- जोखिम और खुले प्रश्न: ज्ञात सीमाएं और अनसुलझे डिज़ाइन विकल्प।
बिना टोकन वाले प्रोजेक्ट में टोकन अर्थशास्त्र न जोड़ें। टोकन प्रोजेक्ट के लिए, मुख्य मैकेनिक्स को परिशिष्ट में न दबाएं। विशेषज्ञ विवरण से पहले संक्षिप्त स्पष्टीकरण रखें। परिशिष्ट का उपयोग उस सामग्री के लिए करें जो किसी दावे का समर्थन करती है लेकिन मुख्य स्पष्टीकरण को बाधित करती है।
पेपर से परे लॉन्च योजना के लिए, टोकन लॉन्च चेकलिस्ट देखें। इसके प्रोजेक्ट तथ्यों को व्हाइटपेपर के साथ संरेखित रखें। लिस्टिंग तैयारी के एक अलग अवलोकन के लिए, CoinMarketCap लिस्टिंग और CoinGecko लिस्टिंग के गाइड देखें। ये संसाधन अलग-अलग कार्यों को संबोधित करते हैं; इनका उपयोग यह साबित करने के लिए नहीं किया जाना चाहिए कि कोई प्रोजेक्ट किसी प्लेटफ़ॉर्म की आवश्यकताओं को पूरा करता है।
पाठक किसी दावे को उसके स्रोत तक कैसे ट्रेस कर सकते हैं?
एक दावा सूची दिखाती है कि गद्य को पॉलिश करने से पहले किन कथनों को सत्यापन की आवश्यकता है। उत्पाद व्यवहार, टोकन मैकेनिक्स, सुरक्षा धारणाओं या प्रोजेक्ट स्थिति के बारे में प्रत्येक महत्वपूर्ण कथन के लिए एक बनाएं। रिकॉर्ड अंतराल को दृश्यमान बनाता है जबकि ड्राफ्ट अभी भी बदलना आसान है।
प्रत्येक प्रविष्टि के लिए 4 फ़ील्ड का उपयोग करें: सटीक दावा, स्रोत या बताई गई धारणा, स्थिति और समीक्षक। हमारी डिफ़ॉल्ट समीक्षा 3 चेकपॉइंट का उपयोग करती है: स्रोत मिलान, स्थिति मिलान और जिम्मेदार व्यक्ति की स्वीकृति। एक उत्पाद मैनुअल उपयोगकर्ता प्रवाह के विवरण का समर्थन कर सकता है। एक डिज़ाइन रिकॉर्ड आर्किटेक्चर निर्णय की व्याख्या कर सकता है। एक पूर्वानुमान को अनुमान के रूप में पहचाना जाना चाहिए, देखे गए परिणाम के रूप में प्रस्तुत नहीं किया जाना चाहिए। यदि कोई सहायक सामग्री नहीं है, तो कथन को योग्य बनाएं या हटा दें।
टोकन अंशों को सटीक परिभाषाओं की आवश्यकता होती है। समझाएं कि प्रत्येक आपूर्ति शब्द का क्या अर्थ है और आवंटन या रिलीज़ नियम कैसे काम करते हैं। पहचानें कि कौन से नियम दस्तावेजित हैं और कौन से शासन या किसी अन्य बताई गई प्रक्रिया के माध्यम से बदल सकते हैं। यह निहित न करें कि टोकन रखने से अधिकार मिलते हैं जब तक कि प्रोजेक्ट की शर्तें उस पढ़ने का समर्थन न करें।
यह रिकॉर्ड भविष्य के संपादकों को उत्पाद परिवर्तन से प्रभावित पाठ खोजने में भी मदद करता है। इसकी प्रविष्टियों की प्रोजेक्ट की वर्तमान सामग्री और टोकन लॉन्च चेकलिस्ट से तुलना करें। GeoMarketing Experts पर, एक समीक्षक जिम्मेदार व्यक्ति द्वारा समूहित प्रश्नों के साथ एक चिह्नित ड्राफ्ट वापस कर सकता है। लेखन कार्य के लिए, व्हाइटपेपर और लिटपेपर लेखन देखें; भुगतान कार्य के दायरे के लिए, क्रिप्टो व्हाइटपेपर प्राइसिंग देखें।
मुख्य पेपर में कितना तकनीकी विवरण शामिल होना चाहिए?
एक सिस्टम आरेख और उसका कैप्शन गद्य के समान कहानी बताना चाहिए। तकनीकी विवरण का उपयोग यह दिखाने के लिए करें कि घटक कैसे इंटरैक्ट करते हैं और उनका व्यवहार किन धारणाओं पर निर्भर करता है। चेन, कॉन्ट्रैक्ट या क्रिप्टोग्राफ़िक शब्दों की सूची उन संबंधों के बिना पर्याप्त नहीं है।
सादे भाषा में सिस्टम अवलोकन से शुरू करें। फिर प्रत्येक महत्वपूर्ण घटक को उसकी भूमिका, इनपुट, आउटपुट और निर्भरताओं द्वारा समझाएं। बहु-अभिनेता प्रक्रिया के लिए, पहचानें कि कार्रवाई कौन शुरू करता है, सिस्टम क्या जांचता है, और जब कोई निर्भरता अनुपलब्ध होती है तो क्या होता है। पहले उपयोग पर विशेषज्ञ शब्दों को परिभाषित करें। पूरे दस्तावेज़ में एक शब्द को एक अर्थ से बांधे रखें।
प्रवाह, विश्वास सीमाएं या डेटा आंदोलन दिखाने के लिए आरेखों का उपयोग करें। एक कैप्शन जोड़ें जो बताता है कि ड्राइंग में क्या शामिल है और क्या छोड़ा गया है। एक आरेख को यह सुझाव नहीं देना चाहिए कि ऑफ-चेन प्रक्रिया स्मार्ट कॉन्ट्रैक्ट द्वारा लागू की गई है। जब पाठकों को पेपर के उद्देश्य से परे कार्यान्वयन विवरण की आवश्यकता हो, तो गहन तकनीकी दस्तावेज़ीकरण से लिंक करें।
प्रत्येक महत्वपूर्ण आरेख पर 2 जांच चलाएं: पुष्टि करें कि इसके लेबल पाठ से मेल खाते हैं, फिर एक तकनीकी समीक्षक से चित्रित व्यवहार को सत्यापित करने के लिए कहें। प्रत्येक आरेख के लिए 4 फ़ील्ड रिकॉर्ड करें: उद्देश्य, घटक, सीमाएं और समीक्षक। घटकों को परीक्षित, ऑडिटेड या प्रस्तावित के रूप में तभी चिह्नित करें जब प्रोजेक्ट साक्ष्य लेबल का समर्थन करता हो। ये विवरण विनिमेय नहीं हैं। यदि डिज़ाइन बदल रहा है, तो पहचानें कि कौन से विवरण अनंतिम हैं, उन्हें स्थापित तथ्यों के रूप में लिखने के बजाय।
कौन से संपादन जांच क्रिप्टो व्हाइटपेपर में अंतराल को उजागर करते हैं?
टोकन विवरण और रोडमैप के बीच विरोधाभास एक सामग्री दोष है, शैली का मुद्दा नहीं। वाक्य पॉलिश पर समय बिताने से पहले स्थिति, परिभाषाओं और साक्ष्य के लिए समीक्षा करें। ये जांच ड्राफ्ट का आकलन करना आसान बनाती हैं:
- तंत्र के बिना वादे: परिणाम का दावा करने के बजाय सिस्टम और उसकी निर्भरताओं का वर्णन करें।
- डिलीवरी के रूप में लिखी गई योजनाएं: भविष्य के काम को लेबल करें और इसे उपलब्ध कार्यक्षमता से अलग करें।
- अस्पष्ट टोकन फ़ंक्शन: समझाएं कि टोकन सिस्टम में क्या करता है।
- अपरिभाषित आंकड़े या शब्द: बताएं कि प्रत्येक मान या लेबल किसे संदर्भित करता है।
- संदर्भ के बिना तकनीकी शब्दावली: एक शब्द को परिभाषित करें और समझाएं कि यह क्यों मायने रखता है।
- विरोधाभासी नाम या नियम: अनुभागों में आपूर्ति विवरण, शासन भूमिकाओं और स्थिति लेबल की तुलना करें।
- सामान्य अंश: ऐसी भाषा हटाएं जो इस प्रोजेक्ट के डिज़ाइन या जिम्मेदारियों का वर्णन नहीं करती है।
प्रत्येक अनुभाग के लिए, पूछें कि एक सावधान पाठक इसकी सामग्री से क्या सत्यापित कर सकता है। एक स्रोत जोड़ें, एक धारणा को योग्य बनाएं, या कथन को संशोधित करें जब उत्तर अस्पष्ट हो। फिर अनुक्रम और पठनीयता के लिए एक अलग संपादकीय पास चलाएं। तथ्य-जांच को कॉपीएडिटिंग से अलग रखने से यह जोखिम कम हो जाता है कि चिकना शब्दांकन एक अनसुलझे दावे को छिपा देता है।
समीक्षकों को रिलीज़ से पहले परिवर्तन कैसे रिकॉर्ड करने चाहिए?
एक चेंज लॉग टीम को यह रिकॉर्ड देता है कि क्या बदला और क्यों। विषय के अनुसार समीक्षा सौंपें: इंजीनियर सिस्टम विवरण जांचते हैं, टोकन जिम्मेदार व्यक्ति मैकेनिक्स जांचते हैं, और संपादकीय समीक्षक संरचना और स्थिरता जांचते हैं। कानूनी मूल्यांकन की आवश्यकता वाली भाषा की समीक्षा काउंसल को करनी चाहिए।
इस अनुक्रम का उपयोग करें:
- रूपरेखा को फ्रीज़ करें और वर्तमान स्रोत सामग्री एकत्र करें।
- स्पष्टीकरण का ड्राफ्ट तैयार करें और सामग्री दावों को साक्ष्य से मैप करें।
- प्रत्येक दावे को उसकी जांच के लिए जिम्मेदार व्यक्ति को रूट करें।
- टिप्पणियों को हल करें और महत्वपूर्ण परिवर्तनों का कारण रिकॉर्ड करें।
- लिंक, आरेख, शब्दों और संस्करण लेबल की अंतिम पाठ से तुलना करें।
जिम्मेदार व्यक्ति द्वारा समूहित प्रश्नों वाला एक चिह्नित दस्तावेज़ अगले संशोधन को एक स्पष्ट मार्ग देता है। यह Founders को दायरे और स्थिति को हल करने में मदद करता है, जबकि तकनीकी समीक्षक सिस्टम विवरण पर ध्यान केंद्रित करते हैं। प्रकाशन के माध्यम से एक चेंज लॉग रखें ताकि समीक्षक देख सकें कि कौन से दावे स्थानांतरित हुए और क्यों।
व्हाइटपेपर से परे प्रोजेक्ट संचार के लिए, दस्तावेज़ की क्रिप्टो मार्केटिंग गाइड और प्रोजेक्ट की वर्तमान तकनीकी सामग्री से तुलना करें। स्रोत तथ्यों की जांच के विकल्प के रूप में किसी का उपयोग न करें। GeoMarketing Experts पर, ड्राफ्ट समीक्षा सामग्री दावों को उनके साक्ष्य से मैप करती है और जिम्मेदार व्यक्ति द्वारा प्रश्न लौटाती है। वर्तमान रूपरेखा, उत्पाद दस्तावेज़ीकरण, यदि प्रासंगिक हो तो टोकन सामग्री, और समीक्षा की आवश्यकता वाले किसी भी दावे को व्हाइटपेपर लेखन समर्थन पर चर्चा करने के लिए भेजें।
एक प्रकाशित व्हाइटपेपर क्या अप्रमाणित छोड़ता है?
एक संस्करण लेबल और एक नियुक्त जिम्मेदार व्यक्ति पाठकों को यह पहचानने में मदद करता है कि वे कौन सा दस्तावेज़ पढ़ रहे हैं। पेपर से वर्तमान प्रोजेक्ट दस्तावेज़ीकरण तक एक मार्ग रखें। जब कोई महत्वपूर्ण सुविधा, टोकन नियम, शासन प्रक्रिया या प्रोजेक्ट स्थिति बदलती है, तो पेपर की समीक्षा करें। यदि यह अब प्रोजेक्ट को प्रतिबिंबित नहीं करता है, तो इसे अपडेट करें या पुराने के रूप में चिह्नित करें।
एक औपचारिक दस्तावेज़ यह स्थापित नहीं कर सकता कि कोई कार्यान्वयन वर्णित अनुसार व्यवहार करता है या सुरक्षा प्रमाणित करता है। टोकन और शासन शर्तें भी प्रोजेक्ट के दस्तावेजित नियमों के अधीन रहती हैं। पेपर में धारणाओं और अनसुलझी निर्भरताओं को बताएं, फिर उन प्रश्नों के लिए योग्य तकनीकी और कानूनी समीक्षा लें जिन्हें ये सामग्री हल नहीं कर सकती है।
प्रकाशन से पहले, जांचें कि अंतिम पाठ उत्पाद और शासी दस्तावेज़ों से सहमत है। पुष्टि करें कि आरेख, शब्दावली, संस्करण लेबल और लिंक समीक्षित ड्राफ्ट से मेल खाते हैं। भविष्य के अपडेट के लिए एक नामित टीम सदस्य को जिम्मेदारी दें, यह मानने के बजाय कि दस्तावेज़ अपने आप वर्तमान रहेगा।
ड्राफ्ट शुरू करने के लिए, रूपरेखा, वर्तमान उत्पाद दस्तावेज़ीकरण, यदि प्रासंगिक हो तो टोकन सामग्री, और समीक्षा की आवश्यकता वाले दावों की एक सूची इकट्ठा करें। उन मदों को GeoMarketing Experts को भेजें। अगला कदम दावा-से-स्रोत जांच है, उसके बाद प्रत्येक प्रश्न को हल करने के लिए जिम्मेदार लोगों के लिए एक अंतराल सूची है।
यह कैसे काम करता है
- पाठक और उद्देश्य निर्धारित करेंप्राथमिक दर्शक का नाम बताएं और पेपर को उन्हें क्या आकलन करने में मदद करनी चाहिए। उस कार्य को मार्केटिंग, कानूनी शर्तों और विस्तृत तकनीकी दस्तावेज़ीकरण से अलग करें।
- वर्तमान तथ्य एकत्र करें और लेबल करेंउत्पाद, आर्किटेक्चर, टोकन और रोडमैप सामग्री इकट्ठा करें। प्रत्येक मद को लाइव, परीक्षित, योजनाबद्ध या अनसुलझे के रूप में चिह्नित करें।
- अनुभाग और दावे मैप करेंरूपरेखा को पाठकों की आवश्यकताओं के आसपास व्यवस्थित करें। प्रत्येक महत्वपूर्ण दावे के लिए स्रोत और समीक्षक रिकॉर्ड करें।
- स्पष्टीकरण का ड्राफ्ट तैयार करेंकार्यान्वयन विवरण जोड़ने से पहले सिस्टम को सादे भाषा में समझाएं। आरेखों को कैप्शन दें और उनकी सीमाओं की पहचान करें।
- पेपर की समीक्षा और रखरखाव करेंदावों को सही समीक्षकों को रूट करें, विरोधाभासों को हल करें, और भविष्य के अपडेट के लिए एक जिम्मेदार व्यक्ति नियुक्त करें।
अक्सर पूछे जाने वाले प्रश्न
क्रिप्टो व्हाइटपेपर में कौन से अनुभाग शामिल होने चाहिए?
प्रोजेक्ट समस्या, प्रस्तावित दृष्टिकोण, उत्पाद या प्रोटोकॉल, प्रासंगिक तकनीकी डिज़ाइन और महत्वपूर्ण जोखिमों को कवर करें। टोकन मैकेनिक्स तभी जोड़ें जब प्रोजेक्ट में टोकन हो। एक 7-भाग की रूपरेखा कवरेज की जांच करने में मदद कर सकती है, लेकिन अंतिम मानचित्र वास्तविक प्रोजेक्ट को प्रतिबिंबित करना चाहिए। नियोजित कार्य को उपलब्ध सुविधाओं से अलग लेबल करें।
ड्राफ्ट को उन सुविधाओं की व्याख्या कैसे करनी चाहिए जो अभी तक लाइव नहीं हैं?
प्रत्येक सुविधा को उसकी वर्तमान स्थिति से लेबल करें और उस लेबल को सुसंगत रखें। लाइव व्यवहार को परीक्षित डिज़ाइन, नियोजित कार्य और अनसुलझे निर्णयों से अलग करें। स्थिति फ़ील्ड वाली एक दावा सूची समीक्षकों को उन कथनों को जल्दी से खोजने का एक तरीका देती है जो अन्यथा पूर्ण कार्यक्षमता के रूप में पढ़े जा सकते हैं।
टोकन आपूर्ति कथनों का समर्थन किस साक्ष्य से होना चाहिए?
प्रत्येक आपूर्ति शब्द को परिभाषित करें और प्रोजेक्ट सामग्री का हवाला दें जो विवरण का समर्थन करती है। आवंटन और रिलीज़ नियमों की व्याख्या करें, फिर पहचानें कि कौन से नियम बदल सकते हैं और कैसे। एक 4-फ़ील्ड दावा रिकॉर्ड—शब्दांकन, स्रोत, स्थिति और समीक्षक—टीम को यह जांचने में मदद करता है कि पेपर वर्तमान टोकन सामग्री से सहमत है।
क्या उत्पाद तैयार होने से पहले क्रिप्टो व्हाइटपेपर प्रकाशित किया जा सकता है?
हाँ, यदि यह वर्तमान कार्यक्षमता को प्रस्तावित कार्य से अलग करता है। वर्णन करें कि क्या डिज़ाइन या परीक्षण किया गया है और महत्वपूर्ण निर्भरताओं या अनसुलझे प्रश्नों की पहचान करें। पाठकों को अब क्या मौजूद है, इसका स्पष्ट विवरण चाहिए, न कि एक रोडमैप जो ऐसे लिखा गया हो जैसे हर नियोजित सुविधा पहले से उपलब्ध है।
क्या व्हाइटपेपर यह प्रदर्शित करता है कि कोई प्रोटोकॉल सुरक्षित है?
नहीं। एक व्हाइटपेपर प्रोजेक्ट के बताए गए डिज़ाइन का वर्णन करता है; यह सत्यापित नहीं करता कि कार्यान्वयन वर्णित अनुसार व्यवहार करता है या सुरक्षा प्रमाणित करता है। धारणाओं और ज्ञात जोखिमों की व्याख्या करें, और योग्य तकनीकी समीक्षा लें। डिज़ाइन दावों को कार्यान्वित व्यवहार के बारे में साक्ष्य से अलग रखें।
लिटपेपर को पूर्ण व्हाइटपेपर से क्या अलग करता है?
एक लिटपेपर पाठकों को प्रोजेक्ट के मुख्य विचार का एक छोटा परिचय देता है। एक व्हाइटपेपर सिस्टम डिज़ाइन, मैकेनिक्स और धारणाओं को अधिक गहराई से समझा सकता है। पाठक के निर्णय के आसपास प्रारूप चुनें, फिर तकनीकी दस्तावेज़ीकरण से लिंक करें जब पूर्ण कार्यान्वयन विवरण कहीं और हो।
टीम को अपना प्रकाशित व्हाइटपेपर कब संशोधित करना चाहिए?
जब कोई महत्वपूर्ण सुविधा, टोकन नियम, शासन प्रक्रिया या प्रोजेक्ट स्थिति बदलती है, तो इसकी समीक्षा करें। एक संस्करण लेबल रखें और वर्तमान सामग्री के विरुद्ध पाठ की जांच करने के लिए एक जिम्मेदार व्यक्ति नियुक्त करें। यदि पेपर अब प्रोजेक्ट को प्रतिबिंबित नहीं करता है, तो इसे संशोधित करें या पुराने के रूप में चिह्नित करें ताकि पाठक इसकी स्थिति देख सकें।
अपने प्रोजेक्ट के बारे में बताएं
चार त्वरित प्रश्नों के उत्तर दें और एक मैनेजर एक घंटे के भीतर योजना, समय और मूल्य सीमा भेजेगा। सब कुछ गोपनीय रहता है।
फ़ॉर्म लोड हो रहा है…