Web conference notes, 2022.02.03 (MDS Working Group)
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
- Michael - first pass at Modes PR
- Policy Use Cases: Add and capture these question to help with prioritizing work
- Why is this needed?
- Why should this be included in Policy?
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
- 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
- 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
