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

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

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

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

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

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

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

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

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

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

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

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

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

    • Google, पुल के अनुरोध के उस वर्शन को मर्ज करेगा जिसके लिए वोट किया गया है (बशर्ते योगदान देने वालों ने सीएलए पर हस्ताक्षर किए हों). साथ ही, पुल के अनुरोध को पांच कारोबारी दिनों के अंदर पूरा करेगा.
    • मूल पुल के अनुरोध में अनुवाद को शामिल नहीं किया जाना चाहिए. Google, कॉन्टेंट के अनुवाद को उन भाषाओं के लिए अपडेट करता है जो सिस्टम में उपलब्ध हैं. हालांकि, समुदाय के शुद्ध अनुवाद वाले पुल के अनुरोधों का भी स्वागत है और उन्हें तब स्वीकार किया जाएगा, जब सारी एडिटोरियल टिप्पणियां ठीक कर दी जाएंगी.
  10. पुल के अनुरोध के आखिरी नतीजों (स्वीकार किए गए या छोड़े गए) का एलान Google Groups के उसी थ्रेड में किया जाना चाहिए जिसमें शुरुआत में पुल के अनुरोध का एलान किया गया था.