Change Process Overview

The specification change process guides how the community proposes, reviews, and adopts changes to the specification in the GTFS Repository.

The specification change process is categorized into 3 tracks according to the three change types: functional changes, non-functional changes, and documentation maintenance. The change process is separated into 2 stages:

• Issue Stage: New ideas are introduced, needs are identified, and the feasibility of changes is discussed.
• Pull Request Stage: Ideas from the Issue Stage are developed, tested, and approved for adoption.

The entire process happens within the GitHub google/transit repository and ensures that all changes are thoroughly evaluated before being adopted.

The issue stage is the same for all 3 tracks. The Pull Request stage differs in each of the 3 tracks.

Stage 1: Issue

The Issue Stage is meant for discussing new ideas, identifying needs, and proposing improvements to the specification. Issues help evaluate the necessity and support for a change, while organizing the resources required to proceed to the Pull Request Stage.

It’s recommended to start at the Issue stage to build consensus around new ideas. However, if the proposal’s scope is already well-defined, beginning directly at the Pull Request stage is appropriate.

The Issue stage is composed of the following steps:

• 1.1 Issue Publication
• 1.2 Issue Discussion

Stage 2: Pull Request

The Pull Request Stage is where ideas from the Issue Stage are developed and implemented into the specification. This stage is divided into 3 tracks depending on the change type. Consider that only Track A: Functional changes utilizes all the steps. Track B: Non-Functional changes and Track C: Documentation Maintenance utilize a shortened version of the process

Track A: Functional Changes

This process guides how the community proposes, reviews, and adopts Functional changes to the specification in the GTFS Repository.

1. A proposal is submitted by opening a Pull Request in the GTFS Repository.
2. The community engages in discussions to refine the proposal and reviews it before testing.
3. After a preliminary vote, First Adopters test the proposed changes.
4. The community votes to decide whether the changes should be officially adopted.
5. Finally, changes are implemented into the specification.

Track A: Functional Changes utilizes steps:

• 2.1 Pull Request Publication
• 2.2 Pull Request Discussion
• 2.3 Pull Request Review
• 2.4 Vote to test
• 2.5 Testing
• 2.6 Vote to Adopt
• 2.7 Adoption

Track B: Non-Functional Changes

This process guides how the community proposes, reviews, and adopts Non-Functional changes to the specification in the GTFS Repository.

1. A proposal is submitted by opening a Pull Request in the GTFS Repository.
2. The community engages in discussions to refine the proposal.
3. The community votes to decide whether the changes should be officially adopted.
4. Finally, changes are implemented into the specification.

Track B: Non-Functional Changes utilizes steps:

• 2.1 Pull Request Publication
• 2.2 Pull Request Discussion
• 2.3 Pull Request Review
• 2.6 Vote to Adopt
• 2.7 Adoption

Track C: Documentation Maintenance

This process guides how the community proposes, reviews, and adopts changes to maintain the documentation in the GTFS Repository.

1. A proposal is submitted by opening a Pull Request in the GTFS Repository.
2. The community engages in discussions to refine the proposal
3. Finally, changes are implemented into the specification.

Track C: Documentation Maintenance utilizes steps:

• 2.1 Pull Request Publication
• 2.2 Pull Request Discussion
• 2.3 Pull Request Review
• 2.7 Adoption