[Governance] Phase 2: Enhancing Voting and Reviews about transit

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

[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

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

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

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.