[Governance] New GTFS Schedule Governance Proposal #544
Conversation
eliasmbd
added
GTFS Schedule
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.
| 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.
| A GTFS Producer is an individual or organization responsible for generating GTFS data. This may include transit agencies, data vendors, aggregators, or planners. | ||
|
|
||
| * If an individual or organization assigns GTFS feed production to another party, only one of them can be recognized as the Producer. | ||
| * To vote, Producers must reference the GTFS feed they represent to confirm their role as Producer. |
There was a problem hiding this comment.
Clarification needed for Producers representing multiple GTFS feeds. Can they pick any feed? Should it be a feed relevant to the proposed change?
There was a problem hiding this comment.
Could an agency who is not the feed picked by the Producer vote separately?
There was a problem hiding this comment.
@westontrillium We think Producers representing multiple GTFS feeds can pick any feed they manage, as long as they choose only one and ensure it is not represented twice. The feed does not need to be relevant to the proposed change, as determining relevance would be complicated to uphold and moderate.
Our intention is to convey a principle along the lines of: "One organization, one feed, one vote", in hopes that this ensures fair representation while keeping the process practical and inclusive. Maybe the language can be changed to reflect this a bit better.
@paulswartz Yes. As long as a it is a unique feed, the agency can represent itself. We are trying to avoid double representation.
|
I have reviewed all the changes and left comments/suggestions. Overall, very pleased with these changes. Thank you to all involved in making this happen! My last bit of feedback is perhaps a bit trivial, but using "TL;DR" as a section title in the official PR template feels a little too informal and regionally/culturally specific to me. Couldn't we just use "Summary" for that section? 😅 |
Add clarification to explicitly state that General Contributors are allowed to vote in roles.md
Co-authored-by: Weston Shippy <[email protected]>
Co-authored-by: Weston Shippy <[email protected]>
Co-authored-by: Guillaume Campagna <[email protected]>
Co-authored-by: Weston Shippy <[email protected]>
Co-authored-by: Weston Shippy <[email protected]>
@AdrianaCeric Thank you for your suggestions, all great improvements to the template. Indeed, time flies! We are glad to see you here being a part of this. |
We really appreciate your thoughtful feedback @mgilligan, and we're reassured by your confidence in both the MobilityData team and the larger GTFS community. As stewards of GTFS, we are committed to ensuring it remains a community-led standard. To support this, a core goal has been to establish a governance process that enhances community involvement while also providing greater stability and clarity to the specification's development. We also want to make one thing absolutely clear: MobilityData is fully committed to keeping the development of GTFS open and accessible to all, with no intention of introducing a paywall for proposals or contributions to the specification. The specification has always thrived on grassroots collaboration, and we are deeply dedicated to preserving and strengthening that philosophy. |
📢 AnnouncementAfter reviewing your comments and committing the changes over the past month, we’re ready to move forward. We’ll launch the vote on this proposal on May 1, 2025. If you haven’t had a chance to review it yet, we encourage you to do so before then. The voting period is expected to last two weeks. |
There was a problem hiding this comment.
Governance is not an easy topic. Thank you MobilityData team for your work on this. I have made several comments on the proposal text — sorry for the tardiness. I do worry that we haven't heard from key stakeholders before a vote. Something I would still like to see is a clear statement of need for these changes. In the workshop series, I heard a key goal was to have a more legible process to bring changes to broad adoption. Looking for some hypotheticals, how would this process serve GTFS-Flex and GTFS-Fares?
|
|
||
| #### General Contributors | ||
|
|
||
| Individuals or organizations that do not qualify as either Producers or Consumers are considered as General Contributors or simply referred to as Contributors. General Contributors can vote in proposals. |
There was a problem hiding this comment.
I believe that GTFS change process currently allows anyone to vote, but the norm has been that only Producers and Consumers vote. Please correct me if this isn't exactly right.
Questions about “General Contributor” role:
- What organizations or individuals do we expect to be “General Contributors”?
- What value do we expect their votes to add, since they can already follow along and participate in discussions?
- Is there any qualifier for a General Contributor’s participation, similar to how a Producer must share GTFS data or Consumer must provide a link to an application? i.e. description of interests or qualifications or GTFS community participation requirement? It seems like anyone might claim the role of a General Contributor.
The benefits of explicitly enabling General Contributor votes are not clear to me yet, and I’m not sure they outweigh the risks.
|
|
||
| The Maintainer supports and facilitates the specification [Change Process](change-process.md), and their role as an impartial facilitator is to guide the community toward making consensus-driven decisions. MobilityData currently serves as the Maintainer of GTFS. | ||
|
|
||
| **Responsibilities**: |
There was a problem hiding this comment.
Should the Maintainer role also include some of the following?
- The Maintainer may solicit and develop use cases to facilitate community collaboration specification development
- The Maintainer may develop draft Specification documents for consideration by the community (Contributors)?
There was a problem hiding this comment.
This may also be an appropriate segue to discuss MobilityData governance. How does MobilityData decide which initiatives in which to invest staff time? MobilityData board candidates are screened by a committee. Who is on the committee? How is this determined? According to what criteria?
| | **Voting Format** | Votes must be formatted as follows: <br>- *“+1 or \-1, Organization Name, Contributor Type (Consumer, Producer, or General Contributor), Link to Produced Feed or Consuming Application”* | | ||
| | **Voting Against** | Contributors providing a negative vote (-1) must give actionable feedback. <br>- Actionable feedback is practical and constructive, providing concrete observations or suggestions to help solve the identified issue: <br> - “*This proposal does not respect the backward compatibility principle of GTFS and we propose to create a separate file instead.*” | | ||
| | **Minimum Votes** | At least 5 votes must be cast. | | ||
| | **Participant Composition** | At least 2 consumers and 2 producers must participate in the vote. Each of these contributors can only be considered either a Consumer or Producer even if they are able to represent both roles. | |
There was a problem hiding this comment.
At least 2 Producer and 2 Consumer +1 votes are required for adoption. There is no statement that any of these votes should be from the Producer(s) or Consumer(s) that undertook testing. I’m sure it is assumed that parties that initiated testing would usually vote in the adoption step. Should there be any clarifying language?
|
|
||
| **<ins>Actions</ins>** | ||
|
|
||
| 1. **Issue Submission** |
There was a problem hiding this comment.
What about providing a template or guide similar to PULL_REQUEST_TEMPLATE.md? This is a really useful framework.
https://github.com/google/transit/blob/master/.github/ISSUE_TEMPLATE/spec_change.yml
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! 🚀