以前のガバナンス

ガバナンスフレームワーク移行

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 へのコメントの形で賛成/反対の投票を行うことができ、投票期間が終了するまで投票を変更することができます。投票を変更する場合は、元の投票コメントを更新し、元の投票を取り消し線で消して新しい投票を記載することが推奨されます。
- 投票期間開始前の投票は考慮されません。
- 投票の開始と終了は GTFS Changes メーリングリストで告知しなければなりません。
提案は、少なくとも3票の全会一致の賛成があれば受け入れられます。
- 提案者の投票は3票の合計には含まれません。例えば、提案者Xが pull request を作成して賛成票を投じ、ユーザーYとZが賛成票を投じた場合、合計は2票の賛成と数えられます。
- 反対票は理由を示さなければならず、理想的には実行可能なフィードバックを提供するべきです。
- 投票が否決された場合、提案者は提案の作業を続けるか、提案を放棄するかを選択できます。いずれの決定も 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 は、公式のパーサーやバリデーターによって無視される追加のカラムやファイルを通じてフォーマットを拡張することを容易に許容しているため、提案は既存のフィード上で簡単にプロトタイプ化およびテストすることができます。