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

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

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

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

  1. प्रोटोकॉल परिभाषा, स्पेसिफ़िकेशन, और दस्तावेज़ के फ़ाइलों (अनुवाद को छोड़कर) के सभी ज़रूरी हिस्सों के अपडेट के साथ एक git ब्रांच बनाएं.
  2. Https://github.com/google/transit पर पुल के लिए अनुरोध बनाएं. पुल के अनुरोध में पैच का पूरा ब्यौरा होना चाहिए. पुल का अनुरोध बनाने वाला वकील बन जाता है.
  3. पुल के अनुरोध को रजिस्टर करने के बाद, उसके वकील को जीटीएफ़एस रीयल टाइम मेलिंग लिस्ट में उसके बारे में एलान करना चाहिए एलान किए जाने के बाद, पुल के अनुरोध को प्रस्ताव माना जाता है.
  4. इसके बाद प्रस्ताव पर चर्चा की जाती है. पुल के अनुरोध की टिप्पणियों को चर्चा के लिए इकलौते फ़ोरम के तौर पर इस्तेमाल करना चाहिए.
    • चर्चा तब तक जारी रहती है जब तक वकील को यह ज़रूरी लगता है, लेकिन कम से कम 7 दिनों तक चर्चा की जानी चाहिए.
    • प्रस्ताव (यानि कि पुल का अनुरोध) को समय पर अपडेट करने की जिम्मेदारी वकील की होती है. यह उन टिप्पणियों के आधार पर होता है, जिनसे वे सहमत हैं.
    • किसी भी समय वकील प्रस्ताव को छोड़ने का दावा कर सकता है.
  5. शुरुआत में चर्चा के लिए ज़रूरी सात दिनों के अंतराल के बाद, वकील कभी भी प्रस्ताव के किसी वर्शन पर वोटिंग की मांग कर सकता है.
  6. वोटिंग कम से कम सात कैलेंडर दिनों और स्विट्ज़रलैंड के पांच कारोबारी दिनों तक होती है. 23:59:59 यूटीसी पर वोटिंग खत्म होती है.
    • वकील को वोटिंग की शुरुआत में ही खत्म होने के समय का एलान कर देना चाहिए.
    • वोटिंग के दौरान प्रस्ताव में सिर्फ़ लिखने में हुई गड़बड़ी को बदला जा सकता है ( जैसे कि गलत वर्तनी या शब्द बदले जा सकते हैं, अगर उनसे मतलब नहीं बदलता हो).
    • किसी भी पुल के अनुरोध के लिए टिप्पणी के रूप में हां/ना लिखकर वोट किया जा सकता है. हालांकि वोटिंग के खत्म होने से पहले तक, वोट को बदला भी जा सकता है. अगर कोई वोटर अपना वोट बदलना चाहता है, तो ऐसा करने के लिए पहले किए गए वोट की टिप्पणी में जाकर उसे काटना होगा और नए वोट के लिए टिप्पणी लिखकर अपडेट करना होगा.
    • वोटिंग शुरू होने से पहले की गई वोट की टिप्पणी को माना नहीं जाएगा.
  7. प्रस्ताव को तब स्वीकार किया जाएगा जब कम से कम तीन वोट के साथ सर्वसम्मति से सहमति हो.
    • उन 3 वोट में प्रस्ताव रखने वाले का वोट नहीं गिना जाता. जैसे कि अगर प्रस्ताव रखने वाले X व्यक्ति ने पुल का अनुरोध बनाया है और हां में वोट किया है. वहीं, उपयोगकर्ता Y और Z ने भी हां में वोट किया है, तो इसे हां वाले कुल 2 वोट के तौर पर ही गिना जाएगा.
    • विरोध में वोट करने वालों को दबाया नहीं जाना चाहिए, बल्कि उन्हें किसी गलती को ठीक करने का सुझाव भी देना चाहिए.
    • अगर वोटिंग में पुल का अनुरोध फ़ेल कर जाता है, तो वकील के पास इस बात का विकल्प होता है कि वह प्रस्ताव पर काम जारी रखे या उसे छोड़ दे. वकील को इनमें से किसी एक फ़ैसले के बारे में, ईमेल पाने वाले लोगों की लिस्ट में एलान करना होगा.
    • अगर वकील ने प्रस्ताव पर काम जारी रखा है, तो किसी भी समय नई वोटिंग के लिए कहा जा सकता है, लेकिन ऐसा पिछले वोट के खत्म होने के 30 दिनों के अंदर किया जाना चाहिए.
    • अगर मूल प्रस्ताव से 30 दिनों के अंदर या पिछले वोट के खत्म होने के 30 दिनों के अंदर वोटिंग के लिए मांग नहीं की जाती है, तो प्रस्ताव को छोड़ दिया जाएगा.
  8. अगर प्रस्ताव को छोड़ दिया गया है, तो उससे जुड़ा पुल अनुरोध बंद हो जाता है.
  9. अगर प्रस्ताव को स्वीकार कर लिया गया है, तो:
    • पुल के अनुरोध के जिस वर्शन के लिए वोटिंग की गई है, Google उस वर्शन को मर्ज करेगा (बशर्ते योगदान देने वालों ने सीएलए पर हस्ताक्षर किए हों) और पुल के अनुरोध को पांच कारोबारी दिनों के अंदर पूरा करेगा.
    • Google, स्टोर किए गए https://github.com/google/gtfs-realtime-bindings डेटा को समय-समय पर अपडेट करता है. gtfs-realtime-bindigs में बदलाव जो कि प्रस्ताव का नतीजा है, उसे सेव करता है. यह प्रस्ताव के पुल के अनुरोध के बारे में बताता है.
    • मूल पुल के अनुरोध में अनुवाद को शामिल नहीं किया जाना चाहिए. Google, कॉन्टेंट के अनुवाद को उन भाषाओं के लिए अपडेट करता है जो सिस्टम में उपलब्ध हैं, लेकिन समुदाय के शुद्ध अनुवाद पुल के अनुरोधों का भी स्वागत है और उन्हें तब स्वीकार किया जाएगा, जब सारी संपादकीय टिप्पणियों के हिसाब से अनुवाद ठीक कर लिया जाएगा.