minutes, recording and transcript

Attendees

• Mark Maxham, Ellis & Associates
• Alex Demisch, SFMTA
• Kegan Mahar, Santa Monica
• Chris Raastad, Bolt Mobility
• Caitlin Colgrove, Remix
• Ryan Fitzgerald, Remix
• Dmitriy Yakovlev, Remix
• Bill Dirks, RideReport
• Max Arnell, MIT
• Ambar Pansari, Bird
• Lionel Panhaleux, BlueSystems
• Mark Stosberg, Ride Amigos
• Geoffrey Bir, Urban Radar
• Mateo Clarke, Austin

Agenda

• Quick intros, if we have new faces (5 minutes)
• Review of next steps from last meeting (5 minutes)
  • Completed issues (#270 and #278)
  • Sequence ID/timestamp uniqueness issues
• Issue/PR triage and discussion (5-10 minutes each)
  • #123 / #76 - Add membership type field / Access method
  • #293 - Add versions endpoint
  • #289 - Add an associated trip id to status changes when a trip ends
• Discuss release process for 0.3.1 (5-10 minutes)
• Talk about communication channels (5-10 minutes)

Discussion summary

• Two issues - #270 and #278 have been merged. Good team effort!
• Sequence ID / timestamp issues
  • There have been a lot of discussions on what to do here, but it’s too much for the short weekly call.
  • We’re going to use this opportunity to try a new process: dedicated working group with a separate call who will come back with one or two proposals for the group.
  • Volunteers: Bill, Lionel, Ambar, Chris, Kegan. Caitlin to coordinate.
• Issue discussion
  • #123 - Add membership type field and #76 - Access method
    • Background from Alex: trying to understand how many trips are taken on the low income plan. This is a change that they’ve made on their own fork of MDS.
    • Two main concerns with doing this: 1) enum fields are tough because it’s hard to represent optional fields in the current spec and 2) this is additional user-identifying information and it’s not clear if that’s a problem.
    • Follow ups: Alex to document on github, also requires follow up on how to handle enums fields.
  • #293 - Add versions endpoint
    • Background from Bill: there are currently no mechanisms to know what versions a provider supports.
    • Discussion: making this optional seems reasonable, but this belongs in the OPTIONS request rather than a separate endpoint.
    • Follow up: Bill to modify open PR to use headers
  • #289 - Add an associated trip id to status changes when a trip ends
    • Background from Bill: sometimes trips end for something other and a user drop off, and the vehicle enters an unavailable state rather than an available state. This transition is not easily supported by the spec.
    • Discussion: there are a couple options to resolve this:
    • Add an explicit transition from on trip to unavailable in the state machine
    • Allow an optional associated trip id on certain event type reasons for unavailable states
    • Use sequence id / event ordering to model this using multiple events with the same timestamp
    • There wasn’t enough to decide between the options, but Caitlin will follow up to continue the discussion on Github.
• Release process
  • 0.3.1 will follow the current release process one more time to ensure the git branches are in a consistent state. The process will be as follows:
  • All PRs for this release to be made against the 0.3.x branch
  • To release, we will merge 0.3.x into master and tag that as 0.3.1
  • Then, we will rebase develop on master to reconcile the git history
  • Look for some slight modifications to the process for the next release (PR will be made with process changes)
• Communications channels
  • Motivation: we have a lot of conversations on these calls that we don’t quite have time to finish. It would be good to have a place where we can have conversations between calls.
  • Proposal: have a shared Slack or Gitter, or potentially have two calls, a logistical one and a technical one.
  • Follow up: Caitlin will investigate setting up a channel.
  • Potential for in-person communication: we won’t be doing it this cycle, since it’s difficult for people to travel. But let us know if you’re interested - there may be opportunities in the future.
• Nominations for next week
  • #288 - Include version number in README