इस पेज पर Google Docs के सीज़न के लिए स्वीकार किए गए एक तकनीकी लेखन प्रोजेक्ट की जानकारी है.
प्रोजेक्ट की खास जानकारी
- ओपन सोर्स संगठन:
- CERN-HSF
- तकनीकी लेखक:
- आराड्ने
- प्रोजेक्ट का नाम:
- रूशियो – रुसियो के दस्तावेज़ को आधुनिक बनाना (रीस्ट्रक्चर करना और दोबारा लिखना)
- प्रोजेक्ट की अवधि:
- मानक अवधि (तीन महीने)
प्रोजेक्ट का विवरण
सारांश: Rucio फ़्रेमवर्क को विषमता वाले डेटा सेंटर के बीच भौगोलिक रूप से डिस्ट्रिब्यूट किए गए, बड़ी संख्या में मौजूद वैज्ञानिक डेटा को मैनेज और व्यवस्थित करने के मकसद से बनाया गया था. यह फ़्रेमवर्क, बड़े पैमाने पर इस्तेमाल किया जा सकने वाला, मॉड्यूलर, और एक्सटेंसिबल है. इसमें, डिस्ट्रिब्यूट किए गए डेटा को वापस पाने और अडैप्टिव रेप्लिकेशन जैसी कई सुविधाएं दी जाती हैं. इस तरह की सेवा के लिए दस्तावेज़ पाने का काम अलग-अलग बैकग्राउंड से होगा. साथ ही, इसे ऐक्सेस करने के लिए उनकी अलग-अलग शर्तें होंगी. इसलिए, ऐसी सेवा के लिए अच्छे दस्तावेज़ होने चाहिए, ताकि असली उपयोगकर्ताओं के लिए इसकी अनुमति और इस्तेमाल को आसान बनाया जा सके. साथ ही, सामान्य समस्याओं और उन्हें हल करने के लिए इसका रेफ़रंस भी दिया जाना चाहिए.
ऐसे दस्तावेज़ न होने पर, डेटा का बेहतर और असरदार तरीके से इस्तेमाल करने में काफ़ी रुकावटें आएंगी. इससे सहायता शुल्क बढ़ सकता है और प्रॉडक्ट की कॉर्पोरेट पहचान पर असर पड़ सकता है. क्योंकि दस्तावेज़, बातचीत का एक तरीका है. इसलिए, यह पक्का करना कि बातचीत को मैनेज करने लायक और ऐक्सेस किए जा सकने वाले फ़्रेमवर्क के हिसाब से व्यवस्थित किया गया हो, जबकि सही वर्शन के साथ यह काम का हो. इसलिए, यह पक्का करना ज़रूरी है कि हम सफलता पाने के लिए बातचीत कर रहे हैं.
इसे लिखते समय, एलएचसी में एटलस और कॉन्टेंट मैनेजमेंट सिस्टम के प्रयोगों की ज़्यादा ऊर्जा वाली ज़रूरतों को पूरा करने के लिए, Rucio फ़्रेमवर्क का इस्तेमाल किया गया. एलएचसी के साथ-साथ, अलग-अलग तरह के वैज्ञानिक समुदायों की ज़रूरतों को पूरा करने के लिए भी इसका इस्तेमाल किया जा रहा है, जैसे कि खगोल भौतिकी. ऐसे में, यह ज़रूरी है कि यह दस्तावेज़ लोगों के काम का हो और उन्हें ज़्यादा से ज़्यादा लोगों तक पहुंचाया जा सके. इस प्रोजेक्ट की मदद से CERN चाहता है कि Rucio के असली उपयोगकर्ता, सभी ज़रूरी दस्तावेज़ों को एक ही जगह से ऐक्सेस करने के लिए, सेंट्रलाइज़्ड व्यू की मदद से फ़्रेमवर्क का इस्तेमाल करें. साथ ही, उपयोगकर्ताओं को किसी भी तरह का अनुभव मिले.
मौजूदा स्थिति: फ़िलहाल, उपयोगकर्ता के दस्तावेज़ अलग-अलग जगहों पर उपलब्ध हैं. साथ ही, यह कई फ़ॉर्मैट में हैं, जैसे कि वैज्ञानिक लेख,readthedocs.io जिसमें कोड का सोर्स हो, Google Drive, GitHub, DockerHub या Wikis. एक से ज़्यादा सोर्स, वर्शन को ट्रैक करने और दस्तावेज़ के सही होने से जुड़ी समस्याओं की जानकारी देते हैं. साथ ही, दस्तावेज़ का एक डीसेंट्रलाइज़्ड मॉडल इस्तेमाल करके, नेविगेशन और इस्तेमाल के उदाहरण में काम की जानकारी दिखाने में काफ़ी रुकावटें आती हैं. खास तौर पर Wikis के मामले में, किसी खास प्रयोग के लिए दी गई जानकारी उसी/अन्य सोर्स में रहने वाले अन्य इंस्टेंस पर भी बहुत अच्छी तरह से लागू हो सकती है. हालांकि, एक जैसे सोर्स की कमी और ज़रूरी लिंकेज की कमी की वजह से यह जानकारी अभी तक इस्तेमाल नहीं की जा सकी. हो सकता है कि इसका इस्तेमाल भी कम हो सके.
आपके सुझाए गए उपयोगकर्ता दस्तावेज़ को मौजूदा दस्तावेज़ से बेहतर क्यों बनाया गया है? कई पहलुओं पर होने वाली समस्या को देखते हुए, नीचे दिया गया मॉडल नेविगेशन, वर्शन, ट्रैक करने, और दस्तावेज़ दिखाने में आने वाली रुकावटों को दूर करता है. इनके बारे में यहां बताया गया है:
दस्तावेज़ को फिर से बनाने का मकसद असली उपयोगकर्ता तक नेविगेट करने में लगने वाली कोशिशों को आसान बनाना है. जानकारी खोजते समय उन्हें खरगोश से बचने की ज़रूरत नहीं है, क्योंकि उन्हें आसानी के हिसाब से कैटगरी में रखा या लेबल किया जाता है. अगर एडमिन के नज़रिए से देखा जाए, तो वर्शन और ट्रैकिंग करना आसान हो जाएगा, क्योंकि ज़रूरत के हिसाब से डेटा को फिर से बनाने से, उसे अलग-अलग कैटगरी में बांटने की आज़ादी मिलती है. रीस्ट्रक्चर्ड किए गए सभी दस्तावेज़ों को एक ही जगह पर इसलिए व्यवस्थित किया जा सकता है, ताकि यह पक्का किया जा सके कि एक से ज़्यादा सोर्स का इस्तेमाल किए बिना पूरी जानकारी उपयोगकर्ता को दिख रही है.
विश्लेषण: ज़रूरी शर्तों के बारे में पढ़ें और मेंटॉरिंग टीम के साथ बातचीत करें. रूस के दस्तावेज़ की मौजूदा स्थिति में की गई कटौती की जानकारी यहां दी गई है:
दस्तावेज़ के लिए छह मुख्य स्रोत होते हैं: - Google Drive का लिंक : https://drive.google.com/drive/शॉर्टकट/1EEN8l1dFjDSgavPrAMMooDjEodHP7aU7
कोड में स्रोत के साथ स्फ़िंक्स द्वारा समर्थित Readthedocs कोड का लिंक: https://github.com/rucio/rucio ReadtheDocs का लिंक: https://rucio.readthedocs.io/en/latest/
DockerHub लिंक: https://hub.docker.com/u/rucio
GitHub लिंक: https://github.com/rucio/rucio
विकी लिंक: https://twiki.cern.ch/twiki/bin/view/AtlasComputing/Atlas DistributiondComputing
वैज्ञानिक लेख लिंक: https://arxiv.org/abs/1902.09857
इन सभी सोर्स के दस्तावेज़ अलग-अलग फ़ॉर्मैट में हैं. उदाहरण के लिए, Google Drive में स्लाइड और दस्तावेज़ के रूप में दस्तावेज़ हैं, GitHub में मुख्य रूप से reस्ट्रक्चर्ड टेक्स्ट मार्कअप भाषा वगैरह में फ़ाइलें हैं. वर्शन और ट्रैकिंग की कमी की वजह से, अलग-अलग सोर्स पर ग़ैर-ज़रूरी जानकारी पब्लिश हो रही है. जानकारी के लेबल/कैटगरी में कोई एकसमानता नहीं है. इसलिए, खोज करते समय पिछले अनुभव और विशेषज्ञता की ज़रूरत होती है.
कॉन्टेंट के अनगिनत फ़ॉर्मैट और सोर्स को देखते हुए, हम चाहते हैं कि जानकारी को नए सिरे से तैयार किया जाए और mkdocs की मदद से एक ही जगह पर उपलब्ध कराया जाए. टूल के बारे में अपनी जानकारी को बेहतर बनाने के लिए, मैंने इनके इस्तेमाल के बारे में खोजा और सीखा है.
नतीजा: मौजूदा दस्तावेज़ अव्यवस्थित है और सही तरीके से लिंक नहीं किया गया है. इसमें फ़ॉर्मैटिंग एक जैसा रखने और एक जैसा फ़ॉर्मैट इस्तेमाल करने की भी कमी है. इसकी वजह से, लोगों को खोज करने के लिए ज़्यादा कोशिश करनी पड़ती है. इस तरह की कमियों की वजह से, एडमिन/रखरखाव करने वालों/लीड पर बेवजह का दबाव भी पड़ता है. इसकी वजह से, कम्यूनिटी की मदद से रखरखाव और दस्तावेज़ अपडेट करना मुश्किल हो जाता है. उपयोगकर्ता और योगदान देने वाले का अनुभव काफ़ी कम हो गया है. इस वजह से, बार-बार ऐसा होता है
प्रस्तावित दस्तावेज़ का स्ट्रक्चर:
ज़रूरतों का पूरा विश्लेषण करने के बाद, मैंने दस्तावेज़ के फिर से तैयार किए गए मॉडल के ज़रिए समस्याओं की मुख्य समस्याओं पर हल करने का फ़ैसला किया है.
रीस्ट्रक्चर्ड मॉडल को यहां अटैच किए गए मॉक-अप में दिखाया गया है. दस्तावेज़ के हर हिस्से को नीचे दी गई सात कैटगरी में बांटा जाएगा:
- इसके बारे में जानकारी
- YouTube पर शुरुआत करना
- कॉन्सेप्ट
- Rucio इंटरफ़ेस
- टास्क
- ट्यूटोरियल
- बेहतर जानकारी
बेशक, इस कार्यक्रम के पूरा होने के बाद लिंक जोड़ने जैसे सुधार किए गए हैं, ताकि मैं वीडियो पर काम कर सकूं. Rucio पर 1,000 से ज़्यादा सक्रिय उपयोगकर्ता, 500 पेटाबाइट डेटा ऐक्सेस कर रहे हैं. इसके दस्तावेज़ों के सुझाए गए फिर से स्ट्रक्चर को इस तरह से बनाया जाना चाहिए कि इसके ज़रिए उपयोगकर्ताओं को, सहायता ईमेल पाने वालों की सूची का इस्तेमाल करने की ज़रूरत न पड़े. इसका लक्ष्य क्लिक दरों की संख्या को कम करके और वर्गीकरण और लेबलिंग के ज़रिए आसानी से दस्तावेज़ दिखाना होगा. इससे उपयोगकर्ता अनुभव को बेहतर बनाया जा सकेगा. उपयोगकर्ता/ऑपरेशन/एडमिन के हिसाब से, सारी जानकारी तीन क्लिक या उससे कम में मिल जाएगी.
मॉक-अप लिंक: https://drive.google.com/file/d/1vSYgOkB9s9eEr2soNs7ujMLHzDlkn_hr/view?usp=sharing)
प्रोजेक्ट के लक्ष्य: - अलग-अलग सोर्स से उपलब्ध गैर-ज़रूरी जानकारी का विश्लेषण करके उसे कम या ज़्यादा करें. इसका मतलब है कि हर जानकारी में सच्चाई का एक सोर्स होना चाहिए. - मौजूदा दस्तावेज़ों को अलग-अलग हिस्सों में लेबल करके फिर से व्यवस्थित करें - फिर से बनाए गए दस्तावेज़ों को mkdocs के आधार पर सेंट्रलाइज़्ड व्यू में माइग्रेट करें - फ़ाइल फ़ॉर्मैट की सीमाओं की वजह से माइग्रेट नहीं किए जा सकने वाले दस्तावेज़ को फिर से फ़ॉर्मैट/इंपोर्ट करें - लिंकेज, जानकारी में अपडेट या गड़बड़ियों को ठीक करने के मामले में, छूटी हुई गड़बड़ियों को भरने के लिए, दस्तावेज़ों में बदलाव करने को सेट अप करें.
इस सिस्टम के लिए ज़रूरी बातें पहले से ही मौजूद हैं. हालांकि, मौजूदा सिस्टम को बेहतर बनाने के लिए मेरा मॉडल बेहतर होगा. इसके लिए, सही दस्तावेज़ के साथ योगदान और मैनेज करने के लिए सही दिशा-निर्देश तय किए जाएंगे. इसके अलावा, प्रोजेक्ट से जुड़ी समस्याओं को ट्रैक करने और इस प्रोजेक्ट की सेहत को बेहतर बनाने के लिए, मैं GitHub प्रोजेक्ट बोर्ड को शामिल करना चाहता हूं.
टाइमलाइन: - 16 अगस्त से पहले --> दस्तावेज़ों के मौजूदा वर्शन और Rucio के बारे में जानें --> ऐसी नई तकनीकों और तकनीकी लेखन कौशल के बारे में जानें जिनसे प्रोजेक्ट में मदद मिलेगी --> GitHub पर रिपोर्ट की गई दस्तावेज़ों से जुड़ी समस्याओं में योगदान दें
कम्यूनिटी बॉन्डिंग (17 अगस्त - 13 सितंबर) --> टाइम ज़ोन के अंतर को ध्यान में रखते हुए, कम्यूनिकेशन चैनल और समय सेट अप करें (पुणे 3 घंटे 30 मिनट आगे है) --> लक्ष्यों को बेहतर बनाने के लिए जिन बड़ी समस्याओं की पहचान की जानी है --> बातचीत करके कम्यूनिटी, संगठन, और फ़्रेमवर्क के बारे में ज़्यादा जानें. --> लागू करने की व्यवहारिकता और संभवता के लिए, मेंटॉर और संगठन के मुख्य सदस्यों के साथ सुझाए गए दस्तावेज़ के स्ट्रक्चर का आकलन. --> प्रस्तावित सुविधाओं को पूरा करना और ऐसे किसी भी बदलाव को लागू करना जिसे मौजूदा दस्तावेज़ में करने की ज़रूरत हो.
दस्तावेज़ की अवधि (14 सितंबर से 30 नवंबर) मैंने यहां जिस प्रस्तावित फ़ॉर्मैट को बनाया है उसके बारे में जानकारी दें. इसमें मैंने उन अहम उपलब्धियों की खास जानकारी दी है जिन्हें दस्तावेज़ के तौर पर इकट्ठा करने के दौरान हासिल करने की योजना है.
--> माइलस्टोन #1: कैटगरी तय करना और लेबल करना ईटीसी: 28 सितंबर, 2020 उपलब्ध दस्तावेज़ों को शामिल करने और लेबल करने से, डेटा की रीस्ट्रक्चर और छंटाई की प्रक्रिया काफ़ी आसान हो जाएगी.
--> माइलस्टोन #2: विश्लेषण, काट-छांट, और रीस्ट्रक्चरिंग ईटीसी: 19 अक्टूबर, 2020 माइलस्टोन #1 के दौरान कैटगरी में बांटे गए दस्तावेज़ों का विश्लेषण, डुप्लीकेट और जानकारी के ग़ैर-ज़रूरी सोर्स का पता लगाने के लिए किया जाएगा. जैसा कि प्रोजेक्ट की जानकारी में बताया गया है, हम उपलब्ध जानकारी के लिए एक ही सोर्स को टारगेट करते हैं.
--> माइलस्टोन #3: सेंट्रलाइज़िंग और रीफ़ॉर्मैटिंग: ईटीसी: 9 नवंबर, 2020 दस्तावेज़ में काट-छांट किए जाने और उसे सही तरीके से फिर से बनाने के बाद, मेरा सबसे पहले उसे फिर से फ़ॉर्मैट करना होगा. अलग-अलग सोर्स की वजह से, फ़ॉर्मैट अलग-अलग होते हैं. इसलिए, उन्हें सबसे पहले सही फ़ॉर्मैट में बदलना होगा. इसके बाद, इस प्रक्रिया को एक ही जगह पर लागू करना आसान हो जाएगा.
--> माइलस्टोन #4: मैनेजमेंट/योगदान से जुड़े दस्तावेज़ सेट अप करना और ईटीसी: 23 नवंबर, 2020 इस चरण में यह पक्का किया जाता है कि प्रोजेक्ट पूरा होने के बाद भी दस्तावेज़ अपडेट होते रहें. दिशा-निर्देश बनाने और प्रोजेक्ट बोर्ड सेट अप करने से, एडमिन के सदस्यों पर यह बोझ कम हो जाएगा. वे कम्यूनिटी में योगदान देने के लिए अनुरोध करेंगे और उन पर बेहतर तरीके से नज़र रख पाएंगे.
--> प्रोजेक्ट का आकलन (30 नवंबर से 5 दिसंबर) अपने मेंटॉर का प्रोजेक्ट रिपोर्ट और इवैलुएशन सबमिट करना Docs के सीज़न में हिस्सा लेने वाले के तौर पर, अपने अनुभव की रिपोर्ट लिखना और सबमिट करना.
यह प्रोजेक्ट क्यों? मुझे लगता है कि बेहतर तरीके से लिखे गए और कई वर्शन वाले दस्तावेज़ों के साथ कोड जोड़ने से, इसे बेहतर तरीके से इस्तेमाल किया जा सकता है. निजी तौर पर, जिस तरह CERN ने भौतिक विज्ञान के अलग-अलग क्षेत्रों में आधुनिक रिसर्च की शुरुआत की है, उससे मुझे बहुत फ़र्क़ पड़ता है. इस तरह के प्रयोगों के दौरान, प्रोसेस, ट्रांसफ़र, और जनरेट की गई जानकारी के आधार पर, मेरे मन में हमेशा यह जानने की दिलचस्पी बनी रहती थी कि संगठन में, डेटा को रेफ़रंस और आने वाले समय में इस्तेमाल के लिए कैसे मैनेज किया जाता है. हमारे लिए एक फ़्रेमवर्क की मदद से दस्तावेज़ों को बेहतर बनाने की दिशा में योगदान देना सम्मान की बात होगी. यह ऐसा फ़्रेमवर्क है जो वैज्ञानिक शोध और खोजों को बढ़ावा दे रहा है.
इस प्रोजेक्ट के लिए मैं सही व्यक्ति क्यों हूं? ज़रूरी शर्तों को पूरा करने के अलावा, मुझे भरोसा है कि इस प्रोजेक्ट के लिए मैं सही व्यक्ति हूं:
मैं पहले से ही Kobernetes के मौजूदा दस्तावेज़ में बदलाव करने की कोशिश कर रहा/रही हूं. इन योगदानों की वजह से, मुझे 1.19 Kobernetes रिलीज़ साइकल के लिए, रिलीज़ Docs Shadow के तौर पर सूची में शामिल किया गया है. इस साइकल में, रिलीज़ के दौरान जोड़ी गई नई सुविधाओं के लिए, दस्तावेज़ों को बेहतर तरीके से मैनेज करने और उन्हें अपग्रेड करने में मेरा योगदान रहा है. मेरा मानना है कि अच्छे दस्तावेज़ एक बेहतरीन प्रॉडक्ट/सेवा का आधार हैं. जानकारी भले ही हो या तकनीकी, अच्छी तरह से लिखी गई, कम शब्दों में, और आसानी से ऐक्सेस करने लायक जानकारी, इसे अपनाने और बेहतर इस्तेमाल के लिए प्रेरित करने वाली होगी. अपने पूरे करियर में मैंने डेटा-ड्रिवन डिस्ट्रिब्यूशन सिस्टम के साथ काम किया. मेरा मानना है कि ऐसे सिस्टम के लिए दस्तावेज़ बनाने से जुड़ी ज़रूरी शर्तों को समझने के लिए, मेरे पास सही विकल्प है. खुद एक असली उपयोगकर्ता होने की वजह से, मुझे खराब ढंग से लिखे गए/गलत दस्तावेज़ों के इस्तेमाल से जुड़ी कमियों के बारे में पता है. इसलिए, खाते को फिर से बनाने के दौरान, मुझे उस दस्तावेज़ पर ध्यान देना होगा.