変更プロセス¶

概要¶

仕様変更プロセスは、コミュニティがGTFS Repositoryにおいて仕様への変更を提案、レビュー、および採用する方法を示します。

仕様変更プロセスは、2つの主要な段階に分かれており、3つの変更タイプ、すなわち機能的変更、非機能的変更、およびドキュメント保守に応じて、3つのトラックに分類されます。

ステージ1: Issue¶

Issueステージは、新しいアイデアの議論、ニーズの特定、および仕様の改善提案を目的としています。Issueは、変更の必要性と支持を評価するのに役立つとともに、Pull Requestステージへ進むために必要なリソースを整理します。

新しいアイデアについて合意形成を図るため、Issueステージから開始することが推奨されます。ただし、提案の範囲がすでに明確に定義されている場合は、Pull Requestステージから直接開始することが適切です。

ステージ2: プルリクエスト¶

プルリクエストステージでは、Issueステージでのアイデアを仕様として開発・実装します。このステージは、変更の種類に応じて3つのトラックに分かれています。

プロセス全体は GitHub google/transit repository 内で行われ、採用される前にすべての変更が徹底的に評価されることを保証します。

プロセストラック¶

提案された変更の種類に応じて、変更プロセスには異なるトラックが適用されます。Issue Stageは3つのトラックすべてで同じままですが、Pull Request Stageはトラックごとに異なります。

トラックA: 機能的変更¶

このプロセスは、コミュニティがGTFS Repository内の仕様に対する機能的変更を提案、レビュー、および採用する方法を示します。

GTFS RepositoryでPull Requestを作成することで、提案が提出されます。
コミュニティは、提案を改善するための議論を行います。この期間は少なくとも7日間継続しなければなりません。
ContributorsおよびMaintainerは、提案された変更をレビューします。この期間は少なくとも7日間継続しなければなりません。
テストの前に、コミュニティは提案について全会一致の合意を確認するための投票を行います。これは、投票に参加するすべての投票者が賛成しなければならないことを意味します。投票を有効とするには、少なくとも5人のcontributorを含み、そのうち最低2人のProducerおよび2人のConsumerを含まなければなりません。投票期間は少なくとも14日間継続しなければなりません。
First Adoptersは、提案された変更をテストします。
コミュニティは、変更を正式に採用するべきかどうかを決定するための投票を行います。この投票は80%多数決ルールに従います。つまり、可決されるには少なくとも80%の票が賛成でなければなりません。有効とするには、投票には少なくとも5人のcontributorを含み、そのうち最低2人のProducerおよび2人のConsumerを含まなければなりません。投票期間は少なくとも14日間継続しなければなりません。
最後に、変更が仕様に実装されます。

トラックB: 非機能的変更¶

このプロセスは、コミュニティがGTFS Repositoryにおいて、仕様に対する非機能的変更を提案、レビュー、および採用する方法を示します。

GTFS RepositoryでPull Requestを作成することにより、提案が提出されます。
コミュニティは、提案を改善するための議論を行います。この期間は少なくとも7日間継続しなければなりません。
ContributorsおよびMaintainerは、提案された変更をレビューします。この期間は少なくとも7日間継続しなければなりません。
コミュニティは、変更を正式に採用するべきかどうかを決定するために投票を行います。この投票は80%多数決ルールに従います。つまり、可決されるには少なくとも80%の票が賛成でなければなりません。有効となるためには、投票には少なくとも5人のcontributorが含まれ、そのうち最低2人のProducerおよび2人のConsumerが含まれなければなりません。投票期間は少なくとも14日間継続しなければなりません。
最後に、変更が仕様に実装されます。

トラックC: ドキュメントの保守¶

このプロセスは、コミュニティが GTFS Repository におけるドキュメントを保守するための変更を提案、レビュー、および採用する方法を示します。

GTFS Repository で Pull Request を作成することで、提案が提出されます。
コミュニティは、提案を改善するための議論に参加します。この期間は少なくとも7日間継続しなければなりません。
Contributors および Maintainer が、提案された変更をレビューします。この期間は少なくとも7日間継続しなければなりません。
最後に、変更が仕様に実装されます。

