[Governance] Phase 2: Enhancing Voting and Reviews

[eliasmbd]

This issue puts forward two alternatives for a new GTFS Spec Amendment Process.

Context

This GitHub Issue is part of the ongoing effort to enhance the GTFS Governance, particularly focusing on the Specification Amendment Process outlined in phase 2 of the phasing plan published in December 2023. The proposed changes are informed by interviews, workshops, and community conversations conducted by MobilityData.

What are we trying to solve?

Proposing changes to GTFS has been a cumbersome process, leading to delayed outcomes and uncertainties. The top-priority issues include insufficient visibility on proposals, limited reviews, and a vague process before the Pull Request stage.

What is not included in phase 2?

The following items will be covered in Phase 3 of the governance as highlighted in the phasing plan:

• 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
• Add a visualization

Proposed Changes Overview

This proposal suggests a series of changes to the Specification Amendment Process, summarized below:

Change	Description	Why?
Adding an earlier voting stage	Introduce a two-step voting scheme to increase community engagement before the final vote.	Enhance visibility and encourage community participation, addressing issues identified too late and reducing uncertainties.
Introducing majority voting	Replace the second vote with an 80% majority vote, restricting the -1 vote to the initial stage.	Overcome barriers for early adopters, increase participation, and carefully define changes allowed between the two votes.
Increasing voting requirements	Incorporate a new minimum 5 votes requirement, along with increased minimum consumer and producer requirements.	Prevent a reduced number of contributors from pushing changes and ensure diverse perspectives in the voting processes.
Formalizing review guidelines	Create a new section to guide community reviews on GTFS spec change proposals at the voting stage.	Address uncertainties around thorough reviews and ensure decisions align with the long-term sustainability of GTFS.
Formalizing steps before Pull Request	Extend the process to include an ideation step before the Pull Request, refining solutions through community conversations.	Account for vital discussions held before the creation of a proposal at the Pull Request stage, improving the quality of proposals.
Formalizing major roles and responsibilities	Introduce a new section to provide clarity on the main roles involved in the specification amendment process.	Clarify the players and their responsibilities, especially for newcomers, in the current process.

Proposed Alternatives

This document proposes two alternatives for the Specification Amendment Process, each with its unique characteristics:

Alternative A: First vote in the GitHub Pull Request

• First voting stage occurs in a GitHub Pull Request, confirming community alignment with spec changes.
• Detailed steps outlined in Annex 1.

Alternative B: First vote in the GitHub Issue

• First voting stage takes place in a GitHub Issue, confirming community alignment before detailed spec changes.
• Detailed steps outlined in Annex 2.

Comparison of Alternatives

Both alternatives address the identified governance issues in slightly different ways. Here's a summary of how each alternative addresses the key issues:

Identified Issue	Alternative A	Alternative B
First adopters impacted by last-minute changes	Solved: More visibility before implementation by early adopters.	Partially Solved: More visibility before a fully developed proposal.
Insufficient engagement in early stages	Partially Solved: Formalized ideation phase with open discussions.	Solved: Structured requirements for early-stage discussions.
High barrier to entry	Partially Addressed: Clearer process before the Pull Request.	Partially Addressed: Clearer process before the Pull Request.

Documents for review

Main body of work:

• Overview: Phase 2: Changes to Voting and Reviews

Attachments: Details and Clarifications:

• Annex 1: Alternative A Details
• Annex 2: Alternative B Details
• Annex 3: Roles and Review Guidelines

What's Next?

1. Review the Overview: Review the general overview and share your thoughts: Overview,

2. Deep dive: Dive deep into the attachments for details: Annex 1, Annex 2, and Annex 3.

3. Provide Feedback: Share your thoughts, suggestions, or concerns by commenting on this GitHub issue and/or in the respective documents mentioned above.

4. Save the date: On March 13, 2024, MobilityData will be holding 2 meetings to present each alternative, and hold a guided discussion based on the comments towards an eventual consensus. Register for one of the meetings below:

   • Meeting 1: March 13, 2024 @ 11 am EDT
   • Meeting 2: March 13, 2024 @ 8 pm EDT - Postponed, new date TBA

[skinkie]

What I am still missing is an 'adoption review' after for example one year to prevent private extension between two (and not all) parties.

[eliasmbd]

What I am still missing is an 'adoption review' after for example one year to prevent private extension between two (and not all) parties.

