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