Overview of the Change Process

The GTFS specification is not set in stone. Instead, it is an open specification developed and maintained by the community of transit agencies, developers, and other stakeholders who use GTFS. It is expected that this community of producers and consumers of GTFS data will have proposals for extending the spec to enable new capabilities. To help manage that process, the following procedures and guidelines have been established.

The general outline for changing the spec has a couple of steps:

  1. Propose a change on the GTFS-changes discussion list.
  2. Receive comments and feedback from the GTFS community and iterate on the proposed change.
  3. Find at least one GTFS producer and one consumer to implement and test the proposed change.
  4. Submit a final request-for-comments on the proposed change to the discussion list. If no outstanding issues are identified after one week’s time, the proposal will be officially adopted.

The discussion group will serve as the primary place for suggesting changes to the spec, such that users of GTFS can learn about and offer feedback on proposed changes. If the community generally agrees that the proposal is worthwhile and follows the GTFS guiding principles, it will be officially added to the spec. We also require that any proposed change be implemented by at least one GTFS producer and one consumer, in order to verify the feasibility of that change in practice.

In addition to the discussion group, note that the GTFS Changes Site will be used to document exiting GTFS change proposals in support of of the discussion group.