變更程序總覽

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

規格修訂程序

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

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

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

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

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

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

  6. 投票的時間長度下限為 7 個全天和 5 個完整瑞士工作天。投票結束時間為世界標準時間 23: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 會負責最後將相關翻譯更新為支援的語言,但也樂見社群提出純翻譯提取要求;所有編輯性建議留言都處理完畢後,這類要求就會立即獲准。