プロセスのステップ¶

IssueおよびPull Requestステージにおけるすべてのステップを以下に示します。すべてのステップを利用するのはTrack Aのみであることに留意してください。Track BおよびTrack Cでは、短縮版のプロセスを利用します。

	Track A: 機能的変更	Track B: 非機能的変更	Track C: ドキュメント保守
ステップ1.1: Issueの公開	✓	✓	✓
ステップ1.2: Issueの議論	✓	✓	✓
ステップ2.1: Pull Requestの公開	✓	✓	✓
ステップ2.2: Pull Requestの議論	✓	✓	✓
ステップ2.3: Pull Requestのレビュー	✓	✓	✓
ステップ2.4: テストへの投票	✓
ステップ2.5: テスト	✓
ステップ2.6: 採用への投票	✓	✓
ステップ2.7: 採用	✓	✓	✓

ステップ1.1: Issueの公開¶

Contributorは、GTFS RepositoryでIssueを作成することにより、仕様を改善するためのアイデアを共有します。

誰でも、議論を開始するためにIssueを作成することができます。

アクション

Issueの提出
- Contributorは、アイデアと、それによって解決される問題を説明するIssueを投稿します。

提案

提案	詳細
仕様変更テンプレートを使用する	提供されているテンプレートを使用して、フィールドに概要レベルの説明を記入します。
議論を促進する	内容は完璧である必要はありません。会話が進むにつれて、議論を促し、変化していくべきです。
関心のあるContributorにタグ付けする	議論に関心を持つ可能性のある他のContributorにタグ付けし、関連するプラットフォームでIssueを共有します。

ステップ1.2: Issueの議論¶

コミュニティは、仕様を変更するための提案の策定を支援するために議論を行います。この提案は、次の段階でPull Requestとして提出されます。

アクション

Issueの議論
- Contributorsは、元のIssue投稿に返信し、フィードバックを共有します。
ワーキンググループの提案
- 必要に応じて、任意のContributorは、ビデオ会議ソフトウェアを使用してすべての関係者間の議論を促進するため、ワーキンググループの設置を提案することができます。
- ワーキンググループは、任意のContributorまたはMaintainerが組織することができます。
- ワーキンググループ会議で行われた議論は、Issueコメントに要約するべきです。

提案

提案	詳細
議論の範囲を明確化する	提案の範囲を明確化することに議論を集中させます。
要件を確認する	提案を策定するために必要なすべての要件が確認されていることを確実にします。
意見を収集する	複数のcontributorからフィードバックを収集し、提案に対する全体的な支持を評価します。
議論を要約する	合意に達した事項、合意された範囲、advocateおよび／またはテストに関心を持つ関係者の告知など、最新の議論の要点を元の投稿に定期的に更新します。
候補となるAdvocateを特定する	完全な提案を策定し、Pull Request StageにおいてAdvocateの役割を担う意思のあるcontributorを特定します。

ステップ2.1: Pull Request の公開¶

注記: すべてのトラックに適用されます

仕様を変更する提案は、GTFS Repository で Pull Request を作成することにより公開されます。提案を公開する提唱者は、単一の変更に焦点を当てなければなりません。変更の提案は誰でも行うことができます。

アクション

変更の適用
- 提唱者は、元の GTFS Repository の fork を、自身の個人アカウントまたは組織のアカウントに作成します。
- 提唱者は、自身の fork にブランチを作成し、提案された変更を適用します。
Pull Request の提出
- 提唱者は、自身の fork から GTFS Repository に Pull Request を作成します。

要件

