Web conference notes, 2021.02.11 (Joint Working Group)

Joint Working Group - Provider Services

#red NOTE NEW TIME TWO HOURS SOONER #red

#red NOTE NEW ZOOM MEETING ID/LINK/PHONE! (as of Jan 1, 2021)

Meeting ID: 841 7098 9462 - Passcode 612987
https://us02web.zoom.us/j/84170989462?pwd=WTRlY25wOVhNeS8wQk1iM2QzYkQvUT09

One tap mobile: +19294362866,,84170989462#,,,,*612987# US (New York)

Dial by phone: +1 929 436 2866 (US) (Find your local number)

Attendees

Add your own name, link, and organization during call

Main Topics

Next release as a minor release
Slowing down pace of release changes to reflect on what's successful and what needs more attention
Review of items marked as beta
MDS version survey that OMF is working on

Notes and or transcript of the call with presentation, document, GitHub links and calls to action.

Next release: Minor 1.2.0

Requirements - New API for agency to describe a city’s MDS requirements digitally (though maybe big and for 2.0)
Modes - Support for new vehicles/modes/services since there is demand/need and it's in use now
Policy - Additions to Policy that could support more digitization of city permit policy requirements (though could be over engineered)
Housekeeping - Revisit and streamline features: authorization documentation consistency (breaking?), more examples, Agency trips, beta features review
- Non breaking updates
- Quality of life additions, focus on making MDS more valuable
- Add more examples for everything in MDS
- Create more MDS documentation
- Go back to things we've done to close loop on learnings

Release Cadence

There is a tension between wanting to be slower with releases and focus on what is happening today, versus a desire to support more modes and future features.
Some providers, third parties, and cities have not upgraded for various reasons.
Europe seems to be leapfrogging since they are sometimes just getting started with MDS: 1.0.0, Agency, Policy is being used organically.
Even though release pace is slowing, the releases are more complex
Minor release still have complexity - non-breaking does not mean non-trivial.

OMF Strategy Ideas

Make the adoption of new releases of MDS easier
Slow down to learn from what we've done
Focus not just on the spec but entire MDS package
Communicate we want people to move off of MDS 0.2, 0.3, try to upgrade to 1.0 where possible
Reduce version spread for collective benefit
Reframe value/benefits of new releases
Clarify and document the effort required to upgrade between specific releases

Survey

OMF is working on sending out a survey to agencies, providers, third parties (members and non-members) to see:
- What versions they are on
- What APIs/endpoints are being used
- Challenges with upgrading
- What OMF resources would be most useful
Working with the OMF Strategy Committee on this.
Regular survey of the MDS landscape to track progress and report improvements over time.
Survey can help grow use case database
Survey question ideas - asking about benefit of upgrading. What are the plans for the next 3-6 months for version support. What features are you looking to add with upgrading? How are you using MDS for policy? Reasonable frequency for major/minor release?

Policy Discussions

What is a space for city policy discussions for MDS development, when the WGs are technical?
OMF is structured so the Working Groups are where the most technical discussion happens, and the WG Steering Committees focus on the policy and direction of the releases. The OMF Staff summarizes this for Technology, Privacy and Strategy committees which can ask for more details and clarifications or meetings, before the Board is presented with relevant points for them to consider. OMF member orgs are invited to participate at any and all levels, and the community of non-members has many chances to engage as well along the way.
Josh - Policy needs to lead the technical discussion. Use cases should lead the discussion, not be split. 2 WGs (policy and tech) might be bad.
Maybe keep the tech/policy folks together. Two phases in a meeting, policy then technical. City policy makers would be engaged first, keep tech people together too and listening to the policy needs.
Maybe solving a policy need for a city, but not for lots of cities.

New features and beta

Is solving a policy need in MDS for one city enough, if it's not immediately useful for multiple cities? Consensus is yes if there are two parties involved in using the change.
Angela: Theme is balance between speed and features. Solution is not one thing, addressed on a variety of fronts.
Current things marked as beta:
- Provider: Vehicles (0.4), Stops (0.4)
- Agency: Stops (0.4)
- Policy: Rates (1.0)

Cities updating MDS permit requirements

When are cities updating their regulations? Flexibility to do it is there, but it's not done frequently.
Mitch: Annual is common. Seen requiring upgrading within 6 weeks (maybe too fast) for GBFS. MDS recommends 6 months for major releases - note there is knowledge of the release timing and features 2-4 months before release.
It's hard for a city to have a regulatory component to have providers test out new features before they are in MDS. It's different than GBFS and MobilityData where they require the feature to be in the real world first with producers and consumers.
Beta features - OMF says these are things we are working on, but no incentive to try them out and give them feedback.
Josh: maybe ad hoc beta features are harder to implement for lots of cities before they are in the spec.
GBFS has longer release cycles, borrowed requirements from GTFS history. And GBFS is simpler than MDS.
Mitch: currently slowing down release cycles, but the frequency is variable based on features and need.
Survey idea: reasonable frequency for major/minor release.
Providers may not be able to proactively upgrade despite knowing about the changes months beforehand. But they can at least prepare and roadmap it knowing it's coming.
OMF can sit in the center and have a shared understanding of the players to create collective recommendations.