इस पेज में, Docs के Google सीज़न के लिए स्वीकार किए गए तकनीकी राइटिंग प्रोजेक्ट की जानकारी दी गई है.
प्रोजेक्ट की खास जानकारी
- ओपन सोर्स संगठन:
- SciPy
- तकनीकी लेखक:
- mkg33
- प्रोजेक्ट का नाम:
- उपयोगकर्ता के हिसाब से बनाए गए दस्तावेज़ और बेहतर तरीके से स्ट्रक्चर करना
- प्रोजेक्ट की अवधि:
- मानक अवधि (तीन महीने)
प्रोजेक्ट का विवरण
प्रेरणा:
मेरा मकसद मौजूदा दस्तावेज़ों की रीफ़ैक्टरिंग पर काम करना है, ताकि अलग-अलग ज़रूरतों वाले लोग इन्हें आसानी से ऐक्सेस कर सकें. इसका मतलब यह है कि कोई रिसर्चर, ऐडवांस और ज़रूरी सुविधाओं में सबसे ज़्यादा दिलचस्पी रखता है. वहीं, बिना किसी विशेषज्ञता के कोई उपयोगकर्ता सिलसिलेवार निर्देश और डायग्राम देखना पसंद करता है.
मेरी दिलचस्पी इस प्रोजेक्ट में निजी और पेशेवर वजहों से है. सबसे पहले, मैं SciPy में अहम योगदान देना चाहता/चाहती हूं, क्योंकि इससे मुझे काफ़ी फ़ायदा मिला. दूसरी, दूसरे सॉफ़्टवेयर में अक्सर मुझे ज़रूरत से कम (या कम) दस्तावेज़ मिलते हैं और मैं हमेशा सोचता रहता हूं कि गाइड से मिले कोड को इस्तेमाल करने में कितनी तेज़ी (अगर ऐसा है तो!) कैसे.
लक्ष्य:
मेरा मकसद SciPy के मौजूदा दस्तावेज़ों को कॉन्टेंट और ग्राफ़िक, दोनों के हिसाब से बेहतर बनाना है. इस समस्या को हल करने के लिए मेरे तरीके की सबसे अहम सुविधा, उपयोगकर्ता सर्वे को डिप्लॉय करना और उसका विश्लेषण करना है. इसका मतलब है कि ऑनलाइन किया जाने वाला एक छोटा सा सर्वे, जिसमें अलग-अलग उपयोगकर्ताओं को दस्तावेज़ से जुड़ी अपनी ज़रूरतों के बारे में बताने का मौका मिलता है. मेरा मानना है कि उनकी राय प्रेरणा का स्रोत होनी चाहिए (हम लोगों के लिए आसान दस्तावेज़ और कैसे बना सकते हैं?).
प्रोजेक्ट के असल हिस्से की बात करें, तो पहले चरण में उपयोगकर्ता सर्वे को डिज़ाइन और उसका विश्लेषण करना शामिल है. इसके साथ ही, स्टाइल से जुड़ी ऐसी कई समस्याओं को हल करना भी शामिल है जो मुझे मौजूदा डॉक्यूमेंट्री में देखने को मिली हैं. उदाहरण के लिए, एक जैसा न होना (उदाहरण: द्वि-डाइमेंशन वाले अरे के साथ में मौजूद 2-डाइमेंशन वाली अरे), ऐसे जटिल वाक्य जिन्हें फिर से लिखा जाना चाहिए या कुछ सबपेज में वर्णमाला के क्रम में मौजूद नहीं हैं. दूसरे चरण में, काम के विषयों के हाइपरलिंक वाले ग्राफ़िक की मदद से जानकारी देने पर फ़ोकस किया जाएगा. ये गाइड, सर्वे के नतीजों और अन्य कम्यूनिकेशन अनुरोधों के आधार पर तय किए जाएंगे. आने वाले समय में, मुझे अलग-अलग तरह के उपयोगकर्ताओं के मुताबिक, काम के दस्तावेज़ चाहिए. इसके अलावा, मैं ट्यूटोरियल को भाषा और बनावट के हिसाब से एक जैसा बनाने की कोशिश करूंगी. आखिर में, मेरा मकसद कम्यूनिटी की मौजूदा ज़रूरतों के आधार पर नए ट्यूटोरियल लिखना है.
उपयोगकर्ता सर्वे:
जहां तक उपयोगकर्ता सर्वे के लिए, हमारा सुझाव है कि आप Google Forms का इस्तेमाल कई वजहों से कर सकते हैं. सबसे पहले, Google Forms मुफ़्त में उपलब्ध है और इसकी मदद से कई काम किए जा सकते हैं. उदाहरण के लिए, जवाब देने वालों, सवालों वगैरह की संख्या के हिसाब से, इसका विज़ुअल फ़ॉर्म, सबसे ज़्यादा फ़ायदेमंद सर्वे के विकल्प (उदाहरण के लिए, पसंद के मुताबिक लीनियर स्केल, चेकबॉक्स, और कई विकल्प वाले सवाल) और सबसे ज़रूरी बात, नतीजे आंकड़ों के विश्लेषण के लिए आसानी से एक्सपोर्ट किए जा सकते हैं. ऑनलाइन रिसर्च के आधार पर, ऐसा लगता है कि फ़िलहाल Google Forms, सर्वे करने के लिए सबसे अच्छा मुफ़्त टूल है. अगर हम इसे ज़्यादा गंभीरता से न लें, तो Google की ओर से चलाए जा रहे किसी प्रॉडक्ट का इस्तेमाल करना बेहतर होगा.
मैंने सैंपल सवालों वाला एक शुरुआती सर्वे बनाया है. इसे https://docs.google.com/forms/d/e/1FAIpQLSeBAO0UFKDZyKpg2XzRslsLJVHU61ugjc18-2PVEabTQg2_6g/viewform पर देखा जा सकता है. फ़ाइनल वर्शन में सवालों की संख्या 10 से 15 के बीच होनी चाहिए. सटीक नतीजे पाने के लिए, हमारा सुझाव है कि आप कई विकल्प वाले सवाल, लीनियर स्केल, और कुछ चेकबॉक्स का इस्तेमाल करें. लीनियर स्केल, पूरे स्पेक्ट्रम के जैसा नहीं होना चाहिए. हालांकि, इससे सिर्फ़ भ्रम होता है और नतीजों में ज़्यादा फैलाव होने की संभावना होती है. इसमें ज़्यादा से ज़्यादा दो ऐसे सवाल होने चाहिए जिनका जवाब विस्तार से देना होता है. ऐसा नहीं करने पर, नतीजे बहुत ज़्यादा फैलाए जाएंगे और कोई मदद नहीं मिलेगी. मुझे लगता है कि बहुत ज़्यादा जवाब होने पर भी कोई समस्या नहीं होगी. इसकी वजह यह है कि आंकड़ों वाले सॉफ़्टवेयर की मदद से, डेटा को आसानी से एक्सपोर्ट किया जा सकता है और उसका विश्लेषण अपने-आप किया जा सकता है. यह मानते हुए कि जवाबों की संख्या बहुत ज़्यादा है, ओपन-एंडेड सवालों के विश्लेषण में थोड़ा समय लग सकता है, लेकिन मुझे लगता है कि यह काम जितना मुश्किल नहीं होगा. ऐसा हो सकता है कि किसी आम व्यक्ति को दस्तावेज़ की स्थिति के बारे में निबंध लिखने की ज़रूरत न पड़े. सबसे खराब स्थिति में, कुछ जवाबों को आने वाले समय के विश्लेषण के लिए सेव किया जा सकता है.
ग्राफ़िकल गाइड:
ग्राफ़िकल गाइड का मेरा विज़न (इसका मकसद नेविगेशनल टूल के तौर पर काम करना) है, जो आम तौर पर इस्तेमाल किए जाने वाले सिद्धांतों पर आधारित है. इसमें लोगों को टेक्स्ट से मिलने वाली जानकारी के बजाय, सीधे विज़ुअल स्ट्रक्चर को बेहतर तरीके से प्रोसेस करने में मदद मिलती है. इतना ही नहीं, विषय के हिसाब से बनाए गए डायग्राम में लाइन से मिलते-जुलते विषयों को जोड़ने वाले चार्ट में दिखाया गया है कि यह सुविधा सिर्फ़ कम अनुभव वाले उपयोगकर्ताओं के लिए ही नहीं, बल्कि उन उपयोगकर्ताओं के लिए भी फ़ायदेमंद है जो इसी काम का अनुभव करते हैं.
जहां तक लागू करने की जानकारी है, हम TikZ पैकेज इस्तेमाल करने का सुझाव देते हैं. सबसे अहम बात, यह एक बेहतरीन टूल है और इसके जल्द ही बंद होने का खतरा नहीं है. इससे अच्छी क्वालिटी का आउटपुट भी मिलता है. इसमें अच्छे दस्तावेज़ मौजूद हैं. यह अक्सर TeX StackExchange और अन्य मुख्यधारा वाले फ़ोरम पर अक्सर चर्चा में रहता है. सबसे अहम बात यह है कि एचटीएमएल दस्तावेज़ के साथ TikZ फ़ाइल (इसमें मौजूद कई हाइपरलिंक) के इंटिग्रेशन से कोई बड़ी समस्या नहीं दिखती. ऐसा इसलिए होता है, क्योंकि एचटीएमएल में TikZ की तस्वीर जोड़ने और उसे जोड़ने के लिए अलग-अलग पैकेज और समाधान मौजूद हैं, जैसे कि TeX4ht.
आने वाले समय में, SciPy में गाइड के रखरखाव के सवाल को आसानी से हल किया जा सकता है. इसके लिए, Overleaf (साथ मिलकर काम करने की सुविधा देने और तुरंत झलक देखने की सुविधा) और पहले से तय किए गए टेंप्लेट इस्तेमाल करें. इसका मतलब यह नहीं है कि ग्राफ़िकल गाइड एक-दूसरे से बहुत अलग होंगे. स्ट्रक्चर, कलर पैलेट, और आकार कमोबेश अलग होंगे. इसलिए, उन्हें बाद में फिर से आकार देने और उनमें पसंद के मुताबिक बनाने में कोई समस्या नहीं होगी.
(कृपया प्रस्ताव का पूरा वर्शन देखें - यह शेयर किए गए GSoD फ़ोल्डर में उपलब्ध है.)