要件	詳細
単一の変更	Pull Request は、一度に単一の変更に焦点を当てるべきです。「単一の変更」とは、無関係な更新をまとめることなく、1つの概念、機能、またはルールに対処する、焦点を絞った範囲を持つ自己完結した変更です。
拡張説明	Pull Request には、提案された変更の拡張説明を含めなければなりません。提供されている Pull Request template に従うことが推奨されます。
変更タイプ	提唱者は、Pull Request の最初の投稿で変更タイプ（Functional、Non-Functional、または Documentation Maintenance）を指定しなければなりません。 - 正しい採用トラックに従うことを確実にするため、すべての貢献者はいつでも誤分類された変更を指摘することができます。 - 合意に達しない場合、メンテナーは明確化を提供し、適切なトラックを推奨することができます。
提案する議論期間	提唱者は、提案された変更の範囲に基づき、最小限の推定議論期間を指定するべきです。 - 例: 「全員が提案について議論するための十分な時間を確保できるよう、少なくとも1か月を議論のために確保することを推奨します。」
メーリングリストでの告知	提唱者は、GTFS Changes mailing list で Pull Request の作成を告知しなければなりません。これには、変更の簡単な説明および Pull Request へのリンクを含めます。

ステップ 2.2: Pull Request の議論¶

注: すべてのトラックに適用されます

コミュニティは、提案の改善および策定を支援するために議論を行います。

アクション

提案の議論
- Contributors は、Pull Request のコメント欄で提案について議論します。
提案の更新
- Advocate は、受け取ったコメントに基づいて提案の内容を更新します。
Working Group の提案
- 必要に応じて、任意の Contributor は、ビデオ会議ソフトウェアを使用してすべての関係者間の議論を促進するため、Working Group の設置を提案することができます。
- Working Group は、Advocate または Maintainer のいずれかが組織することができます。
- Working Group 会議で行われた議論は、Pull Request のコメントに要約するべきです。

要件

要件	詳細
最小議論期間	議論は Advocate が必要と判断する期間継続しますが、少なくとも暦日で丸7日間でなければなりません。
Contributor License Agreement	提案を編集する Advocate を含むすべての contributors は、Contributor License Agreement に署名しなければなりません。

ステップ2.3: Pull Request レビュー¶

注記: すべてのトラックに適用されます

コミュニティは、提案をテスト用に準備するため、Advocate にフィードバックを提供します。

アクション

レビュー期間の告知
- Advocate は、Pull Request のコメント欄でレビュー期間の開始を告知します。
Maintainer のレビュー
- Maintainer は、用語が現行の仕様と整合していることを確認するため、Pull Request をレビューします。
- Maintainer は、コメントで変更を提案するか、または文言が正しいことを確認できます。これにより、Advocate は必要に応じて調整し、次のステップに進みます。
Contributor のフィードバック
- Contributors もこの期間中に Pull Request をレビューし、テスト前にAdvocate が最終調整を行うためのフィードバックを提供できます。

要件

要件	詳細
最小レビュー期間	レビューは Advocate が必要と判断する期間継続しますが、少なくとも暦日で丸7日間でなければなりません。 - Documentation Maintenance Track には最小レビュー期間の要件はありません。

ステップ2.4: テスト実施のための投票¶

注記: トラックB: 非機能的変更およびトラックC: ドキュメント保守には適用されません

コミュニティは、提案の範囲についての合意を確認し、テストに進むのに十分な技術的妥当性があることを確認するために投票します。

アクション

投票の告知
- Advocateは、Pull Requestのコメント欄で投票の開始を告知し、投票の終了時刻を指定します。
- Advocateは、GTFS Changes mailing listのディスカッションスレッドで、Pull Requestのコメントへのリンクおよび投票の終了時刻を示して投票を告知します。
投票プロセス
- Contributorsは、Pull Requestのコメント欄で投票しなければなりません。
編集および取消し
- Advocateは、投票期間中、編集上の目的に限り提案を編集することができます。その他の変更には、投票プロセスの再開が必要です。
- Advocateは、いつでも投票を取り消すことができます。
投票終了の告知
- Advocateは、Pull Requestのコメント欄で投票の終了を告知し、結果を含めます。
- Advocateは、GTFS Changes mailing listのディスカッションスレッドでも、結果を含めて投票の終了を告知します。
否決された投票
- 投票が否決された場合、Advocateは以下を選択することができます。
  1. 提案の作業を継続する、または
  2. 提案を放棄する。
