MDS Working Group

• Every other Thursday at 9am PT / 12pm ET / 6pm CET

Zoom Registration Link: https://us02web.zoom.us/meeting/register/tZAscOmhpjIuHNakPx6CNbACpjUjw1Gsucr4

One tap mobile: +19294362866,,84170989462#,,,,*612987# US (New York) - though we encourage Zoom

Note: Attendees register upon entry into the Zoom meeting. An attendee count will be posted here after the meeting:

17 attendees

Main Topics

• Kickoff - Sébastien Berthaud, Blue Systems
• Summary based on last meeting - Michael Schnuerle (OMF)
• MDS Task Force recruiting - Michael Schnuerle (OMF), Angela Giacchetti (OMF)
• Task Force Status and Next Steps - Task Force Members
  • Modes Architecture Task Force
  • Policy Reimagining Task Force
  • Unification Task Force

WGSC Meeting Organizers

• Host: Sébastien Berthaud, Blue Systems
• Facilitator: Michael Schnuerle, OMF
• Outreach: N/A
• Note taker: Jean Kao, Populus

1. Michael - first pass at Modes PR
2. Policy Use Cases: Add and capture these question to help with prioritizing work

• Why is this needed?
• Why should this be included in Policy?

• Slide presentation

Have reviewed with WGSC and other OMF committees and will bring some possible ideas to a future WG meeting.

1 Ease MDS implementation

What’s in place:

• Some open source tooling, but it’s unsupported
• Have 2 open source projects in OMF org, though not actively maintained, have some traction again
• Maintain list of any community open source tools available
• Implementation Slack channel for members, though not used much

2 Increase adoption of recent MDS versions

What’s in place:

• MDS Versions webpage as resource
• Language samples for how and when to upgrade
• Officially deprecating old versions
• Clearly list benefits of upgrading
• Feature the highlights of each release
• Social media/blog/webinars before and after release, additional focus on features

3 Commitment to real world use of new features

What’s in place:

• MDS features only get added by community members intending to use
• Have some orgs commit to using (eg Requirements, Metrics, Provider Reports)
• State of MDS survey: shows use of newer versions and APIs more than we can each individually see

4 Refine not expand MDS

What’s in place:

• MDS features only get added by community members intending to use them
• Expansion for 2.0 is only from real-world use case needs and current implementations which have created ‘variants’ outside of MDS:
  • New modes in use already. Cities/companies working to incorporate
  • Policy updates are focused on making it clearer and easier
  • API unification aimed at making implementation & understanding easier

5 Continue focus on provider participation

What’s in place:

• Have 3 providers as OMF members who are active in the community and leadership roles
• Additional providers active in public Working Group meeting and providing feedback on OMF products like releases, GDPR guidance, etc.
• Benefits for provider participation are well documented and the OMF engages with prospective members and participants regularly

• Alex Demisch (co-lead)

  • Top down approach - architecture white paper
  • Bottom up approach - some work with taxi, sidewalk robots, carshare
  • participation from people who have worked on MDS with all three modes to drive adoption

• Sanjiv (co-lead)

  • want to elicit input based on implementations that have already occurred with other modes
  • continue to revisit architecture paper
  • back/forth to make sure architecture maintains or find out where it constrains

• Michael (OMF)

  • if we can get over hurdle of how do we add new modes then can get into details of each new mode
  • we have enough info to take a first pass at the architecture
  • get pull request to start convo on what framework is going to come
  • take what’s in technical documentation and put it into spec
  • see wiki link to review work done so far and comment

• Seb (co-lead)

  • mission: increase adoption by a) cover all main use cases, and b) simplify and make sure it’s easy to implement
  • next steps
    1. Creating right participation group
    • want to make sure cities are represented, SFMTA, DDOT, want a few more cities
    • everything is for adoption so want operator feedback as well
    2. Which use cases matter

• Sanjiv

  • Do cities expect operators to implement the policy API
  • Seb: some cities are asking for this
  • In addition to documenting use cases somehow capture value or why, why digitally instead of manually
  • Seb: solve for key uses, reason for policy and reason for implementation
  • 2 reasons, accuracy, dynamic nature
  • Seb: if hard to implement from operator maybe it’s the bottom of the list

• Marie (lead)

  • Provider conceived as historical database
  • Agency build in parallel more of a real-time active management
  • some discrepancies between them, some resolved in v1.0
  • shape of API, some fields, some things missing
  • mission: rest of cleanup, APIs should be symmetrical so that they work mostly the same
    • push vs pull
    • cities can implement what makes the most sense but the implementation is the same
  • goals
    • full data parity so both APIs can cover same use cases
    • document design decisions
    • straightforward to implement
    • don’t want to cause any migration headaches

• Michael (OMF)

  • traditionally cities have to choose either provider or agency
  • now a number of cities are using both, provider to get historical data to do analysis, agency to do more dynamic management
  • by unifying will be less of a burden on both

• Todd Petersen: how does API Unification intersect with taxi work at LA?

• Marie: main driver at LA is to be able to implement use cases around taxis that needs trip data - in provider but not available in agency

• ideal taxi companies are sitting here with us instead they’re being reactive

• having to act as proxies because they aren’t here

• Sanjiv

  • when proposing taxi for LA are you thinking agency or provider?
  • Marie: could be either but initial implementation will be agency