GTFS Schedule Governance Revision

[etienne0101]

Hi everyone,

As committed in our update on January 7th, we are now initiating the first formal revision period for the GTFS Schedule Governance Framework.

The goal of this review is to conduct a pragmatic health check to identify any minor adjustments to make, without conducting broad restructuring.

Context & Observations

Since the adoption of the framework in July 2025, we have seen the process in action through 2 Pull Requests introducing functional changes:

• PR #598 Add safe duration fields to trips.txt to provide better flexible trip time estimates
• PR #578 Add network sets and relax constraint on networks in fare_leg_join_rules.txt (note: although not adopted yet, this PR is halfway through the process and passed the vote to test phase).

Call for Feedback

We invite contributors, especially those who have opened, reviewed or participated in Issues and PRs under the new rules (since July 7, 2025), to share their experiences. Specifically:

1. Has the new governance impacted how you are engaging with spec development? If so, how?
2. Does the current governance make the process of improving the spec feel fairer?
3. Are there small adjustments that would lower the barrier to entry for new contributors?

Proposed Timeline

We want to keep this review focused and efficient:

• May 2026: Community discussion and feedback collection.
• June 2026: MobilityData will summarize the feedback. If clear improvements are identified, an amendment will be posted as a new issue to follow the standard governance process.
• Future: A second follow-up is anticipated in 12–18 months, as the governance will remain open to feedback and future improvements.

Please share your thoughts below. We are looking for constructive feedback that helps us maintain a stable yet responsive specification.

Thank you for your continued participation and engagement! We look forward to hearing from you.

Sincerely,

The MobilityData Team

[etienne0101]

As the discussion and feedback collection period ends this Sunday, I'd like to suggest two areas where we could introduce minor changes to the governance.

1- A simplified process for documentation maintenance
For typo fixes and minor updates to the documentation, the mandatory 7-day discussion period + 7-day review period can be inefficient. Although changes must remain traceable via Pull Requests open to everyone, we could implement a fast track for documentation maintenance. As an example, this PR by MobilityData did not strictly follow the full governance process.

2- Building trust with more evidence during testing Although it falls under GTFS Realtime Governance, this discussion about adding screenshots to demonstrate tests is interesting.
Even though an implementation can be tested by different types of consumers - and not just rider-facing applications - a screenshot or a link to the implementation (an app or an integration into a platform), whenever possible, could help build mutual trust regarding what has actually been tested.

[antrim]

Sharing some thoughts before the comment period closes, as someone who has been involved with GTFS since its early days. I appreciate the work that's gone into developing this framework, and I'm offering this in the spirit of making the June summary as useful as possible.

Contributors from outside the usual characters, e.g. smaller agencies, are the ones who could tell us whether the process is working. Active outreach — a short structured survey, direct contact with stakeholders not represented here — would make the June summary more useful.

The review could be framed as a cost/benefit analysis. What is the community experiencing?

Potential benefits:

• Process clarity through a thoroughly documented process.
• Safer route to adoption through a legible testing step.
• Broader stakeholder participation through defined voter categories.

Potential costs / risks:

• Bureaucratic process with higher overhead.
• Is the volume of documentation a barrier to understanding?

Can we look at the process through the eyes of someone who is new to the governance process?

More broadly, what are the highest-priority unmet needs for GTFS stakeholders right now? Does the new governance process accelerate or delay progress toward a more complete, better-defined, and more widely adopted spec? Or is it neutral?

Was spec governance ever the primary blocker? To be direct: I'm not convinced spec governance was ever the big problem. The persistent problems in this ecosystem are elsewhere: producers and consumers implement GTFS in non-standard ways, and adoption of new features and extensions is slow. My worry is that investing in a heavier process spends finite community and MobilityData attention on governance, while the parts that aren't working as well get less. I don't know that for certain. But I think it's a question this review should consider.

For example, as far as I understand, Google Maps still does not accept GTFS datasets that include most GTFS-Flex features, which creates a blocker. Google Maps doesn't just ignore the GTFS-Flex data elements, they reject the entire feed and ask the producer to provide a feed w/o those GTFS-Flex features. (Google's own Transit Partners documentation confirms GTFS-Flex datasets cannot currently be accepted: https://support.google.com/transitpartners/answer/1111481.) Governance refinement on the spec side does not change that. GTFS-Flex was officially passed in March 2024 #433 (comment).

Does the governance reform move the needle on conformance and adoption and ultimately better traveler information? I suggest the June summary should consider this governance proposal alongside other strategic questions for GTFS and MobilityData.

[etienne0101]

Thank you for this thoughtful contribution and for sharing your perspective on the ecosystem. Supporting the needs of smaller agencies and ensuring GTFS accessibility remain top priorities for us.

We love the idea of more targeted outreach and will consider a structured survey or other methods to gather feedback, while sharing what we learn where appropriate.

I completely share your intuition that technical literacy, conformance, and data adoption are the primary barriers to entry rather than the governance process itself. However, we see this revised process as a way to create stronger signals of implementation readiness before something becomes part of the official specification. Especially through broader producer/consumer support and testing.

You are right that formal spec adoption does not automatically guarantee implementation by major consumers. This is a critical adoption gap we are actively trying to close --> In fact, we will launch a new tool to help address this 🔜

We will include your questions and cost/benefit suggestions in our upcoming June summary.