इस पेज पर Google Docs के सीज़न के लिए स्वीकार किए गए एक तकनीकी लेखन प्रोजेक्ट की जानकारी है.
प्रोजेक्ट की खास जानकारी
- ओपन सोर्स संगठन:
- बोकेह
- तकनीकी लेखक:
- vis_verborum
- प्रोजेक्ट का नाम:
- बनाना, पढ़ना, शेयर करना: Bokeh के दस्तावेज़ ऑप्टिमाइज़ करना
- प्रोजेक्ट की अवधि:
- मानक अवधि (तीन महीने)
प्रोजेक्ट का विवरण
बनाना, पढ़ना, और शेयर करना: Bokeh के दस्तावेज़ ऑप्टिमाइज़ करना
1. खास जानकारी
Bokeh, Python की मदद से ब्राउज़र पर आधारित इंटरैक्टिव विज़ुअलाइज़ेशन बनाने के लिए एक बेहतरीन टूल है. इसका बहुत बड़ा उपयोगकर्ता आधार (हर महीने 5.02 लाख कोंडा डाउनलोड, 8 लाख 55 हज़ार PyPi डाउनलोड) और योगदान देने वाले बड़ी संख्या (GitHub पर 455 योगदान देने वाले) हैं. इसमें कोई हैरानी की बात नहीं है कि बोकेह के पूरे दस्तावेज़ ऑर्गैनिक तरीके से उगाए गए. इस वजह से, एक ही जगह पर अलग-अलग तरह की गतिविधियां होती हैं. ऐसे में, उन्हें ऐक्सेस करना मुश्किल और जटिल होता है.
Google के Docs का सीज़न, Bokeh के दस्तावेज़ों के स्ट्रक्चर और कॉन्टेंट की बारीकी से समीक्षा करने और उनमें बदलाव करने का अनोखा अवसर देता है. इसकी मदद से, यह भी पक्का किया जाता है कि दस्तावेज़, उससे जुड़े टूल, और वर्कफ़्लो, आने वाले समय के लिए बेहतर साबित हों.
मैंने Python और स्फ़िंक्स (सबसे हाल के प्रोजेक्ट: PyZillow और PyPresseportal) के साथ ओपन-सोर्स प्रोजेक्ट को कोड किया है और दस्तावेज़ तैयार किया है. हालांकि, पत्रकारिता के क्षेत्र में मेरी बैकग्राउंड की वजह से, मैं Google के सीज़न में खास तौर पर हिस्सा लेता हूं. मैंने न्यूज़रूम में 13 साल से ज़्यादा समय तक काम किया है. मैंने कई सालों तक डिजिटल बदलाव को मैनेज करने और एडिटर के तौर पर काम किया. पत्रकारिता के मेरे काम के अलावा, नए डिजिटल टूल और स्टाइल गाइड को डिज़ाइन करने और उनका लेखा-जोखा रखने के साथ-साथ न्यूज़रूम के कर्मचारियों को ट्रेनिंग देने की ज़िम्मेदारी भी मेरी बढ़ गई थी.
हाल ही में यूरोप से अमेरिका आने के बाद, मैंने कम्यूनिकेशन और कोडिंग के प्रति अपने उत्साह को एक साथ लाने के नए तरीके आज़माने का फ़ैसला किया. मुझे तकनीकी लेखन, लेखन और टेक्नोलॉजी में अपने कौशल और अनुभव का सबसे बेहतर मिला-जुला रूप मिला. इस प्रस्ताव में, मैं आपको बताऊंगा कि मैं Bokeh के दस्तावेज़ों को ऑप्टिमाइज़ करने के लिए Google के Docs सीज़न का इस्तेमाल कैसे करूंगा: दस्तावेज़ बनाना और दस्तावेज़ों में योगदान को ज़्यादा आसान बनाकर, दस्तावेज़ को पढ़ना आसान बनाकर और अन्य लोगों के साथ दस्तावेज़ में जानकारी शेयर करना आसान बनाकर.
2. मौजूदा स्थिति
Bokeh के आधिकारिक दस्तावेज़ में ये मुख्य यूनिट शामिल हैं:
- जानकारी से जुड़ा दस्तावेज़: इंस्टॉल करने की गाइड, इस्तेमाल के लिए गाइड, डेवलपर गाइड, प्रॉडक्ट की जानकारी
- गैलरी और डेमो (सोर्स कोड के साथ इंटरैक्टिव उदाहरण)
- रेफ़रंस गाइड (docstrings पर आधारित दस्तावेज़)
- ट्यूटोरियल (Jupyter notebooks का बहुत बड़ा कलेक्शन, इसे mybinder.org पर होस्ट किया गया है)
- IDEs के लिए डॉकस्ट्रिंग और मॉडल से जुड़ी सहायता
- प्रोजेक्ट डेटा स्टोर करने की जगह में उदाहरण और README
इसके अलावा, बहुत सारी जानकारी Bokeh सहायता फ़ोरम और Stack Overflow पर उपलब्ध है, जहां Bokeh का डेवलपर सक्रिय रूप से उपयोगकर्ता के सवालों के जवाब देता है. साथ ही Bokeh के Medium ब्लॉग पर भी.
ज़्यादातर दस्तावेज़ों वाले वेब पेज स्फ़िंक्स की मदद से बनाए गए हैं, जिनमें कई मानक और कस्टम स्फ़िंक्स एक्सटेंशन का इस्तेमाल किया गया है. उदाहरण के लिए, रेफ़रंस गाइड को docstrings से जनरेट किया जाता है. इसके लिए, ‘autodoc’ और कस्टम ‘bokeh_autodoc’ जैसे एक्सटेंशन का इस्तेमाल किया जाता है. ऑर्गैनिक रूप से विकसित किए गए दस्तावेज़ों में दिया गया डेटा, ग़ैर-ज़रूरी और अलग-अलग तरह का है.
मौजूदा दस्तावेज़ों का विश्लेषण करते समय, सबसे पहले मुझे दस्तावेज़ लिखने के स्टाइल से जुड़े दिशा-निर्देशों का साफ़ तौर पर पता न चलना था. Bokeh की डेवलपर गाइड में कुछ बुनियादी निर्देश दिए गए हैं. हालांकि, इस दस्तावेज़ में शैली के बारे में ज़्यादा दिशा-निर्देश नहीं हैं, खास तौर पर docstrings से आगे की जानकारी देने वाले दस्तावेज़ों के बारे में. इस वजह से, स्टाइल और स्ट्रक्चर से जुड़ी समस्याओं की वजह से, दस्तावेज़ों में मौजूद जानकारी को ऐक्सेस करना और भी मुश्किल हो जाता है. खास तौर पर, नए लोगों के लिए यह काम मुश्किल हो जाता है.
उदाहरण के लिए:
- साफ़ और मज़बूत क्रियाओं के बजाय संज्ञा, जर्ंड, और असामान्य शब्दों का इस्तेमाल करने से कुछ टेक्स्ट को समझना मुश्किल हो जाता है: “मुख्य बात यह है कि सामान्य इस्तेमाल में फ़िगर() फ़ंक्शन की मदद से प्लॉट ऑब्जेक्ट बनाना शामिल है”. इसे पढ़ने में आसानी हो, इसके लिए इसे अलग तरीके से लिखा जाना चाहिए. उदाहरण के लिए: “Figure() फ़ंक्शन, प्लॉट ऑब्जेक्ट बनाने के लिए सबसे ज़्यादा इस्तेमाल किया जाने वाला फ़ंक्शन है.”
- कुछ वाक्य बहुत लंबे हैं, जिन्हें समझना मुश्किल है: “इसके बाद, हम vbar को x कॉर्डिनेट, बार की ऊंचाई, और वैकल्पिक रूप से किसी भी चौड़ाई या ऐसी प्रॉपर्टी के तौर पर कॉल कर सकते हैं जिसे हम सेट करना चाहते हैं". लंबे वाक्यों को छोटे वाक्यों या बुलेट वाली सूचियों में बांटा जा सकता है. वाक्यों को आसान बनाने से, खास तौर पर डिस्लेक्सिया से पीड़ित लोगों को मदद मिलेगी. साथ ही, इससे उन लोगों को मदद मिलेगी जो अपनी मुख्य भाषा के तौर पर अंग्रेज़ी का इस्तेमाल नहीं करते हैं (समस्या #10160 देखें).
- “आप” और “हम”, दोनों का एक जैसा इस्तेमाल, जिससे भ्रम की स्थिति पैदा होती है और लोगों का ध्यान भटकता है: “इस्तेमाल के उदाहरण के हिसाब से, दो ऐसे बुनियादी तरीके इस्तेमाल किए जा सकते हैं जिनका इस्तेमाल किया जा सकता है” और “हम अलग-अलग कॉल का इस्तेमाल करके पूरे साल सीरीज़ प्लॉट कर सकते हैं” (एक ही पेज के दो उदाहरण). कुछ पेज लोगों से अलग-अलग तरीकों से भी संपर्क करते हैं. जैसे: “उपयोगकर्ताओं को अतिरिक्त डिपेंडेंसी इंस्टॉल करनी पड़ सकती हैं” या “कोई व्यक्ति ज़्यादा जटिल लेआउट बना सकता है”.
- टाइपिंग में गड़बड़ी, ग़ैर-ज़रूरी शब्द, और व्याकरण की गलतियां, पढ़ने का फ़्लो और जानकारी को भरोसेमंद नहीं बनाती: “बोकेह ने बुनियादी बार चार्ट बनाना आसान बना दिया है” या “उपयोगकर्ता की गाइड के ग्लिफ़ सेक्शन देखें”.
- अलग-अलग स्ट्रक्चर में होने वाली गड़बड़ियां, पढ़ने वालों को परेशान कर सकती हैं: उदाहरण के लिए, एक पेज पर अच्छी तरह से एनोटेट किए गए उदाहरण और दूसरे पेज पर उदाहरणों की जानकारी न देना.
Bokeh का दस्तावेज़ लैंडिंग पेज छोटा है और इसमें सभी उपलब्ध संसाधनों की जानकारी शामिल नहीं है (डॉकस्ट्रिंग और मॉडल सहायता फ़ंक्शन, सहायता फ़ोरम, डेमो या Medium ब्लॉग की पूरी जानकारी वाली लाइब्रेरी का कोई ज़िक्र नहीं). इससे नए उपयोगकर्ताओं के लिए, Bokeh का इस्तेमाल शुरू करना और भी मुश्किल हो जाता है.
3. गोल
11 हफ़्ते के दस्तावेज़ डेवलपमेंट फ़ेज़ का बेहतर तरीके से इस्तेमाल करने के लिए, मैं तीन मुख्य एलिमेंट पर फ़ोकस करूंगा:
3.1. दस्तावेज़ बनाने के तरीके को बेहतर बनाना
Bokeh के ज़्यादातर दस्तावेज़, योगदान देने वाले लोगों ने लिखे हैं. इन दस्तावेज़ों में नई सुविधाओं और गड़बड़ियों को ठीक करने के लिए, पुल के अनुरोधों में दस्तावेज़ शामिल किए जाते हैं. मौजूदा दस्तावेज़ों में बदलाव करने और उन्हें रीफ़ैक्टर करने के लिए, मैं दस्तावेज़ तैयार करने से जुड़े कुछ चरण इस्तेमाल करूंगा/करूंगी. हालांकि, मुझे आने वाले समय में दस्तावेज़ बनाने और इनके रखरखाव के लिए, वर्कफ़्लो को ध्यान में रखना होगा: योगदान देने वालों के लिए, दस्तावेज़ों के स्टैंडर्ड को लगातार बेहतर बनाए रखना जितना हो सके उतना आसान होना चाहिए.
मुझे दो तरीकों से यह पक्का करना है:
- मैं मौजूदा डेवलपर गाइड में शामिल किए जाने के लिए व्यावहारिक और आसान स्टाइल के दिशा-निर्देशों का एक सेट तैयार करूंगा/करूंगी. इन दिशा-निर्देशों में स्टाइल, व्याकरण, और स्ट्रक्चर के बारे में बताया गया है. इसके अलावा, मैं Slack जैसे अंदरूनी कम्यूनिकेशन चैनलों का इस्तेमाल करूं, ताकि यह पक्का किया जा सके कि बोकेह में योगदान देने वालों को स्टाइल के दिशा-निर्देशों के बारे में पता है. मैं टीम के लिए व्यक्तिगत तौर पर ट्रेनिंग और सवाल-जवाब के सेशन भी मुहैया कराएगा.
- मैं कोर टीम के साथ मिलकर दस्तावेज़ की क्वालिटी कंट्रोल करने के लिए टूल का बेहतर सेट ढूंढूंगा. इन टूल को Bokeh के मौजूदा वर्कफ़्लो में जोड़ दिया जाएगा. इसे पीआर (अनुरोध पाने के लिए अनुरोध) और सीआई (लगातार इंटिग्रेशन) के लिए इस्तेमाल किया जाएगा. टीम की ज़रूरतों के हिसाब से, Bokeh के टेस्टिंग सुइट में pydocstyle, proselint या sphinxconrib-स्पेलिंग जैसे टूल जोड़े जा सकते हैं. स्पेल चेक की सुविधा, प्री-कमिट सेटअप या GitHub ऐक्शन पर भी लागू होगी. मैंने अपने ओपन-सोर्स प्रोजेक्ट में से एक की GitHub की कार्रवाइयों में, काम करने वाले सिद्धांत का एक सबूत जोड़ा है.
3.2. दस्तावेज़ पढ़ने की सुविधा को बेहतर बनाएं
अच्छे दस्तावेज़ों का मकसद मौजूदा और संभावित उपयोगकर्ताओं के लिए, सही जानकारी ढूंढना आसान बनाना और इस जानकारी का बेहतर तरीके से इस्तेमाल करना है.
किसी टेक्स्ट की उपयोगिता की मुख्य वजहें हैं, उसकी स्टाइल और स्ट्रक्चर: दस्तावेज़ को साफ़ और एक जैसी स्टाइल में लिखने से, पाठक ध्यान भटकाने वाली चीज़ों और ग़ैर-ज़रूरी भाषा के बिना, तुरंत जानकारी पा सकते हैं. दस्तावेज़ की सीधी और पारदर्शी संरचना की मदद से, काम की जानकारी को तेज़ी से ढूंढना आसान हो जाता है.
मैं इन दोनों चीज़ों पर ज़्यादा ध्यान दूँगा. साथ ही, नए उपयोगकर्ताओं को इस्तेमाल करने पर ज़ोर दूँगा. इसमें उपयोगकर्ता गाइड पर आधारित नैरेटिव दस्तावेज़ की पूरी समीक्षा शामिल होगी. मैं अलग-अलग टारगेट ऑडियंस के बारे में ज़्यादा साफ़ तौर पर जानकारी देने के लिए, दस्तावेज़ वाले लैंडिंग पेज को भी पूरा करूंगा/करूंगी. साथ ही, यह पक्का करूंगा/करूंगी कि हर उपयोगकर्ता को सही संसाधन तेज़ी से मिलें.
ऊपर बताए गए दस्तावेज़ों के बनाने में सुधार करने की तरह ही, मैं आने वाले समय में सुधारों की बुनियाद तैयार करने और Bokeh के दस्तावेज़ों को लगातार बेहतर बनाने पर फ़ोकस करूंगा.
3.3. दस्तावेज़ शेयर करने के तरीके को बेहतर बनाएं
Bokeh को लेकर ज़्यादा से ज़्यादा चर्चा तीसरे पक्ष के प्लैटफ़ॉर्म पर हो रही है. इनमें से कई प्लैटफ़ॉर्म लिंक की बेहतरीन झलक शामिल करने के लिए, Facebook OpenGraph जैसे मेटाडेटा का इस्तेमाल करते हैं. OpenGraph का इस्तेमाल, Facebook, Twitter, LinkedIn, Slack, और iMessage जैसी सेवाओं में किया जा रहा है. Bokeh का बातचीत फ़ोरम, लिंक की झलक दिखाने के लिए OpenGraph का भी इस्तेमाल करता है.
इस टेक्नोलॉजी का इस्तेमाल करने के लिए, मुझे Bokeh के SKAdNetwork ने बनाए गए वेब पेजों में मेटाडेटा जोड़ा है, जैसा कि समस्या #9792 में बताया गया है. सबसे कारगर तरीका होगा, खास एक्सटेंशन का इस्तेमाल करना. कुछ दिन पहले, OpenGraph डेटा के लिए Sling एक्सटेंशन का पहला वर्शन GitHub पर पब्लिश किया गया था. मैं Bokeh के दस्तावेज़ों के साथ इस एक्सटेंशन को बेहतर बनाने के लिए, दस्तावेज़ डेवलपमेंट के कुछ फ़ेज़ का इस्तेमाल करूंगा/करूंगी.
मैंने इस अवधारणा का एक प्रमाण भी तैयार किया है कि मैं अपने एक ओपन-सोर्स प्रोजेक्ट, PyPresseportal में से एक में सफलतापूर्वक उपयोग कर रहा/रही हूं. यह एक्सटेंशन, काम की जानकारी अपने-आप इकट्ठा करता है. जैसे, टाइटल, ब्यौरा, इमेज, और यूआरएल. फिर यह इस जानकारी को OpenGraph टैग के रूप मेंSphinx से जनरेट किए गए एचटीएमएल-कोड में डाल देता है.
इस एक्सटेंशन को डेवलप करने का अगला कदम होगा, OpenGraph मेटाडेटा को मैन्युअल रूप से परिभाषित करने के लिए कस्टम निर्देश (docutil के मौजूदा ‘meta’ डायरेक्टिव की तरह). मैन्युअल तरीके से जनरेट किया गया डेटा उपलब्ध न होने पर, अपने-आप जनरेट होने वाले मेटाडेटा का इस्तेमाल, सिर्फ़ फ़ॉलबैक के तौर पर किया जाएगा.
स्ट्रक्चर्ड डेटा के साथ काम करना काफ़ी मुश्किल काम है. इसलिए, हम Bokeh के दस्तावेज़ों में अच्छी क्वालिटी वाला OpenGraph मेटाडेटा शामिल करने पर फ़ोकस करेंगे. OpenGraph के लिए किए जाने वाले सभी काम के साथ-साथ, स्ट्रक्चर्ड डेटा से जुड़ी सहायता की नींव रखी जाएगी.
स्फ़िंक्स और ReadTheDocs समुदाय के सदस्यों ने OpenGraph और स्ट्रक्चर्ड डेटा के लिए एक्सटेंशन डेवलप करने में दिलचस्पी दिखाई है (उदाहरण के लिए, #1758 और #5208 अंकों में) और मुझे उनके साथ मिलकर काम करना होगा.
4. सेवाएं
संक्षेप में, मुझे Docs के सीज़न में ये कुछ डिलीवर करने की उम्मीद है:
- Bokeh में योगदान देने वालों के लिए दस्तावेज़ की स्टाइल से जुड़े दिशा-निर्देश
- दस्तावेज़ की क्वालिटी को अपने-आप कंट्रोल करने की सुविधा को शामिल करने के लिए, पीआर और सीआई वर्कफ़्लो में बदलाव किया गया है
- बदलाव की गई और दोबारा बनाई गई उपयोगकर्ता गाइड
- अपडेट किए गए दस्तावेज़ का लैंडिंग पेज
- दस्तावेज़ के वेब पेजों और चालू स्फ़िंक्स एक्सटेंशन में OpenGraph मेटाडेटा शामिल है
इसके अलावा, मैं अपनी निजी वेबसाइट/मीडियम या Bokeh के मीडियम ब्लॉग पर, Google के Docs के सीज़न से जुड़ी अपनी यात्रा को दस्तावेज़ के तौर पर सेव करने के लिए, एक "डॉकलॉग" रखूंगा. यह Google के लिए प्रोजेक्ट रिपोर्ट की बुनियाद के तौर पर भी काम करेगा. मैं GitHub से जुड़ी समस्याओं और अनुरोध को प्रोसेस करने के लिए, पारदर्शी तरीके से अपना काम पूरा करूंगी.
5. टाइमलाइन
समुदाय से जुड़ने के चरण से पहले: मैं Bokeh के GitHub डेटा स्टोर करने की जगह पर कई चर्चाओं में पहले से ही हिस्सा ले रहा/रही हूं. साथ ही, मैंने ब्रायन वैन डे वेन और पविथरा ईश्वारामूर्ति के साथ संपर्क बनाए हैं, जो कि बोके के Google के सीज़न के लिए मेंटॉर हैं. मैं Bokeh के बारे में हुई बातचीत पर लगातार नज़र बनाए रख सकता हूं. साथ ही, विज़ुअलाइज़ेशन बनाकर और पब्लिश करके Bokeh को बेहतर तरीके से समझूंगा.
समुदाय से जुड़ने का चरण (17/08 से 13/09):
- मेंटॉर के साथ शेयर करके, कोर टीम से मिलें और प्रोजेक्ट प्लान को बेहतर बनाएं
- नियमित तौर पर रिपोर्ट पाने और मेंटॉर से सुझाव या राय पाने के लिए, शेड्यूल और बातचीत का तरीका सेट अप करें
- Bokeh के Slack का इस्तेमाल करके, Bokeh पर योगदान देने वाले सभी लोगों को Google के Docs सीज़न के बारे में बताएं. साथ ही, दस्तावेज़ डेवलप करने के लक्ष्यों के बारे में बताएं
- बोकेह में योगदान देने वालों से सुझाव लें, ताकि दस्तावेज़ डेवलप करने के प्लान को और बेहतर बनाया जा सके
दस्तावेज़ डेवलपमेंट का चरण
1 हफ़्ता, 09/14 से 09/20:
- ब्यौरे से जुड़े दस्तावेज़ों का ऑडिट और उनमें बदलाव करना शुरू करें
- स्टाइल के लिए दिशा-निर्देश ड्राफ़्ट करना शुरू करें
हफ़्ता 2, 09/21 से 09/27:
- शैली के दिशा-निर्देशों पर काम करते रहें
- ब्यौरे से जुड़े दस्तावेज़ में बदलाव करना जारी रखें
- दस्तावेज़ के लैंडिंग पेज को पूरी तरह बदलना शुरू करें
हफ़्ता 3, 09/28 से 10/04:
- शैली के लिए दिशा-निर्देश तय करें
- दस्तावेज़ का लैंडिंग पेज बनाएं
चौथा हफ़्ता, 10/05 से 10/11:
- कहानी के दस्तावेज़ में बदलाव करें
- Bokeh की कोर टीम से PR/CI वर्कफ़्लो में दस्तावेज़ क्वालिटी कंट्रोल करने के लिए, टूल इंटिग्रेट करने के बारे में चर्चा करें
पांचवां हफ़्ता, 10/12 से 10/18:
- स्टाइल के दिशा-निर्देशों, कहानी से जुड़े दस्तावेज़ों को बेहतर बनाने, और पीआर/सीआई वर्कफ़्लो पर चर्चा करने के लिए, Slack पर बोकेह में योगदान देने वालों के साथ सवाल-जवाब का सेशन सेट अप करें
- OpenGraph मेटाडेटा के लिए अपने मौजूदा सिद्धांत के प्रमाण को एक डिप्लॉयमेंटेबल स्फ़िंक्स एक्सटेंशन में डेवलप करना शुरू करें
- Bokeh पर योगदान देने वालों के साथ सवाल और जवाब के सेशन से मिले सुझाव के आधार पर स्टाइल के दिशा-निर्देशों में बदलाव करें
छठा हफ़्ता, 10/19 से 10/25:
- PR और CI वर्कफ़्लो में दस्तावेज़ की क्वालिटी कंट्रोल करने वाले टूल की जांच शुरू करें
- मेटाडेटा के लिए Sling एक्सटेंशन का डेवलपमेंट जारी रखें
हफ़्ता 7, 10/26 से 11/01:
- स्फ़िंक्स एक्सटेंशन की टेस्टिंग
- Slack पर बोकेह में योगदान देने वालों के साथ सवाल-जवाब का दूसरा सेशन
- सवाल और जवाब के दूसरे सेशन में मिले सुझाव, राय या शिकायत के आधार पर उपलब्ध कराए जा सकने वाले कामों में बदलाव करें
हफ़्ता 8, 11/02 से 11/08:
- स्फ़िंक्स एक्सटेंशन को डिप्लॉय करें और कहानी के बेहतर दस्तावेज़ और दस्तावेज़ का लैंडिंग पेज पब्लिश करें
हफ़्ता 9, 11/09 से 11/15:
- पीआर और सीआई वर्कफ़्लो में दस्तावेज़ क्वालिटी कंट्रोल टूल का इस्तेमाल करें
- शैली के लिए दिशा-निर्देश के साथ-साथ PR और सीआई वर्कफ़्लो को शामिल करने के लिए, डेवलपर गाइड को अपडेट और पब्लिश करें
हफ़्ता 10, 11/16 से 11/22:
- बचे हुए टास्क पूरे करें
हफ़्ता 11, 11/23 से 11/29:
- प्रोजेक्ट रिपोर्ट लिखना शुरू करें
- प्रोजेक्ट का आकलन लिखना शुरू करें
प्रोजेक्ट को पूरा करने का चरण
हफ़्ता 12, 11/30 से 12/05:
- प्रोजेक्ट रिपोर्ट को फ़ाइनल करें और सबमिट करें
हफ़्ता 13, 12/03 से 12/10:
- प्रोजेक्ट की समीक्षा को फ़ाइनल करें और सबमिट करें
Google के Docs सीज़न के खत्म होने के बाद:
- मुझे उम्मीद है कि मैं Bokeh के डेवलपमेंट में शामिल हूं और Bokeh के दस्तावेज़ों पर काम करना जारी रखूंगा.
- OpenGraph/स्ट्रक्चर्ड डेटा मेटाडेटा के लिए स्फ़िंक्स एक्सटेंशन के डेवलपमेंट को जारी रखने की मेरी योजना है.
- मुझे उम्मीद है कि मैं पत्रकारिता के क्षेत्र में अपने बैकग्राउंड और अपने मौजूदा नेटवर्क का इस्तेमाल करके, डेटा पत्रकारिता के क्षेत्र में Bokeh का प्रमोशन करना चाहता हूं. उदाहरण के लिए, पत्रकारिता के दर्शकों को ध्यान में रखते हुए Bokeh के बारे में लिखना या पत्रकारिता के क्षेत्र में Bokeh का इस्तेमाल करने के बारे में कॉन्फ़्रेंस में हिस्सा लेना.
6. मेरे बारे में
मैं मूल रूप से एक पत्रकार हूं और मैं टीवी, ऑनलाइन, और रेडियो खबरों में माहिर हूं. टीवी और डिजिटल न्यूज़ में मैनेजिंग एडिटर और रिपोर्टर के तौर पर काम करके, मुझे लिखने और एडिट करने का सालों का अनुभव मिला है. इसके साथ ही, मैंने ऐसे कई प्रोजेक्ट पर काम किया जो डिजिटल ट्रांसफ़ॉर्मेशन और ऑटोमेशन को बढ़ावा देते हैं. मैंने डिजिटल टूल और वर्कफ़्लो के साथ-साथ, डिजिटल न्यूज़ ब्रैंड के लिए स्टाइल गाइड और कम्यूनिकेशन की रणनीतियों पर कई मैन्युअल तरीके से काम किया. मैंने टीम के सदस्यों को उन टूल का इस्तेमाल करना भी सिखाया है.
कम्यूनिकेशन और टेक्नोलॉजी के बीच के अंतर को समझने के लिए, हमेशा मुझे एक नई दुनिया मिली. Python में कोडिंग सीखने के बाद, मुझे एक नई दुनिया देखने लगी: उदाहरण के लिए, मैंने डेटा पत्रकारिता के लिए डेटा विश्लेषण और विज़ुअलाइज़ेशन करने का काम किया. कोडिंग सीखने से मुझे सॉफ़्टवेयर इंजीनियर के साथ मिलकर काम करने में भी मदद मिली, ताकि न्यूज़रूम वर्कफ़्लो के लिए डिजिटल टूल डेवलप किए जा सकें.
मैंने पिछली नौकरी में जो मैन्युअल और दस्तावेज़ लिखे थे वे सभी सार्वजनिक नहीं हैं. इसलिए, अब मैं ओपन-सोर्स प्रोजेक्ट के साथ ज़्यादा से ज़्यादा काम करने पर ध्यान दे रही हूं (उदाहरण के लिए नीचे देखें). मैंने Google की डेवलपर दस्तावेज़ स्टाइल गाइड और Microsoft स्टाइल गाइड जैसी स्टाइल गाइड पर अपने तकनीकी लेखन को आधार बनाया है. मैं नियमित तौर पर GitHub, Slack, और Linux का इस्तेमाल करता/करती हूँ. मैं स्फ़िंक्स, मिपी, और स्फ़िंक्स ऑटोडॉक जैसे टूल का इस्तेमाल करके कहानी के दस्तावेज़ों के साथ-साथ डॉकस्ट्रिंग और टाइप हिंट लिख रहा हूं.
अभी मैं फ़्रीलांस का काम कर रहा हूं. मेरे शेड्यूल से आपको दस्तावेज़ तैयार करने के दौरान, हर हफ़्ते करीब 25 घंटे तक, Bokeh के दस्तावेज़ों पर काम करने की सुविधा मिलती है. मैं पैसिफ़िक टाइम ज़ोन में काम करता हूं. हालांकि, टीम के शेड्यूल और ज़रूरतों को पूरा करके मुझे खुशी मिलती है.
7. ओपन सोर्स दस्तावेज़ों के हाल ही के उदाहरण
PyZillow: PyZillow, रीयल एस्टेट वेबसाइट Zillow.com के एपीआई के लिए एक Python रैपर है. कुछ कोड देने और कोड मेंटेनर के तौर पर काम करने के अलावा, मैंने पूरा दस्तावेज़ लिखा. मैंने स्फ़िंक्स का इस्तेमाल कहानी के दस्तावेज़ों और मॉड्यूल के लिए किया. मैंने कोड में जोड़ी गई docstrings के आधार पर, स्फ़िंक्स एक्सटेंशन ऑटोडॉक के साथ मॉड्यूल रेफ़रंस बनाया है.
PyPresseportal: PyPree पोर्टल वेबसाइट प्रेस पोर्टल के एपीआई के लिए Python रैपर है. PresseDL.de वेबसाइट, जर्मनी में प्रेस रिलीज़ और निवेशक संबंध से जुड़ी सूचनाओं के सबसे बड़े डिस्ट्रिब्यूटर में से एक है. उदाहरण के लिए, अपनी प्रेस रिलीज़ देने के लिए करीब सभी पुलिस और फ़ायर डिपार्टमेंट इस सेवा का इस्तेमाल करते हैं. एक पत्रकार के तौर पर कई सालों तक इस एपीआई का इस्तेमाल करने के बाद, मैंने एक Python इंटरफ़ेस डेवलप करने का फ़ैसला लिया, ताकि वेबसाइट के हर तरह के डेटा संसाधनों को Python ऑब्जेक्ट के तौर पर ऐक्सेस किया जा सके. मैंने कोड और पूरा स्फ़िंक्स आधारित दस्तावेज़ लिखा है.