Web conference notes, 2019.03.28

minutes, recording and transcript

Attendees

• Jascha Franklin-Hodge: Former CIO of the city of Boston, fellow at the Kennedy School working on mobility data issues, currently consulting with Remix on data strategy and helping LADOT bring more voices into the MDS Provider process
• Ryan Fitzgerald: Software Engineer on the New Mobility team at Remix
• Caitlin Colgrove: Engineering Manager on the Data team at Remix
• Lionel Panhaleux: Blue Solutions, using MDS as both a client and a provider
• Fletcher Foti: CTO of Populus
• John Pena: Lead engineer for GovTech at Lime
• Andrew Scherkus: Formerly part of the Jelly Scooters team at Ford, worked with a lot of open source data standards
• Kegan Maher: Data Officer for the city of Santa Monica, one of the earliest consumers of MDS, author of open source ingestion and validation libraries for MDS
• Marcel Porras: Chief Sustainability Officer at LADOT, overseeing dockless mobility implementation in the city of Los Angeles
• Hunter Owens: Senior Data Scientist, city of LA, one of the maintainers of MDS on Github
• Ambar Pansari: Product Manager on GovTech at Bird
• Marla Westervelt: Policy and strategy for GovTech at Bird
• Alex Demisch: Data Analytics Manager, SFMTA
• Mateo Clarke: Data in Tech division of city of Austin
• Roy Williams: Software Engineer at Lyft, built most of their MDS implementation
• Urban Radar

Agenda

• Intros (10-15 minutes)
• Quick process review, feedback, and questions (5-7 minutes)
• Goals for issue / PR discussion (2 minutes)
• Issue/PR triage and discussion (~5 minutes each)
  • #270 - Create standard way to designate intended milestone and API in issue subjects
  • #278 - Add event_type_reason codes to provider status_changes API
  • #268 - Discussion: make MDS queries more predictable
  • #273 - provider, agency: event timestamps
• Nominate issues for next week’s discussion and scheduling (5 minutes)

Follow up actions

• Github issues:
  • #270 - Jascha Franklin-Hodge to summarize discussion on issue, make PR for issue templates
  • #278 - Hunter Owens to follow up on issue with clarifying questions
  • #268 - John Pena to summarize discussion on issue, continue discussion there
  • #273 - Lionel Panhaleux to summarize discussion
• Rate limiting on the Provider API: Roy Williams to file an issue for later discussion

Discussion summary

• Welcome
  • 8 am PT will likely not be the standard time for this call. Goal is to find a consistent time but schedules are still being sorted out
  • Goal of these calls is for all of us to get to know each other and expand the group of folks working on MDS - we won’t always agree but we want to create a space to make some of these challenging decisions
• Process review
  • This process is a work in progress - there will be things to change and opportunities to give feedback
  • Last week (week of 3/25) was week 1 of the process: proposal week.
  • We’re in weeks 2-4 of the process, which is the work period. We’ll work through the issues people have submitted and try to come to consensus.
  • Week 5 will be about making final decisions and week 6 will be the release. 4/30 is the target release date.
  • We’ll have an in-person work session week 5 (week of 4/15), likely on the west coast. Stay tuned for more details.
  • This release is about smaller stakes changes to exercise the process so we’re ready to tackle some of the bigger issues in future cycles.
• Issue discussion
  • Goal for these issue discussions: we don’t have very much time, so the main goal is to get to a next step for each of the issues. Either a PR if there’s consensus, or a revision to the issue, or potentially a longer follow up call if necessary.
  • #270 - Create standard way to designate intended milestone and API in issue subjects
    • Background: people who do not have write access to the repo cannot add issues to milestones, but still need a way for people to indicate which part of the API it touches (provider or agency) and which release it’s targeting.
    • Final decision: use a Github issue template with checkboxes for breaking/non-breaking/unsure, and provider/agency, since it’s easier for people new to the repo to understand the process than a title naming-scheme.
    • There is a related discussion on what exactly constitutes a breaking change, but that was deferred for a later conversation.
  • #268 - Discussion: make MDS queries more predictable
    • Background: Lime has seen a 10x increase in the number of MDS requests since February. To handle the volume, they’d like to be able to cache or precompute common queries, especially since most queries are bounded by the hour or day.
    • There were a number of suggestions both for changing the API and for optimizing the computations on the provider side. Those have been documented by John on Github. The discussion will continue on the Github issue.
    • Related concern from Lyft: when people have bugs they sometimes DOS the endpoints, but that will be followed up on in an upcoming discussion.
  • #273 - provider, agency: event timestamps
    • Background: Two main issues here 1) deduplicating between provider and agency events, and 2) making sure that simultaneous events were processed in the correct order such that the vehicle ends up in the proper state at the end (e.g. available vs unavailable)
    • The first problem has to do with agency so that discussion was tabled because it requires a different set of people in the conversation, and this call is focused on provider.
    • For the ordering issue: ordering by time is unreliable for many reasons (clock skew, connection issues), and so if we want a stable ordering of events, we should have a separate “sequence id” that can be guaranteed to be monotonically increasing.
    • The conversation will be moved to Github for further discussion.
  • #278 - Add event_type_reason codes to provider status_changes API
    • This one generally seems reasonable (agency already has one of the event types) but there were some clarifying questions about the technical feasibility so we’ll follow up on Github to get those answered.