Modifications to the GTFS Governance: Phasing Plan

[eliasmbd]

🗒️ Context

After conducting numerous interviews and workshops throughout 2023, MobilityData is suggesting several refinements to address common problems in both the formal amendment process and the informal processes related to GTFS governance.

In this issue, you will find a summary of the most common problems as highlighted by the community.

🤔 Problems

High barrier to entry

• Scattered communication leads to confusion regarding where to access key information.
• Confusion on where the source of truth for documentation lies.
• Lack of overview on what is actively being discussed.
• The governance process is designed for major changes, creating an intimidating barrier for individuals seeking to propose minor improvements.

Insufficient engagement in the proposals in the early stages of development.

• Vague process before the Pull Request stage.
• The level of consensus is frequently unclear until a Pull Request is initiated or a vote is called.
• Reviews are vague, it’s hard to know if a proposal has been thoroughly reviewed before testing and adoption.

First adopters are frequently impacted by last-minute changes to their implementation, leading to an increase in committed resources.

• First Adopters need to implement changes before opening a vote. Certain problems identified too late demand multiple rounds of testing and require supporting various versions of a proposal.

🔮 Phasing Plan

Based on these issues, MobilityData has worked on a phasing plan, which will be updated to represent the current status.

Phase	What’s included	Status
1 - Effective communication and GitHub management	Publication of a monthly “GTFS Digest” that gives an overview of the active conversations in the community and latest additions. Using GitHub issue templates and labels to guide contributors and give a better overview of the status of each issue. [Governance] Phase 1: Issue Templates #417 [Governance] Phase 1: GTFS Digest Release #419 Modified Labels Categorization	✅ Done
2 - Enhancing voting and reviews	Adding an earlier vote to increase the visibility and potential issues of a proposal early-on. The veto would be moved to this earlier vote to incentivise contributors to review the proposal early and share any major concerns before early adopters implement the changes proposed The final vote would follow a majority vote with a 80% threshold Incorporating review guidelines to simplify the process of providing feedback on proposals. [Governance] Phase 2: Enhancing Voting and Reviews #436 [Governance] New GTFS Schedule Governance Proposal #544	🚧 WIP
3 - Fast-track process for smaller changes	Adding a lightweight process for smaller changes Other editorial changes on the spec amendment process Including other ways of contributing than via a Pull Request Clarifying the roles and major steps Add a visualization [Governance] Phase 2: Enhancing Voting and Reviews #436 [Governance] New GTFS Schedule Governance Proposal #544	🚧 WIP

🔎 Future Considerations

While the phasing plan should address most of the problems highlighted by the GTFS community, some solutions worth exploring remain.

• Merging GTFS Schedule and GTFS Real-time governances
• GTFS Community Platform
• Formalize Working Group
• Adding GTFS Project Roadmap
• Flexibility in 1 Consumer and 1 Producers testing requirements and depreciation of “small” unused fields
• YouTube videos for GTFS changes and other applications

⏩ What’s next?

1. We welcome the GTFS community to comment in the section below and share their thoughts.
2. Questions for the community
   1. Do you think the proposed solutions best help alleviate the problems identified?
   2. Out of the 3 proposed phases, would you split any of them up to include more details?

[e-lo]

💟 I love this in general.
☑️ Thank you for digesting all of the concerns you heard into a plan of action!

Requests:

1. I'd love some more clarity on the two-stage voting process – I don't really understand it as currently described.
2. I'd love a process split by "normative changes" and non-normative as well as large- (e.g. faresv2) vs small (e.g. adding another enum). Non-normative changes are important for making sure the spec is implemented as intended and is supported by good examples and documentation.
3. In addition to the next steps that you've highlighted, "what will it take" to implement these changes and how can we help?

[mmorang]

Thank you. Excellent job summarizing the problems and pain points!! I also like your proposed solutions.

The one thing I would add is that, in addition to the monthly summary of ongoing discussions, there needs to be a low-traffic announcement list in which official changes to the spec are described clearly and concisely as soon as they are officially adopted. I think some people don't necessarily want or need to be involved in the proposals and just need to be informed of changes as soon as they occur.

[gcamp]

👍 this is a step in the right direction. Generally agree with the steps laid out, but curious about the specifics especially of #3.

I would also add in future considerations :

• The "must be implemented by one producer and one consumer" rule is a good rule in spirits, but I think should be more flexible, especially for individual fields when adding a new normative change.

[skinkie]

@gcamp I think for merging the change the 1+1 idea works well. Hence it is implemented and tested. But I also would consider adding an automatic deprecation if nobody would actually picks up the change after those initial parties. 1+1 is still a private extension.

[AdrianaCeric]

Great to see MobilityData actively addressing the challenges in GTFS governance! Reiterating discussions at the European workshop, in addition to the proposed phasing plan, it might be beneficial to consider incorporating representatives from various user groups or constituencies, such as student ambassadors, into the voting and review processes to provide unique perspectives. I believe one of the primary objectives of addressing the "High barrier to entry" concern is to narrow the divide between new contributors (including individual/independent transit developers, youth, students and non-tech transit enthusiasts) and the established community, where private companies tend to dominate the voting processes and discussions in the working groups.

For example, in Phase 1, when considering the publication of the "GTFS Digest," the choice of platform is crucial. If it is only posted on the Slack, it might inadvertently become an echo chamber for the same group of "power-maintainers" of the spec. Options include making the Slack more easily joinable or exploring alternative channels, such as YouTube videos or increased social media/blog presence, to promote the Digest and broaden its reach beyond the existing community.

[westontrillium]

Generally very excited about what's in this plan!

• Adding an earlier vote to increase the visibility and potential issues of a proposal early-on.
  • The veto would be moved to this earlier vote to incentivise contributors to review the proposal early and share any major concerns before early adopters implement the changes proposed
  • The final vote would follow a majority vote with a 80% threshold

I agree with @e-lo; I'd also like more clarity on the above, as well as how it was determined that, for instance, the veto vote is first and the final vote is a majority vote (at an 80% threshold) and not the other way around. How were these specifics determined? Not saying these choices are worse or better than some alternative, just want to understand the reasoning behind them. 🙂

Also, would it be a good idea to have a trial period for this new voting process so we can actually see it in practice, identify any issues, etc., before having to fully commit? We would, of course, have to agree that any votes conducted under the new rules are valid beyond the trial period, but it could be a way of mitigating the greater risk of being stuck with a process we didn't realize was unfeasible at the time of adoption.

[leonardehrenfried]

I'm mostly in favour of this change.

I can however forsee that not everybody can agree what is a "small change". Nevertheless, I think we should try it and resolve issues as they come up.

[westontrillium]

I can however forsee that not everybody can agree what is a "small change". Nevertheless, I think we should try it and resolve issues as they come up.

Yes, it would probably be good to have a specific, measurable threshold if possible. "X number of new fields/files or more constitutes a large change," etc.

[abyrd]

I just created issue #415 to describe something that I think may be a major factor affecting timely review and comprehensive understanding of change proposals.