इस पेज पर, तकनीकी लेखन वाले उस प्रोजेक्ट की जानकारी दी गई है जिसे Google Season of Docs के लिए स्वीकार किया गया है.
प्रोजेक्ट की खास जानकारी
- ओपन सोर्स संगठन:
- CERN-HSF
- टेक्निकल राइटर:
- Ariadne
- प्रोजेक्ट का नाम:
- Rucio – Rucio के दस्तावेज़ों को आधुनिक बनाना (उनका स्ट्रक्चर बदलना और उन्हें फिर से लिखना)
- प्रोजेक्ट की अवधि:
- स्टैंडर्ड अवधि (तीन महीने)
प्रोजेक्ट का विवरण
खास जानकारी: Rucio फ़्रेमवर्क को इस मकसद से बनाया गया था कि अलग-अलग तरह के डेटा सेंटर में, भौगोलिक तौर पर अलग-अलग जगहों पर मौजूद वैज्ञानिक डेटा को मैनेज और व्यवस्थित किया जा सके. डिस्ट्रिब्यूटेड डेटा रिकवरी और अडैप्टिव रेप्लिकेशन जैसी सुविधाएं देने वाला यह फ़्रेमवर्क, बहुत बड़े, मॉड्यूलर, और एक्सटेंसिबल है. इस तरह की सेवा के लिए दस्तावेज़ के उपभोक्ता अलग-अलग बैकग्राउंड से होने चाहिए. साथ ही, इसे ऐक्सेस करने के लिए उनकी शर्तें भी अलग-अलग होंगी. इसलिए, इस तरह की सेवा के लिए अच्छे दस्तावेज़ होने चाहिए, ताकि असली उपयोगकर्ताओं के लिए इसे अपनाना और इस्तेमाल करना आसान हो. साथ ही, इन दस्तावेज़ों से सामान्य समस्याओं और उन्हें हल करने के तरीकों के बारे में भी पता चलता हो.
इस तरह के दस्तावेज़ों के बिना, डेटा का बेहतर और असरदार तरीके से इस्तेमाल करने में काफ़ी समस्याएं आ सकती हैं. इससे, सहायता पाने की लागत बढ़ सकती है. साथ ही, प्रॉडक्ट की कॉर्पोरेट पहचान को नुकसान पहुंच सकता है. वैसे तो दस्तावेज़ बातचीत का एक तरीका होता है. यह पक्का करना कि कम्यूनिकेशन को मैनेज किए जा सकने वाले और ऐक्सेस किए जा सकने वाले फ़्रेमवर्क में शामिल किया गया हो. साथ ही, यह भी पक्का करना कि कम्यूनिकेशन, सही वर्शन के साथ काम का हो. इससे यह पक्का होता है कि हम सफलता के लिए कम्यूनिकेट कर रहे हैं.
इस लेख को लिखने के समय, Rucio फ़्रेमवर्क का इस्तेमाल, एलएचसी में ATLAS और CMS एक्सपेरिमेंट की ज़्यादा ऊर्जा की ज़रूरतों को पूरा करने के लिए किया जा रहा था. इसका इस्तेमाल, एलएचसी के अलावा अलग-अलग वैज्ञानिक कम्यूनिटी की ज़रूरतों को पूरा करने के लिए भी किया जा रहा है. जैसे, ऐस्ट्रोफ़िज़िक्स. इसलिए, यह ज़रूरी है कि दस्तावेज़ ज़्यादा से ज़्यादा काम के और ऐक्सेस किए जा सकने वाले हों. इस प्रोजेक्ट की मदद से, CERN की कोशिश है कि Rucio के असली उपयोगकर्ताओं को एक बेहतर अनुभव मिले. साथ ही, यह फ़्रेमवर्क का इस्तेमाल करते हुए सभी ज़रूरी दस्तावेज़ों को एक ही जगह से ऐक्सेस कर सके.
मौजूदा स्थिति: फ़िलहाल, उपयोगकर्ता से जुड़े दस्तावेज़ अलग-अलग जगहों पर मौजूद हैं और कई फ़ॉर्मैट में हैं. इनमें वैज्ञानिक लेख, code में सोर्स के साथ Readthedocs.io, Google Drive, GitHub, DockerHub या Wikis शामिल हैं. कई सोर्स से, दस्तावेज़ के वर्शन को ट्रैक करने और उसके सही होने से जुड़ी समस्याएं आती हैं. इसके अलावा, दस्तावेज़ों के डिसेंट्रलाइज़्ड मॉडल से, किसी खास इस्तेमाल के उदाहरण के लिए नेविगेट करने और काम की जानकारी दिखाने में काफ़ी रुकावटें आती हैं. खास तौर पर, विकी के मामले में, किसी खास प्रयोग के लिए दी गई जानकारी, उसी/अन्य सोर्स में मौजूद अन्य इंस्टेंस पर भी लागू हो सकती है. हालांकि, डेटा को एक साथ इकट्ठा न करने और सही तरीके से लिंक न करने की वजह से, यह जानकारी इस्तेमाल नहीं की जाती है.
आपका सुझाया गया उपयोगकर्ता दस्तावेज़, मौजूदा दस्तावेज़ से बेहतर क्यों है? कई तरह की समस्याओं को देखते हुए, यहां दिए गए मॉडल में नेविगेशन, वर्शन, ट्रैकिंग, और दस्तावेज़ दिखाने से जुड़ी समस्याओं को हल किया गया है. इन समस्याओं के बारे में यहां बताया गया है:
दस्तावेज़ को फिर से बनाने का मकसद, असली उपयोगकर्ता के लिए नेविगेट करने में लगने वाली कोशिशों को आसान बनाना है. उसे जानकारी खोजने के लिए, अलग-अलग जगहों पर नहीं जाना पड़ेगा. इसकी वजह यह है कि जानकारी को आसानी से खोजने के लिए, उसे अलग-अलग कैटगरी में बांटा/लेबल किया जाएगा. एडमिन के तौर पर, वर्शन और ट्रैकिंग को आसानी से मैनेज किया जा सकेगा. ऐसा इसलिए, क्योंकि स्ट्रक्चर में बदलाव करने से, ज़रूरत के हिसाब से कैटगरी तय करने की सुविधा मिलती है. दोबारा बनाए गए सभी दस्तावेज़ों को एक ही जगह पर लाने से, यह पक्का किया जा सकेगा कि सभी जानकारी उपयोगकर्ता को दिख रही है. इसके लिए, अलग-अलग सोर्स से जानकारी भेजने की ज़रूरत नहीं है.
विश्लेषण: ज़रूरी शर्तों के बारे में जानकारी पढ़ने और मेंटरिंग टीम के साथ बातचीत करने के बाद, Rucio के दस्तावेज़ की मौजूदा स्थिति के बारे में मेरी राय यहां दी गई है:
दस्तावेज़ करने के छह मुख्य स्रोत हैं: - Google Drive लिंक : https://drive.google.com/drive/Folders/1EEN8l1dFjDSgavPrAMMooDjEodHP7aU7
Sphinx की मदद से काम करने वाला 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/AtlasDistributedComputing
वैज्ञानिक लेख लिंक: https://arxiv.org/abs/1902.09857
इन सोर्स के दस्तावेज़ अलग-अलग फ़ॉर्मैट में होते हैं. उदाहरण के लिए, Google Drive में Slides और Docs के तौर पर दस्तावेज़ होते हैं.GitHub में मुख्य रूप से reStructuredText मार्कअप भाषा में फ़ाइलें होती हैं वगैरह. इसमें वर्शन और ट्रैकिंग की सुविधा नहीं होती. इस वजह से, कई सोर्स पर ग़ैर-ज़रूरी जानकारी पब्लिश हो जाती है. जानकारी को लेबल या कैटगरी में नहीं रखा गया है. इसलिए, खोज करते समय पिछला अनुभव और विशेषज्ञता ज़रूरी है.
अलग-अलग फ़ॉर्मैट और सोर्स को ध्यान में रखते हुए, यह उम्मीद की जाती है कि जानकारी को फिर से व्यवस्थित किया जाए और mkdocs का इस्तेमाल करके उसे एक जगह पर इकट्ठा किया जाए. टूल के बारे में अपनी समझ को बेहतर बनाने के लिए, मैंने इनके इस्तेमाल के बारे में रिसर्च की है और इनके बारे में अच्छे से जाना है.
नतीजा: मौजूदा दस्तावेज़ बिना स्ट्रक्चर किए गए हैं और सही तरीके से लिंक नहीं किए गए हैं. साथ ही, इसमें एक ही फ़ॉर्मैट और सेंट्रलाइज़ेशन की सुविधा नहीं है. इस वजह से, उपयोगकर्ताओं को खोज के लिए ज़्यादा मेहनत करनी पड़ती है. इस तरह के अंतर से, एडमिन/रखरखाव करने वालों/लीड पर भी ग़ैर-ज़रूरी दबाव पड़ता है. इस वजह से, दस्तावेज़ों को अपडेट करने और उनके रखरखाव के लिए, कम्यूनिटी के हिसाब से काम करना मुश्किल हो जाता है. इससे, उपयोगकर्ता और योगदान देने वाले लोगों को काफ़ी खराब अनुभव मिलता है. साथ ही,
सुझाए गए दस्तावेज़ों का स्ट्रक्चर:
ज़रूरी शर्तों का पूरा विश्लेषण करने के बाद, मैंने दस्तावेज़ों के नए सिरे से तैयार किए गए मॉडल की मदद से, अहम समस्याओं को हल करने का फ़ैसला लिया है.
बदले गए स्ट्रक्चर का मॉडल, यहां अटैच किए गए मॉक-अप में दिखाया गया है. इसमें हर दस्तावेज़ को इन सात कैटगरी में बांटा जाएगा:
- इसके बारे में जानकारी
- शुरू करें
- कॉन्सेप्ट
- रूसियो इंटरफ़ेस
- Tasks
- ट्यूटोरियल
- बेहतर तरीके से जानकारी
बेशक, इस प्रोग्राम के खत्म होने के बाद, मुझे लिंक जोड़ने जैसे सुधार करने हैं. Rucio पर 500 पेटाबाइट डेटा को ऐक्सेस करने वाले 1,000 से ज़्यादा सक्रिय उपयोगकर्ता हैं. ऐसे में, इसके दस्तावेज़ों को फिर से व्यवस्थित करने के प्रस्ताव से, उपयोगकर्ताओं को सहायता मेलिंग सूची का इस्तेमाल करने की ज़रूरत काफ़ी कम हो जाएगी. इसका मकसद, क्लिक रेट की संख्या को कम करके और कैटगरी और लेबल की मदद से दस्तावेज़ों को आसानी से दिखाकर, उपयोगकर्ता अनुभव को बेहतर बनाना है. उपयोगकर्ता/ऑपरेशंस/एडमिन के नज़रिए से, आपको जो भी जानकारी चाहिए वह तीन क्लिक या उससे कम में उपलब्ध होगी.
मॉक-अप का लिंक: https://drive.google.com/file/d/1vSYgOkB9s9eEr2soNs7ujMLHzDlKn_hr/view?usp=sharing)
प्रोजेक्ट के लक्ष्य: - अलग-अलग सोर्स से मिलने वाली ग़ैर-ज़रूरी जानकारी का विश्लेषण करना और उसे हटाना. इसका मतलब है कि हर जानकारी के लिए एक सोर्स होना चाहिए. - मौजूदा दस्तावेज़ों को अलग-अलग हिस्सों में लेबल और कैटगरी में रखकर फिर से व्यवस्थित करना - mkdocs के आधार पर फिर से बनाए गए दस्तावेज़ को एक ही व्यू में माइग्रेट करना - फ़ाइल फ़ॉर्मैट की सीमाओं की वजह से माइग्रेट नहीं किए जा सकने वाले दस्तावेज़ को फिर से फ़ॉर्मैट करना/इंपोर्ट करना - समुदाय की ओर से दस्तावेज़ में बदलाव सेट अप करना, ताकि यह पक्का किया जा सके कि लिंक करने, जानकारी अपडेट करने या गड़बड़ियों को ठीक करने में कोई कमी रह गई है.
इस सिस्टम के लिए बुनियादी बातें पहले से ही मौजूद हैं, हालांकि, योगदान देने और मैनेज करने के लिए सही दस्तावेज़ देकर मेरा मॉडल मौजूदा सिस्टम को बेहतर बनाने के लिए काम करेगा. इसके अलावा, मेरा मकसद है कि इसमें GitHub के प्रोजेक्ट बोर्ड शामिल किए जाएं. इससे, प्रोजेक्ट से जुड़ी समस्याओं को ट्रैक करने और यह काम सही से करने में मदद मिलेगी.
टाइमलाइन: - 16 अगस्त से पहले --> दस्तावेज़ और Rucio के मौजूदा वर्शन के बारे में जानकारी हासिल करना --> नई तकनीकें और तकनीकी लेखन की नई स्किल सीखना, जो प्रोजेक्ट के दौरान मददगार होंगी --> GitHub पर दस्तावेज़ से जुड़ी समस्याओं को हल करना
कम्यूनिटी बॉन्डिंग (17 अगस्त से 13 सितंबर) --> टाइम ज़ोन के अंतर को समझने के लिए, कम्यूनिकेशन चैनल और समय सेट अप करें (पुणे में तीन घंटे 30 मिनट आगे हैं) --> लक्ष्यों को बेहतर बनाने में अहम समस्याएं हल की जा सकती हैं --> बातचीत में हिस्सा लेकर कम्यूनिटी, संगठन, और फ़्रेमवर्क के बारे में ज़्यादा जानें. --> संगठन के मेंटर और अन्य अहम सदस्यों के साथ, दस्तावेज़ के प्रस्तावित स्ट्रक्चर का आकलन करना. इससे यह पता चलता है कि दस्तावेज़ को लागू किया जा सकता है या नहीं. --> प्रस्तावित सुविधाओं को तय करना और ऐसे अन्य बदलाव जिन्हें मौजूदा दस्तावेज़ों में करने की ज़रूरत पड़ सकती है.
दस्तावेज़ तैयार करने की अवधि (14 सितंबर से 30 नवंबर) मैंने यहां जो फ़ॉर्मैट सुझाया है उसके आधार पर, मैंने दस्तावेज़ तैयार करने की अवधि के दौरान हासिल किए जाने वाले मुख्य माइलस्टोन के बारे में बताया है.
--> माइलस्टोन #1: कैटगरी तय करना और लेबल करना ETC: 28 सितंबर, 2020 उपलब्ध दस्तावेज़ों को एक साथ जोड़ने और उन्हें लेबल करने से, स्ट्रक्चर में बदलाव करने और कॉन्टेंट को कम करने की प्रोसेस को आसान बनाया जा सकता है.
--> माइलस्टोन #2: विश्लेषण, काट-छांट करना, और स्ट्रक्चर में बदलाव करना इत्यादि: 19 अक्टूबर, 2020 माइलस्टोन #1 के दौरान कैटगरी में बांटा गया दस्तावेज़, डुप्लीकेट और जानकारी के ग़ैर-ज़रूरी सोर्स के लिए विश्लेषण किया जाएगा. प्रोजेक्ट की जानकारी में बताया गया है कि हम उपलब्ध सभी जानकारी के लिए, एक सोर्स को टारगेट कर रहे हैं.
--> माइलस्टोन #3: दस्तावेज़ों को एक जगह पर इकट्ठा करना और उनका फ़ॉर्मैट बदलना: ETC: 9 नवंबर, 2020 दस्तावेज़ों को काट-छांट करके और उनका स्ट्रक्चर ठीक करने के बाद, मेरा मकसद सबसे पहले उनका फ़ॉर्मैट बदलना है. अलग-अलग सोर्स की वजह से, फ़ॉर्मैट अलग-अलग होते हैं. इसलिए, सबसे पहले इन्हें सही फ़ॉर्मैट में बदलना ज़रूरी है. ऐसा करने के बाद, डेटा को एक ही जगह पर इकट्ठा करने की प्रोसेस आसान हो जाएगी.
--> माइलस्टोन #4: ट्रैकिंग बोर्ड सेट अप करना + मैनेजमेंट/योगदान से जुड़े दस्तावेज़ वगैरह: 23 नवंबर, 2020 इस चरण का मकसद यह पक्का करना है कि प्रोजेक्ट पूरा होने के बाद भी, दस्तावेज़ अपडेट रहते हों. दिशा-निर्देश तय करने और प्रोजेक्ट बोर्ड सेट अप करने से, कम्यूनिटी के योगदान को इकट्ठा करने और उन्हें असरदार तरीके से ट्रैक करने में, एडमिन को आसानी होगी.
--> प्रोजेक्ट का आकलन (30 नवंबर से 5 दिसंबर) अपने प्रोजेक्ट की रिपोर्ट सबमिट करें और अपने मेंटर का आकलन करें Season of Docs में हिस्सा लेने के अपने अनुभव की रिपोर्ट लिखें और सबमिट करें.
यह प्रोजेक्ट क्यों? मेरा मानना है कि कोड के साथ अच्छी तरह से लिखे गए और वर्शन वाले दस्तावेज़ का इस्तेमाल करना, इसे और बेहतर तरीके से इस्तेमाल करने और अपनाने का एकमात्र तरीका है. व्यक्तिगत रूप से, मैं जिस तरह से CERN ने भौतिकी के अलग-अलग क्षेत्रों में आधुनिक रिसर्च शुरू की है, उससे बहुत दिलचस्प रही हूं. ऐसे एक्सपेरिमेंट के दौरान, प्रोसेस की गई, ट्रांसफ़र की गई, और जनरेट की गई जानकारी का स्केल बहुत बड़ा होता है. इसलिए, मुझे हमेशा यह जानने में दिलचस्पी रहती थी कि संगठन में रेफ़रंस और आने वाले समय में इस्तेमाल के लिए, डेटा को कैसे मैनेज किया जाता है. ऐसे फ़्रेमवर्क के दस्तावेज़ को बेहतर बनाने में योगदान देना मेरे लिए सम्मान की बात होगी जिसकी मदद से, कुछ बेहतरीन वैज्ञानिक रिसर्च और खोजें की जा रही हैं.
इस प्रोजेक्ट के लिए मैं सही व्यक्ति क्यों हूं? ज़रूरी शर्तें पूरी करने के अलावा, मुझे लगता है कि मैं इस प्रोजेक्ट के लिए सही व्यक्ति हूं, क्योंकि:
मैं पहले से ही Kubernetes के लिए मौजूदा दस्तावेज़ में बदलाव करने पर काम कर रहा हूं. इन योगदानों की वजह से, मुझे Kubernetes के 1.19 रिलीज़ साइकल के लिए, रिलीज़ दस्तावेज़ों के शेडो के तौर पर शामिल किया गया है. इसमें, रिलीज़ के दौरान जोड़ी गई नई सुविधाओं के दस्तावेज़ों को बेहतर तरीके से मैनेज और अपग्रेड करने में मेरी मदद की जाती है. मुझे लगता है कि बेहतर दस्तावेज़, किसी बेहतर प्रॉडक्ट/सेवा की बुनियाद होते हैं. चाहे वह प्रक्रिया से जुड़ी हो या तकनीकी जानकारी, वह जानकारी अच्छी तरह से लिखी गई हो, कम शब्दों में दी गई हो, और उसे आसानी से ऐक्सेस किया जा सकता हो. इससे, इस सुविधा को अपनाने और उसका बेहतर इस्तेमाल करने में मदद मिलेगी. अपने पूरे करियर में, डेटा-ड्रिवन डिस्ट्रिब्यूटेड सिस्टम के साथ काम करने के बाद, मुझे लगता है कि ऐसे सिस्टम के दस्तावेज़ से जुड़ी ज़रूरी शर्तों को समझने में मुझे कोई परेशानी नहीं होगी. मैं खुद एक असली उपयोगकर्ता हूं. इसलिए, मुझे पता है कि खराब तरीके से लिखे गए/गलत दस्तावेज़ों से क्या समस्याएं आ सकती हैं. साथ ही, मैं इस बात का ध्यान रखूंगा कि स्ट्रक्चर में बदलाव करते समय, इन समस्याओं को ध्यान में रखा जाए.