Increasing the voting requirements from 3 to 5 with a minimum of 2 Consumers and 2 Producers should help mitigate that and provide a more diverse set of perspectives.
@skinkie In Annex 3, you can also find a section on Transit Agency and Vendors. I'd like to know what you think about this.

[e-lo]

@eliasmbd I think I am still unclear about a few of the voting detail descriptions.

Replace the second vote with an 80% majority vote, restricting the -1 vote to the initial stage.

Wouldn't a -1 vote still be allowed by an individual ? It is just that a single one (likely) wouldn't sink the proposal.

[skinkie]

What I am still missing is an 'adoption review' after for example one year to prevent private extension between two (and not all) parties.

Increasing the voting requirements from 3 to 5 with a minimum of 2 Consumers and 2 Producers should help mitigate that and provide a more diverse set of perspectives.

It sounds nice but I don't think it should work like that. We need some initial parties to test something, to me that still can be 1 < n <= 2. That gives a technical analysis of a proposal. The adoption is a completely different matter.

[eliasmbd]

@eliasmbd I think I am still unclear about a few of the voting detail descriptions.

Replace the second vote with an 80% majority vote, restricting the -1 vote to the initial stage.

Wouldn't a -1 vote still be allowed by an individual ? It is just that a single one (likely) wouldn't sink the proposal.

@e-lo With a requirement of 5 votes and a 80% majority vote, a single -1 at the second vote would not sink a proposal. This reduces the risk at the later stage once efforts have been made by first adopters.

[eliasmbd]

What I am still missing is an 'adoption review' after for example one year to prevent private extension between two (and not all) parties.

Increasing the voting requirements from 3 to 5 with a minimum of 2 Consumers and 2 Producers should help mitigate that and provide a more diverse set of perspectives.

It sounds nice but I don't think it should work like that. We need some initial parties to test something, to me that still can be 1 < n <= 2. That gives a technical analysis of a proposal. The adoption is a completely different matter.

@skinkie Are you suggesting that a review should be held after a year of implementation has been made? Similar to the experimental field in GTFS-RT governance?

[skinkie]

@skinkie Are you suggesting that a review should be held after a year of implementation has been made? Similar to the experimental field in GTFS-RT governance?

I wasn't even thinking about GTFS-RT at this point. But now you bring it up: yes. I think this would be a really sound approach that allows experimentation and validation and clean up for stuff that does not get implemented.

[e-lo]

@e-lo With a requirement of 5 votes and a 80% majority vote, a single -1 at the second vote would not sink a proposal. This reduces the risk at the later stage once efforts have been made by first adopters.

I get that, but if you are still allowed to vote -1 on the proposal then the text is misleading. Suggest:

Replace the second vote with an 80% majority vote.

or

Replace the second vote with an 80% majority vote requiring unanimous consent only in the initial vote.

[e-lo]

Proposing changes to GTFS has been a cumbersome process, leading to delayed outcomes and uncertainties.

I am very concerned about adopting this (much heavier) process before making some of the small changes to non-normative content lighter first (example of a new issue where this would be helpful: #435 )

While some of these changes are good, I do think that the fact that I just had to read three documents of how this could work which were each many pages long could be argued to be a much more cumbersome process and would likely delay and make outcomes even more uncertain. If our primary goal is to make it less cumbersome...then let's start there and then add complexity where it is warranted.

[skinkie]

Proposing changes to GTFS has been a cumbersome process, leading to delayed outcomes and uncertainties.

I am very concerned about adopting this (much heavier) process before making some of the small changes to non-normative content lighter first (example of a new issue where this would be helpful: #435 )

I think you got me/us wrong then. Content changes should in my opinion have a regular editorial proces. 4 to 6 eye principe. But I would prefer a much heavier proces on extending a standard for the sake of extending. Don't think this would need a year of talks about for example fares, rather properly done and reviewed technical proposals and/or implementations.

[westontrillium]

I added comments on some specifics in the overview doc, but I'll also add some general comments here:

I'm interested in the prospect of actually just aligning the GTFS-Schedule amendment process to Realtime's process (e.g., the "adopted but experimental" phase). Has this been considered? It would also be easier to manage a single voting process for both...

I would also like to know if there are any plans in place for how we will evaluate the changes' effectiveness?

It may be a good thought exercise to take the events of a recent amendment to the spec and ask how would that have been different under these new processes? Would it have taken less time? More time? What pitfalls or pain points specifically might have been avoided?