變更程序總覽

GTFS Realtime 規格並非一成不變,相反地,這種規格屬於開放式型態,可由運輸公司、開發人員和其他使用 GTFS Realtime 的相關人員所組成的社群共同開發及維護。GTFS Realtime 資料製作者和使用者所組成的社群,一般來說會提出提案來擴充規格以實現新功能。為了協助管理相關流程,我們制定了下列程序和規範。

規格修訂程序

官方規格、參考資料和說明文件是以英文撰寫而成。如果其他語言的翻譯與英文原文不同,則以後者為優先。所有通訊皆以英文進行。

  1. 建立 Git 分支,並更新通訊協定定義、規格和說明文件檔案的所有相關部分 (翻譯除外)。

  2. 前往 https://github.com/google/transit 建立提取要求。提取要求必須包含修補程式的擴充說明。提取要求的建立者會成為「負責人」

  3. 提取要求登錄完成後,必須由負責人在 GTFS Realtime 郵寄清單中宣布。宣布後,提取要求就會視為提案。

  4. 隨後就會討論提案。提取要求留言區應做為唯一論壇使用。

    • 只要負責人認為有必要,討論就會持續下去,但時間必須至少 7 天。
    • 負責人必須根據他們認同的留言即時更新提案 (亦即提取要求)。
    • 負責人隨時都可聲明放棄提案。
  5. 負責人可以在討論所需的最初 7 天過後,隨時要求針對某個提案版本進行投票。

  6. 投票的時間長度下限為 7 個全天和 5 個完整瑞士工作天。投票結束時間為世界標準時間晚上 11 時 59 分 59 秒。

    • 負責人必須在投票開始時宣布具體的結束時間。
    • 投票期間只能對提案進行字詞修訂 (僅能調整錯字和用詞,但不能影響原意)。
    • 任何人都可透過留言的形式,對提取要求投票表示贊成或反對,而且在投票期結束前皆可變更決定。如果投票者改變心意,建議方法是更新投票留言,也就是劃掉原本的投票意見,然後寫下新的投票主張。
    • 投票期開始前所投下的票不列入計算。
  7. 如果投票者一致表示贊成,且票數至少有 3 票,就等於通過提案。

    • 提案者的票不算在這 3 票當中。舉例來說,如果提案者 X 建立了提取要求並投下贊成票,而使用者 Y 和 Z 也投下贊成票,則贊成票一共為 2 票。
    • 反對票背後應具有充分理由,以能提供建設性意見回饋為最佳。
    • 如果投票失敗,負責人可以選擇繼續處理或放棄提案。不論是哪一種決定,都必須在郵寄清單中宣布。
    • 如果負責人持續處理提案,之後隨時都可要求重新投票,但時間必須在前一次投票後的 30 天內。
    • 如果在最初提案後的 30 天內,或是在前一次投票後的 30 天內沒有要求投票,提案就會遭到放棄。
  8. 在這種情況下,對應的提取要求就會關閉。

  9. 如果提案通過:

    • Google 會努力合併付諸投票的提取要求版本 (前提是貢獻者已簽署 CLA),並在 5 個工作天內執行提取要求。
    • Google 致力於即時更新 https://github.com/google/gtfs-realtime-bindings 存放區。因提案獲准而修訂 gtfs-realtime-bindigs 時,應參照提案的提取要求。
    • 原始提取要求不得加入翻譯。Google 最後會負責將相關翻譯更新為所支援語言,但也樂見社群提出純翻譯提取要求。所有編輯性建議留言都處理完畢後,這類要求就會立即獲准。