बदलाव की प्रक्रिया के बारे में खास जानकारी

ऐसा नहीं है कि जीटीएफ़एस रीयल टाइम फ़ीड के निर्देशों में बदलाव नहीं किए जा सकते. इसके बजाय, यह बदलाव करने लायक वे निर्देश हैं जिन्हें सार्वजनिक परिवहन एजेंसियों, डेवलपर, और जीटीएफ़एस रीयल टाइम इस्तेमाल करने वाले दूसरे लोगों की कम्यूनिटी ने बनाया है और वे ही इसका रखरखाव करते हैं. उम्मीद की जाती है कि जीटीएफ़एस डेटा बनाने वाले और इस्तेमाल करने वाले लोगों की इस कम्यूनिटी के पास ऐसे सुझाव होंगे जिनसे इन निर्देशों में नई क्षमताओं को शामिल किया जा सके. इस प्रक्रिया को मैनेज करने में सहायता करने के लिए, नीचे बताई गई प्रक्रियाएं और दिशा-निर्देश बनाए गए हैं.

निर्देशों में संशोधन की प्रक्रिया

आधिकारिक निर्देश, रेफ़रंस, और दस्तावेज़ अंग्रेज़ी में हैं. अंग्रेज़ी से किसी दूसरी भाषा में अनुवाद करने पर अगर मतलब में अंतर आता है, तो अंग्रेज़ी वाले दस्तावेज़ को अहमियत दी जाती है. सारी बातचीत अंग्रेज़ी में की जाती है.

  1. प्रोटोकॉल परिभाषा, निर्देश, और दस्तावेज़ फ़ाइलों (अनुवाद के अलावा) के सभी उपयोगी हिस्सों के अपडेट के साथ एक git ब्रांच बनाएं.

  2. https://github.com/google/transit पर पुल के लिए अनुरोध बनाएं. पुल के अनुरोध में पैच का पूरा ब्यौरा होना चाहिए. पुल का अनुरोध बनाने वाला, एडवोकेट बन जाता है.

  3. पुल के अनुरोध को रजिस्टर करने के बाद, उसके एडवोकेट को जीटीएफ़एस रीयल टाइम के ईमेल पाने वालों की सूची में उसके बारे में एलान करना चाहिए. एलान किए जाने के बाद, पुल के अनुरोध को प्रस्ताव मान लिया जाता है.

  4. इसके बाद प्रस्ताव पर चर्चा की जाती है. पुल के अनुरोध की टिप्पणियों को चर्चा के लिए इकलौते फ़ोरम के तौर पर इस्तेमाल करना चाहिए.

    • चर्चा तब तक जारी रहती है, जब तक एडवोकेट को यह ज़रूरी लगता है, लेकिन कम से कम सात दिनों तक चर्चा की जानी चाहिए.
    • प्रस्ताव (यानी कि पुल का अनुरोध) को समय पर अपडेट करने की ज़िम्मेदारी एडवोकेट की होती है. यह उन टिप्पणियों के आधार पर होता है जिनसे वे सहमत हैं.
    • एडवोकेट किसी भी समय प्रस्ताव को छोड़ने का दावा कर सकता है.
  5. चर्चा के लिए ज़रूरी पहले सात दिन के अंतराल के बाद, एडवोकेट किसी भी समय प्रस्ताव के एक वर्शन पर वोट की मांग कर सकता है.

  6. वोटिंग कम से कम सात कैलेंडर दिनों और स्विट्ज़रलैंड के पांच कारोबारी दिनों तक होती है. 23:59:59 यूटीसी पर वोटिंग खत्म होती है.

    • एडवोकेट को वोटिंग की शुरुआत में ही खत्म होने के समय के बारे में जानकारी दे देनी चाहिए.
    • वोटिंग के दौरान प्रस्ताव में सिर्फ़ लिखने में हुई गड़बड़ी को बदला जा सकता है ( जैसे कि गलत वर्तनी या शब्द बदले जा सकते हैं, अगर उनसे मतलब नहीं बदलता हो).
    • किसी भी पुल के अनुरोध के लिए टिप्पणी के रूप में हां/ना लिखकर वोट किया जा सकता है. हालांकि, वोटिंग के खत्म होने से पहले, वोट को बदला भी जा सकता है. अगर कोई वोटर अपना वोट बदलना चाहता है, तो ऐसा करने के लिए, पहले किए गए वोट की टिप्पणी में जाकर उसे मिटाना होगा. इसके बाद, नए वोट के लिए टिप्पणी लिखकर अपडेट करना होगा.
    • वोटिंग शुरू होने से पहले की गई वोट की टिप्पणी को माना नहीं जाएगा.
  7. प्रस्ताव को तभी स्वीकार किया जाता है, जब सभी ने हां लिखा हो और इसके लिए कम से कम तीन वोट हों.

    • उन तीन वोट में, प्रस्ताव रखने वाले का वोट नहीं गिना जाता. जैसे कि अगर प्रस्ताव रखने वाले X व्यक्ति ने पुल का अनुरोध बनाया है और हां में वोट किया है. वहीं, उपयोगकर्ता Y और Z ने भी हां में वोट किया है, तो इसे हां वाले कुल दो वोट के तौर पर ही गिना जाएगा.
    • विरोध में वोट करने वालों को दबाया नहीं जाना चाहिए, बल्कि उन्हें किसी गलती को ठीक करने का सुझाव भी देना चाहिए.
    • अगर वोटिंग में पुल का अनुरोध फ़ेल हो जाता है, तो एडवोकेट के पास इस बात का विकल्प होता है कि वह प्रस्ताव पर काम जारी रखे या उसे छोड़ दे. एडवोकेट को इनमें से किसी एक फ़ैसले के बारे में, ईमेल पाने वाले लोगों की लिस्ट में एलान करना होगा.
    • अगर एडवोकेट ने प्रस्ताव पर काम जारी रखा है, तो किसी भी समय नई वोटिंग के लिए कहा जा सकता है. हालांकि, ऐसा पिछली वोटिंग के खत्म होने के 30 दिनों के अंदर किया जाना चाहिए.
    • अगर मूल प्रस्ताव से 30 दिनों के अंदर या पिछली वोटिंग के खत्म होने के 30 दिनों के अंदर वोटिंग की मांग नहीं की जाती है, तो प्रस्ताव को छोड़ दिया जाएगा.
  8. अगर प्रस्ताव को छोड़ दिया गया है, तो उससे जुड़ा पुल का अनुरोध बंद हो जाता है.

  9. अगर प्रस्ताव को स्वीकार कर लिया गया है, तो:

    • Google, पुल के अनुरोध के उस वर्शन को मर्ज करेगा जिसके लिए वोट किया गया है (बशर्ते योगदान देने वालों ने सीएलए पर हस्ताक्षर किए हों). साथ ही, Google पुल के अनुरोध को पांच कारोबारी दिनों के अंदर पूरा करेगा.
    • Google, स्टोर किए गए https://github.com/google/gtfs-realtime-bindings डेटा को समय-समय पर अपडेट करता है. साथ ही, gtfs-realtime-bindigs में किया गया ऐसा बदलाव जो कि प्रस्ताव का नतीजा है, उसे सेव करता है. यह प्रस्ताव के पुल के अनुरोध के बारे में बताता है.
    • मूल पुल के अनुरोध में अनुवाद को शामिल नहीं किया जाना चाहिए. Google, कॉन्टेंट के अनुवाद को उन भाषाओं के लिए अपडेट करता है जो सिस्टम में उपलब्ध हैं. हालांकि, कम्यूनिटी के शुद्ध अनुवाद वाले पुल के अनुरोधों का भी स्वागत है और उन्हें तब स्वीकार किया जाएगा, जब सारी एडिटोरियल टिप्पणियां ठीक कर दी जाएंगी.