- Advocateは、Pull Requestのコメント欄およびGTFS Changes mailing listのディスカッションスレッドで、その決定を告知しなければなりません。

要件

投票は、以下の条件を満たさなければなりません。

要件	詳細
承認ルール	すべてのcontributorが+1に投票した場合にのみ、投票は可決されます（全会一致の合意）。
投票形式	投票は以下の形式でなければなりません。 - “+1 または -1、組織名、Contributor Type（Consumer、Producer、またはGeneral Contributor）、作成したFeedまたは利用アプリケーションへのリンク”
反対票	反対票（-1）を投じるcontributorは、実行可能なフィードバックを提供しなければなりません。 - 実行可能なフィードバックとは、特定された問題の解決に役立つ具体的な所見または提案を提供する、実践的かつ建設的なフィードバックです。 - “この提案はGTFSの後方互換性の原則を尊重していないため、代わりに別のファイルを作成することを提案します。”
最低投票数	少なくとも5票が投じられなければなりません。
参加者構成	少なくとも2つのGTFS consumer および 2つのGTFS producerが投票に参加しなければなりません。 - これらのcontributorは、両方の役割を代表できる場合であっても、Consumer または Producerのいずれかとしてのみ扱うことができます。 - 提案のテストを意図するFirst Adopterは、提案のAdvocateとして行動していない場合、投票し、この要件の対象として数えることができます。
Advocateの投票	Advocateは、自身の提案に投票することはできません。
無効な投票	以下の場合、投票は無効とみなされます。 - contributorが公式の投票期間外（開始前または終了後）に投票した場合。 - 個人または組織が複数回投票した場合（個人または組織ごとに許可される投票は1票のみです）。 - contributorが実行可能なフィードバックを含めずに提案に反対票を投じた場合。
最低投票期間	投票期間は少なくとも14暦日間継続し、23:59:59 UTCに終了しなければなりません。

ステップ2.5: テスト¶

注記: トラックB: 非機能的変更およびトラックC: ドキュメント保守には適用されません

1つのGTFS Producer と1つのGTFS Consumer が、テストのために提案された変更を実装する First Adopters として協力を申し出ます。

アクション

テスターの確認
- Advocate は、変更をテストし、Pull Requestのコメント欄でコメントを提供する First Adopters の身元を確認します。
テスト
- First Adopters は、公開環境で変更を適用し、テストします。Producerの場合、これは公開GTFSフィードを意味します。Consumerの場合、これはアプリケーションの公開されている本番バージョンを意味します。
- テストは、採択のための投票を呼びかける前に、すべての要件が満たされていることを確認するために必要な期間継続します。
テストの証明
- First Adopters は、pull requestのコメントで実装された変更へのリンクを共有することにより、テストの証明を示します。

要件

Advocate は、テスト期間のすべての要件が完了した後にのみ、採択のための投票（ステップ2.6）に進むことができます。

要件	詳細
最小テスト期間	テスト期間は、少なくとも7暦日間継続しなければなりません。
テスターの参加	少なくとも1つのConsumerおよび1つのProducerを含む、少なくとも2人の貢献者が、提案された変更を適用しテストしなければなりません。
テスト中の問題の特定	変更をテストするFirst Adoptersは、Advocateが提案に必要な調整を行えるよう、特定された問題を、理想的には解決策の提案とともに、Pull Requestにコメントして報告しなければなりません。 - 変更が提案の範囲に重大な影響を与える場合、任意のContributorがそれを指摘することができ、その場合Advocateは提案を議論ステップ（ステップ2.2）に戻すか、または取り下げを検討する必要があります。
テストの証明	First Adoptersは、公開環境で変更を適用、テスト、および共有しなければなりません。 - Producersの場合は公開GTFSフィードへのリンク - Consumersの場合はGTFSを利用するアプリケーションへの公開リンク。

