Changes

ガバナンスフレームワーク移行について

2025年7月7日以降、すべての新しい Pull Request は 新しい GTFS Schedule ガバナンスフレームワーク の対象となります。
- 2025年7月7日以前 に作成された Pull Request は、このセクションで説明されている 旧ガバナンス に従い続けます。
- これには以下の PR が含まれます: 567、561、556、546、545、533、515、502、498、483、423。
- 2025年7月7日以前に作成されたすべての PR が解決され次第、このページおよびここで説明されているプロセスは完全に廃止されます。

GTFS 仕様は固定されたものではありません。むしろ、GTFS を利用する交通事業者、開発者、その他の関係者によって開発・維持されるオープンな仕様です。GTFS データの提供者および利用者のコミュニティが、新しい機能を実現するために仕様拡張の提案を行うことが想定されています。そのプロセスを管理するために、以下の手順およびガイドラインが定められています。

仕様変更プロセス¶

公式の仕様書、リファレンスおよびドキュメントは英語で作成されています。翻訳版と英語の原文に相違がある場合は、英語の原文が優先されます。すべてのコミュニケーションは英語で行われます。

プロトコル定義、仕様書およびドキュメントファイル（翻訳を除く）の関連部分をすべて更新した git ブランチを作成します。
https://github.com/google/transit に pull request を作成します。pull request にはパッチの詳細な説明を含めなければなりません。pull request の作成者は advocate（提案者） となります。
pull request が登録されたら、提案者は GTFS Changes メーリングリストに pull request へのリンクを含めて告知しなければなりません。告知された時点で、その pull request は提案と見なされます。また、pull request には Google Groups の告知へのリンクを追加し、相互参照できるようにするべきです。
- 提案者はコントリビューターであるため、pull request が受け入れられる前に Contributor License Agreement に署名しなければなりません。
提案に関する議論を行います。pull request のコメント欄を唯一の議論の場として使用するべきです。
- 議論は提案者が必要と感じる限り続けることができますが、少なくとも7暦日間は行わなければなりません。
- 提案者は、同意したコメントに基づいて提案（すなわち pull request）を適時に更新する責任を負います。
- 提案者はいつでも提案を放棄したと宣言することができます。
提案者は、議論開始から7日間の期間が経過した後であれば、いつでも提案のあるバージョンについて投票を呼びかけることができます。
- 投票を呼びかける前に、少なくとも1つの GTFS producer と1つの GTFS consumer が提案された変更を実装しているべきです。GTFS producer は、変更を公開されている GTFS フィードに含め、そのデータへのリンクを pull request のコメント内に提供することが期待されます。また、GTFS consumer は、その変更を実際に利用して新機能または改善された機能を提供しているアプリケーションへのリンクを pull request のコメント内に提供することが期待されます。
投票は、14暦日間を完全にカバーする最短期間続きます。投票は UTC 23:59:59 に終了します。
- 提案者は、投票開始時に具体的な終了時刻を告知するべきです。
- 投票期間中は、提案に対して編集上の変更（誤字修正、意味を変えない表現の修正）のみが許可されます。
- 誰でも pull request へのコメントとして「yes/no」の形で投票することができ、投票期間が終了するまで投票を変更することができます。投票を変更する場合は、元の投票コメントを更新し、元の投票を取り消し線で示して新しい投票を記載することが推奨されます。
- 投票期間開始前の投票は無効です。
- 投票の開始および終了は GTFS Changes メーリングリストで告知しなければなりません。
提案は、少なくとも3票の全会一致の「yes」が得られた場合に承認されます。
- 提案者自身の投票は3票の合計には含まれません。たとえば、提案者Xが pull request を作成して「yes」と投票し、ユーザーYとZが「yes」と投票した場合、合計2票の「yes」としてカウントされます。
- 「no」票を投じる場合は、その理由を明示し、可能であれば実行可能なフィードバックを提供するべきです。
- 投票が否決された場合、提案者は提案の作業を継続するか、提案を放棄するかを選択することができます。いずれの決定も GTFS Changes メーリングリストで告知しなければなりません。
- 提案者が作業を継続する場合は、いつでも新たな投票を呼びかけることができます。
30暦日間活動のない pull request はクローズされます。pull request がクローズされた場合、対応する提案は放棄されたものと見なされます。提案者は、議論を再開または継続したい場合、いつでも pull request を再オープンすることができます。
提案が承認された場合：
- Google は、投票で承認されたバージョンの pull request（コントリビューターが CLA に署名していることが条件）をマージし、5営業日以内に pull request を実行することを約束します。
- 翻訳は元の pull request に含めてはいけません。 Google は、最終的に対応言語への翻訳を更新する責任を負いますが、コミュニティからの純粋な翻訳のみの pull request も歓迎され、すべての編集上のコメントが解決され次第、受け入れられます。
pull request の最終結果（承認または放棄）は、最初に pull request が告知された同じ Google Groups スレッドで告知するべきです。

指針原則¶

GTFS の本来の理念を維持するために、仕様を拡張する際に考慮すべきいくつかの指針原則が定められています。

フィードは作成および編集が容易であるべきです¶

私たちは、この仕様の基盤として CSV を選択しました。これは、スプレッドシートプログラムやテキストエディタを使用して簡単に表示および編集できるため、小規模な事業者にとって便利だからです。また、ほとんどのプログラミング言語やデータベースから容易に生成できるため、大規模なフィードの発行者にとっても適しています。

フィードは解析しやすいものであるべきです¶

フィードリーダーは、できるだけ少ない作業で必要な情報を抽出できるようにするべきです。フィードへの変更や追加は、フィードの読者が実装しなければならないコードパスの数を最小限に抑えるために、できるだけ広く有用なものであるべきです。（ただし、最終的にはフィードリーダーよりもフィード発行者の方が多くなるため、作成を容易にすることを優先するべきです。）

この仕様は乗客向け情報に関するものです¶

GTFS は主に乗客向け情報を対象としています。つまり、この仕様には、まず第一に乗客向けツールを支援するための情報が含まれているべきです。交通事業者がシステム間で内部的に送信したいと考える、運用指向の情報は大量に存在する可能性があります。GTFS はそのような目的のために設計されたものではなく、その用途には他の運用指向のデータ標準を使用する方が適している場合があります。

仕様への変更は後方互換性を維持するべきです¶

仕様に新しい機能を追加する際には、既存のフィードを無効にしてしまうような変更を避けたいと考えています。既存のフィード発行者が、自身のフィードに新しい機能を追加したいと思うまで、余分な作業を強いることは望んでいません。また、可能な限り、既存のパーサーが新しいフィードの古い部分を引き続き読み取ることができるようにしたいと考えています。

推測的な機能は推奨されません¶

新しい機能を追加するたびに、フィードの作成および読み取りの複雑さが増します。したがって、実際に有用であると分かっている機能のみを追加するよう注意する必要があります。理想的には、提案される機能は、実際の交通システムでその新機能を使用してデータを生成し、それを読み取り・表示するソフトウェアを作成することでテストされていることが望ましいです。GTFS は、公式のパーサーやバリデーターによって無視される追加の列やファイルを通じてフォーマットを拡張できるようになっているため、既存のフィード上で提案を容易にプロトタイプ化し、テストすることができます。