[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?

[eliasmbd]

I'd like to remind everyone here that we will be holding 2 meetings on these changes on Wednesday.

This is the agenda of the meeting:

1. Presentation of the proposal and it's alternatives (20 minutes)
2. Guided discussion around alternatives by focusing on your comments and feedback.
   @skinkie @e-lo @westontrillium We will cover your comments in the meetings as well, so your presence and participation would be greatly appreciated.

To allow for global participation, we have the same meeting for 2 sets of timezones.

Here are the 2 options:

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

[eliasmbd]

Just a quick update on the 8pm EDT meeting. We decided to postpone it for a later date to ensure a more diverse attendance. The intention of that meeting was to include voices from the Asian-Pacific and Australian Timezones. The date will be announced as soon as we set up another meeting.

[eliasmbd]

Working Group Meeting Announcement

We will be holding our first Working Group Meeting on the subject of Governance on May 2nd @ 11AM EDT

We will build off of last meeting's discussions and focus our discussions on the smaller items. We will try to build concensus on one item at the time.

We will be using Miro for this meeting. We also have a Working Group channel on the MobilityData Slack.

Let us know if you can't make it. We plan on providing asynchronous options like recordings.

To sign up click here

Join the MobilityData Slack to be included in the working group channel.

[eliasmbd]

WGM Annoucement

Thanks for joining yesterday. Your inputs were very helpful to get some major questions behind us. As discussed, we will be hosting bi-weekly meetings at first and then transition to a monthly format once proposal writing begins. We anticipate 4 bi-weekly meetings with the objective to achieve consensus on 2 or more goals outlined in the screenshot below. We hope next meetings will be more solution oriented rather than a philosophical discussion on the bigger questions.

Here is the link to sign up to the next 2 meetings
Eventbrite Page

The next 2 meetings will be held on: May 16 @ 11AM EDT and May 30 @ 11AM EDT

Join the MobilityData Slack to be included in the working group channel.

[eliasmbd]

Unfortunately, we didn't have enough people at our last meeting to proceed, so we decided to postpone it. We want to make sure everyone's voices are heard and that the opinions reflect the diversity of GTFS stakeholders.

In our next meeting, we hope to dive deeper into the proposed solutions and agree on how to tackle each highlighted issue. We hope to find consensus on at least 2 solutions for the following items:

1. Formalizing the process before the Pull Request
2. Reducing Risk for First Adopters
3. Bring more visibility early in the process
4. Make the process smoother / faster
5. Make things easier for non-technical people
6. Bring more contributor diversity
7. Reduce the amount of proposals hanging out in proposal stage

If consensus is found on 2 items and we still have time we can cover other items on the list. As you will see, many solutions to the items above can overlap making each discussion essential to the overall result.

The next meeting will be on Thursday, May 30, 2024, at 11:00 AM (EDT).

Please use the Eventbrite link to register, this is important for us as it helps us track the estimated attendance and anticipate any potential setbacks.

If you have trouble registering, please reply to this email, and we'll send you the Google Calendar link.

Thanks for confirming your attendance. Let us know if you can't make it.

We appreciate your contributions and hope to see you at the next meeting.

[eliasmbd]

📣📣📣

The next WGM will be held on August 8th, 2024 @ 11:00 AM (EDT)

Reach out to me either here or on slack to receive your calendar invite. We will continue to use Google Calendar for this WG as it seems like the best solution for everyone.

This might be our last meeting.

We will visually recap our current solutions, address the discussion held in the last meeting, and then we will be covering priority item no.6:

1. Formalizing the process before the Pull Request (Discussed)
2. Reducing Risk for First Adopters (Discussed)
3. Bring more visibility early in the process (Discussed)
4. Make the process smoother / faster (Discussed)
5. Make things easier for non-technical people (Discussed if time allows)
6. Bring more contributor diversity (Priority)
7. Reduce the amount of proposals hanging out in proposal stage (Discussed if time allows)

If consensus is found on item number 6, we believe that MobilityData would have sufficient information to begin work on the proposal. If time allows, we will try to cover items 5 and 7. The solutions in items 5 and 7 are very similar to previously discussed ones and may lead to redundant conversations. Item 6 on the other hand directly influences the implementation of the most complex solution: voting changes.

As this may be the last meeting before beginning to draft the proposal, please let us know if you can't make it.

[eliasmbd]

Outcomes of Working Group Meetings

Overview

As discussed in our most recent Governance Working Group Meeting, several important changes to our governance process have been agreed upon by the working group participants. Below is a summary of the key changes, including features that were set aside for future consideration, and the next steps for implementation.

Key Changes

Change	Description	Justification
1. Improve Governance Documentation	• Include visualizations of the process. • Clearly define roles.	• Makes documentation easier to follow for newcomers. • Provides clarity on who is a consumer, producer, advocate, vendor, contributor, etc.
2. Formalize Semi-Structured Phase Before PR	• Officially incorporate an "issue phase" reflecting current practice. • Maintain low access barriers, allowing easy proposal submissions without requiring data modeling. • Provide suggestions / guidelines on how to guide discussion and structure proposals.	• Community preferred this flexible approach over a more rigid structure.
3. Require a Proposal Schedule	• Add a requirement to specify if the change is "big/long" or "small/quick" when creating a proposal.	• Helps the community gauge the effort required and manage expectations during the review process.
4. Define Discussion and Review Period Length	• Define specific time periods for Discussion and Review phases. • Might require splitting the Discussion and Review periods.	• Clear separation between discussion and review phases ensures predictability. • Maintainers will check for language consistency, and contributors can review technical aspects.
5. Implement a Vote Before Testing	• Implement a new voting period to validate changes after review and move forward with testing. • This vote becomes the "most important" to test appetite and gather potential first adopters. • Veto power will remain for this vote.	• This change addresses the need to confirm broad community support before significant testing begins. • The vote serves as a checkpoint to ensure that the changes have enough backing, reducing the risk of investing resources into changes with limited interest. • This step was chosen over the idea of forming a review committee or holding an earlier vote at the issue stage due to concerns about efficiency and practicality.
6. Increase Voting Requirements	• Increase minimum votes required from 3 to 5. • Require a minimum of 2 Producers and 2 Consumers to vote.	• Reflects GTFS's mature stage, promoting a stable process and increasing the quality of changes. • Reduces the risk of changes being pushed by a small group of stakeholders.

Future Consideration

During the meeting, some features were set aside for future consideration:

• Creating a lightweight process for Clarifications and Editorial Changes:
  • Formalizing Clarifications and Editorial Changes by removing elements of the proposed changes above might help implement smaller changes quicker and more efficiently all while ensuring quality and stability of the specification.
  • Provide clarity on qualifying changes types by defining them (Large vs. Small changes, Normative vs. non-normative, and / or Additions, vs. Editorial, vs. Clarification)
  • Might be the next step after the completion of the first draft of this proposal
• Increasing Implementation (Testing) Requirements for Significant Changes:
  • It was proposed to require testing by a minimum of two Consumers and two Producers for larger changes. This would ensure new features are thoroughly tested and more widely adopted before being fully integrated.
  • Was mentioned as a backup plan to reinforce feature adoption by GTFS users.
• Removing Google Groups Requirement:
  • The group did not reach a consensus on removing the Google Groups requirement. Alternatives like different announcement platforms are still under discussion.
• Merging GTFS Schedule and GTFS Realtime Governance Processes:
  • There was general support for merging these processes, particularly around handling the Experimental field. While not implemented immediately, this is seen as a valuable future improvement.

Next Steps

• Proposal Drafting: Drafting the proposal by MobilityData is expected to begin by the end of Q3-2024 (September 2024).
• Presentation: The proposal is expected to be presented to the community at the beginning of Q4-2024 (October 2024).

Please feel free to comment below if you have any questions or need further clarification on these updates.

Thank you for your continued participation and support.

[e-lo]

The past several governance WG meetings have been at times I've had rigid conflicts with, so apologies for chiming in after this has gotten to this stage. I really appreciate the follow through and level of documentation that you've done on this, @eliasmbd !

I have a few concerns and a few remaining clarification requests...

Needing Clarification (at least for me!):

1. Does anything change with the existing vote into the spec? Does it still require a unanimous decision?
   Small Suggestion: Rather than calling thing "veto" which usually refers to a single person holding that power, it might be more clear to call the voting requirement "unanimous"
2. I'm not sure what the "testing period" contains. It doesn't seem well-defined w.r.t. who is responsible for doing what and what would trigger its conclusion. Is it when its been implemented by one producer and one consumer?
3. What happens if/when a change need to be made to the proposal that already passed the initial vote?

It might be useful if in the documentation we go thru a hypothetical example of a smaller change and a larger change.

Concerns:

1. I understand how the initial vote reduces the risk for first adopters. My concern is about how we navigate the potential evolution of the proposal that happens in the testing phase...where a lot of clarifications and changes are often made b/c implementation adds a lot of clarification.
2. I am really worried about how this entire process sounds very daunting and probably goes counter to two of the larger goals of this which was to increase the diversity of contributors and make things less difficult for non technical people. Requiring more steps and more technical people's involvement seems to be going in the opposite direction.
3. I don't understand the benefit of increasing the voting requirement for two producers and two consumers - is there a historic issue with things passing that shouldn't have?

[westontrillium]

Just chiming in to second all of @e-lo's clarification points (especially moving away from the wording "veto").

Regarding concern # 2, I view the proposed process as adding some order to what can often be a chaotic and impenetrable process. The hypothesis I've been running with in my head is that with a visible, formalized structure to how an idea becomes part of the spec, and with a clear understanding of what stage a given proposal is on in that process, newcomers would be equipped with the context needed to know the kind of contributions that would be most useful for that time.

Regarding concern # 3, requiring more than one producer/consumer for the vote makes sense to me so that consensus is more "triangulated," less unilateral, potentially.

[eliasmbd]

Thanks for your thoughtful feedback, @e-lo! I appreciate you taking the time to share your concerns and suggestions. We understand that scheduling is challenging at times.

Clarifications:

1. Voting Requirements
   The existing vote into the spec still requires unanimous decision—nothing changes here. The main addition is the need for a minimum of 5 votes, with at least 2 from producers and 2 from consumers. This helps ensure broader consensus while maintaining the unanimous requirement. We agree with your suggestion to replace "veto" with "unanimous"—we'll make that adjustment in the proposal.

2. Testing Phase
   The testing phase is the same as the current implementation phase, so no new responsibilities or processes are being introduced. It's simply a period where the proposal is tested by at least one producer and one consumer, allowing for real-world testing and adjustments when needed. We'll make sure this is clearly defined in the documentation.

3. Changes Post-Vote
   To clarify, we’re not introducing any new processes here—there has always been flexibility to make necessary changes after testing. The only addition is an extra layer of review, where changes can be checked against the initial supporters from the first vote to ensure we’re still on track. This is meant to maintain alignment with the original intent.

4. Hypothetical Examples
   We plan to include hypothetical examples in the proposal to illustrate how changes would be handled. We can explore the inclusion of these examples in the final documentation as we move forward, ensuring that they add clarity without introducing unnecessary complexity.

Concerns:

1. Testing Phase Evolution
   The first vote confirms that the change is ready for testing. The testing phase is primarily about validating the proposal through real-world implementation. While corrections are possible and likely to happen, the focus is on testing to ensure the change meets the agreed-upon requirements.

2. Process Complexity
   We recognize that the process may seem daunting, especially as it's currently written. However, as @westontrillium mentioned, formalizing these steps and visualizing the process should actually increase accessibility. A clearer structure with visualizations should help newcomers and veterans navigate the system more easily, even if it introduces some complexity at first glance. It’s important to note that we’re formalizing and categorizing some processes that are already in use informally, making them visible to those who haven’t been directly involved in them beforehand.

3. Increased Voting Requirements
   Requiring votes from multiple producers and consumers increases voter diversity and ensures the quality of changes. As @westontrillium pointed out, this helps achieve a broader consensus, making decisions less unilateral and more stable. Past votes have shown that this is not an unreasonable requirement, as the vote count has often met or exceeded this threshold.

@e-lo, this approach reflects the feedback we’ve gathered from the WGMs and the community. We’ll begin drafting the proposal based on this collective input, but please know that we remain open to making adjustments if necessary. As we move forward with drafting, there will be further opportunities to participate and provide feedback to ensure the proposal is solid, fair, and well-received.

Lastly, I’d like to invite anyone who participated in the WGMs to confirm or share their thoughts on this approach. Your input is invaluable as we refine this proposal.