ステップ2.6: 採択の投票¶

注: Track C: Documentation Maintenance には適用されません

コミュニティは、提案された変更を仕様に正式に採択するかどうかを確認するために投票します。

アクション

投票の告知
- Advocate は、投票の終了時刻を明記して、Pull Request のコメント欄で投票の開始を告知します。
- Advocate は、Pull Request のコメントへのリンクおよび投票の終了時刻を記載して、GTFS Changes mailing list のディスカッションスレッドで投票を告知します。
投票プロセス
- Contributors は、Pull Request のコメント欄で投票しなければなりません。
編集および取消し
- Advocate は、投票期間中、編集上の目的に限り提案を編集することができます。
- Advocate は、いつでも投票を取り消すことができます。
投票終了の告知
- Advocate は、Pull Request のコメント欄で投票の終了を告知し、結果を含めます。
- Advocate は、結果を含めて、GTFS Changes mailing list のディスカッションスレッドでも投票の終了を告知します。
否決された投票
- 投票が否決された場合、Advocate は以下のいずれかを選択することができます。
  1. 提供された実行可能なフィードバックに基づいて提案を調整し、再度投票を実施する、
  2. ディスカッションのステップ（ステップ2.2）に戻り、スコープを再定義する、または
  3. 提案を放棄する。
- Advocate は、Pull Request のコメント欄およびGTFS Changes mailing listのディスカッションスレッドで、その決定を告知しなければなりません。

要件

投票は、以下の条件を満たさなければなりません。

要件	詳細
承認ルール	contributors の80%以上が+1に投票した場合、投票は可決されます（特別多数決）。
投票形式	投票は以下の形式でなければなりません。 - “+1 または -1、組織名、Contributor Type（Consumer、Producer、またはGeneral Contributor）、作成したFeedまたは利用するApplicationへのリンク”
反対票	反対票（-1）を投じる contributors は、実行可能なフィードバックを提供しなければなりません。 - 実行可能なフィードバックとは、特定された問題の解決に役立つ具体的な所見または提案を提供する、実践的かつ建設的なフィードバックです。 - “この提案はGTFSの後方互換性の原則を尊重していないため、代わりに別のファイルを作成することを提案します。”
最低投票数	少なくとも5票が投じられなければなりません。
参加者構成	少なくとも2つのGTFS consumers および 2つのGTFS producers が投票に参加しなければなりません。 - これらの contributors は、両方の役割を代表できる場合であっても、Consumer または Producer のいずれかとしてのみ考慮されます。 - 提案をテストした First Adopters は、提案のAdvocateとして行動していない場合、投票でき、この要件に算入されます。
Advocateの投票	Advocate は、自身の提案に投票できません。
無効な投票	以下の場合、投票は無効と見なされます。 - contributor が公式の投票期間外（開始前または終了後）に投票した場合。 - contributor が複数回投票した場合（contributor ごとに許可される投票は1票のみです）。 - contributor が実行可能なフィードバックを含めずに提案に反対票を投じた場合。
最低投票期間	投票期間は少なくとも14暦日間すべて継続し、23:59:59 UTCに終了しなければなりません。

ステップ 2.7: 採用¶

注記: すべてのトラックに適用されます。

Maintainer は、投票が成功した後に正式に採用された変更を実装します。

アクション

実装
- 投票が可決された場合、Contributors が Contributor License Agreement に署名していることを条件として、Maintainer は投票対象となった Pull Request を14暦日以内にマージしなければなりません。
Revision History の更新
- Maintainer は、投票が成功した後に採用されたすべての変更を、月に1回 Revision History に記録します。

要件

要件	詳細
実装	Maintainer は、正式に採用されたすべての変更を14暦日以内にマージするべきです
Revision History	Maintainer は、Specification の Revision History を毎月更新し、最近採用されたすべての変更について、簡単な説明および関連する議論へのリンクとともに記録するべきです。Documentation Maintenance の変更はこの要件の対象外ですが、価値があると判断された場合は Revision History に追加することができます。