[Governance] New GTFS Schedule Governance Proposal#544
[Governance] New GTFS Schedule Governance Proposal#544eliasmbd merged 39 commits intogoogle:masterfrom
Conversation
eliasmbd
added
GTFS Schedule
abyrd
left a comment
abyrd
left a comment
There was a problem hiding this comment.
Overall this looks quite good and very clear. I added a few comments that are mostly just style related. I am specifically not weighing in on the new voting thresholds, but will not oppose them if the rest of the community agrees on them.
One thing that stands out to me is that this proposal creates the role of "maintainer" and writes the name of a specific independent organization (Mobility Data) into the GTFS specification itself, assigning that organization the maintainer role.
One might reasonably argue that this is just formalizing a shift that has been happening for years, but it is still a significant change that gives Mobility Data an official status I think it didn't technically have before.
I would be very interested to hear from the original creators of GTFS (Google and Portland TriMet). Do these organizations support enshrining Mobility Data as the official maintainer of the GTFS spec, to the extent of writing its name into the governance documents of the spec itself?
Similarly I would like to hear from community members who cultivated and maintained the GTFS spec over many years when Google was less active in that respect.
Confirmation from these originators and longtime supporters of the GTFS concept would go a long way toward legitimizing the change and cementing Mobility Data's role.
| We chose CSV as the basis for the specification because it's easy to view and edit using spreadsheet programs and text editors, which is helpful for smaller agencies. It's also straightforward to generate from most programming languages and databases, which is good for publishers of larger feeds. | ||
|
|
||
| **Feeds should be easy to parse** | ||
| Feed readers should be able to extract the information they're looking for with as little work as possible. Changes and additions to the feed should be as broadly useful as possible, to minimize the number of code paths that readers of the feed need to implement. (However, making creation easier should be given precedence, since there will ultimately be more feed publishers than feed readers.) |
There was a problem hiding this comment.
I certainly agree with the underlying principle here. But I don't see how making changes "as broadly useful as possible" would "minimize the number of code paths". I don't think one follows from the other. Parentheses could be removed from the final sentence as it's as important as any other information here.
There was a problem hiding this comment.
@abyrd These are great points. We've decided to keep the Guiding Principles unchanged for now, as we believe that addressing this topic would require a separate discussion altogether. We would like to wait until this proposal is finalized before initiating that conversation with the community. In the meantime, we will add it as an item in the governance backlog.
There was a problem hiding this comment.
@eliasmbd Elias - I think a call to vote tomorrow on the new proposal is premature and if there is nothing pressing, I'd like to request a brief postponement at this time. This is an important document and I think more comments from key people would be beneficial prior to releasing this to the community.
| Feed readers should be able to extract the information they're looking for with as little work as possible. Changes and additions to the feed should be as broadly useful as possible, to minimize the number of code paths that readers of the feed need to implement. (However, making creation easier should be given precedence, since there will ultimately be more feed publishers than feed readers.) | ||
|
|
||
| **The spec is about passenger information** | ||
| GTFS is primarily concerned with passenger information. That is, the spec should include information that can help power tools for riders, first and foremost. There is potentially a large amount of operations-oriented information that transit agencies might want to transmit internally between systems. GTFS is not intended for that purpose and there are potentially other operations-oriented data-standards that may be more appropriate. |
There was a problem hiding this comment.
I suggest removing both instances of the word "potentially". But completely agree with the underlying idea here.
There was a problem hiding this comment.
@abyrd Please view reply above regarding Guiding Principles.
|
Thanks @abyrd, we truly appreciate your feedback! You're raising a great point about the maintainer role, and we completely agree that it's important to hear from the broader community. Input from long-time contributors would be especially valuable. Just for context, the maintainer role was introduced and discussed during last year's working group meetings. From the start, the intent was that this role could be filled by whoever the community decides, even if that's not MobilityData in the future. This was emphasized in those discussions, and we didn't hear specific concerns at the time. That said, the community always has the ability to amend the governance (including roles like this one), and this proposal actually provides a clearer, more structured process for making those changes. Our goal is to ensure that decisions remain transparent, inclusive, and truly community-led. |
|
@abyrd, thank you for soliciting a response from the original team. We developed GTFS nearly 20 years ago so I sincerely hope that my voice does not carry any more weight than others in the GTFS community. I think MobilityData has done a lot to move the needle forward on some proposals that sat in limbo for years, keeping documentation and validators up-to-date and providing clear examples for more complex proposals such as GTFS Fares V2. TriMet and our customers has benefited from all of this work. I'm personally +0 about the overall governance changes and cementing MobilityData as the maintainer. My only hesitation is an unlikely fear that MobilityData could position themselves behind their membership pay wall to get official proposals reflected on gtfs.org. However, all of my interactions with the MobilityData team and the larger GTFS community causes me to believe that would not happen. |
There was a problem hiding this comment.
Thank you for your work on this! Governance is a topic often complained about but rarely worked on.
I added two small comments, to clarify that producer and consumer can't be the same contributor.
I agree with Andrew that the pillars imagery is not really supporting (😉) the rest of the content.
For those wanting to review the content, I would note it's way easier to look at content directly in the branch than using Github's PR system since this is a big change with mostly new stuff.
Updating intro page with overview table
My expectation is that it wouldn't have changed the length of the discussions and all the work the advocate (MD in this case) would have to do. Having consensus is still a hard process. But instead of us going to MD and telling them we were planning to do implement it and implement a draft proposal, we would have saved probably a couple of engineering-week by having the changes done in the first vote discussion before the implementation. Even if I agree the testing phase is important and real-implementation are required to show the need for the change is real, it's very rare that there's major changes needed during the testing phase. In both the case of fares-v2 and trip modifications, the changes were based on opinions about implementation detail, not blocker from the point of view of the first adopters. With this in mind, I don't expect changes between the first and second vote to happen often. |
Vote LaunchHello GTFS Community, After extending the review period and incorporating some of your feedback, we now feel confident in moving forward with a vote on this proposal. Thank you to everyone who shared their thoughts—any insights not reflected in this version will be collected for future discussions. Voting RequirementsAs a reminder, here are the voting requirements under the current GTFS governance:
Post-adoption stepsIf the new governance is adopted:
Voting PeriodWe are launching the vote for a period of 16 full calendar days to take into account the multiple national holidays across the globe. The vote will close on July 6, 2025 at 23:59:59 UTC. Thank you for participating in this process and happy voting! |
|
+1 Trillium I feel overall quite positive about these changes, and I think the 6 month "trial" period offers us sufficient insurance should there be anything we need to adjust; I'm eager for us to start collectively evaluating how this new process impacts proposals. Thanks to everyone involved for all your contributions on what has been a huge undertaking, and thanks to MobilityData for providing the necessary leadership to keep things moving! |
|
+1 from @interline-io |
|
+1 from Transit |
|
+1 from Google |
…orial-changes New Governance: Minor editorial editorial changes
|
@bdferris-v2 Thanks for pointing this out. We made a few editorial updates to improve how the governance change is communicated if adopted. It should be noted, these changes do not interfere with the current voting process since they are editorial. They include:
Additionally, we’ll reinstate and maintain |
|
+1 from WSDOT Public Transportation Division |
|
+1 from BART |
|
+1 from the @mbta |
|
The voting period is closed and the vote has passed. 7 votes in favor, 0 votes against. +1 @westontrillium (trillium) Thank you to everyone who participated in the Governance work to get this foundational proposal across the finish line. We will be posting updates on next steps and get the governance merged as soon as possible. |
Updates notes before merging
|
18 participants
Summary
We’re proposing an update to the current GTFS governance process based on two years of community feedback. Key improvements include clearer documentation, structured proposal phases, and revised voting requirements. Now, we’re inviting final discussions before calling a vote to adopt these changes.
🌍 Context
Governance has been a long-standing topic of discussion within the community. Over the past two years, MobilityData has gathered input through various consultations:
See Issue #436 and #413 for further details.
We’ve incorporated these discussions into a structured proposal and now seek targeted community feedback before finalizing the vote.
🔧 Key Changes
⏭️ Next Steps
We invite the community to review the proposed next steps and share feedback to ensure all perspectives are considered and no key aspects are overlooked. Your input is essential to ensuring the new governance framework reflects the needs of the community.
Let us know your thoughts! 🚀