minutes, recording and transcript

Attendees

• Jascha Franklin-Hodge, Remix
• Max Arnell, MIT
• Hunter Owens, City of LA
• Mark Maxham, Ellis and Associates
• Geoffrey Bir, Urban Radar
• Bill Dirks, RideReport
• Evan Costagliola, Lime
• Andrew Scherkus
• Fletcher Foti, Populus
• Caitlin Colgrove, Remix
• Dmitriy Yakovlev, Remix

Agenda

• Quick intros, if we have new faces (5 minutes)
• Review of next steps from last meeting (5-10 minutes total)
  • #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
• Issue/PR triage and discussion (5-10 minutes each)
  • #279 - Clarify breaking vs non-breaking changes
  • #255 - Update MDS / MDS-Provider to support multiple modes
  • #281 - Use OpenAPI to define Provider API request shapes and query parameters
• Nominate issues for next week’s discussion (5 minutes)
• Planning for next major release (10 minutes)

Follow up actions

• Github issues:
  • #270 - Jascha to tweak PR. Will merge when done.
  • #278 - Agreed on path forward. Hunter to create PR.
  • #268 - Push to 0.4.0. John Pena to summarize discussion in GitHub
  • #273 - Hunter to wrangle and link all related issues in GitHub. Discuss this and other “state machine” issues on side channel/at in person meeting
  • #279 - Hunter to write up thoughts on GitHub for online discussion.
• related to #279 - Bill Dirks to create issue related to the need to query supported API versions
  • #255 - Jascha to summarize discussion in GH. Plan for future bigger discussion, with target of a major release.
  • #281 - Dmitriy to do additional research about OpenAPI use for part of an API spec and report back with examples.
• Rate limiting on the Provider API: Roy Williams to file an issue for later discussion

Discussion summary

• Issue review (from last meeting)
  • #270 - Pull request for issue / PR templates in (#286). Will refine language, update relevant sections of CONTRIBUTING.md and ReleaseGuidelines.md, then merge for 0.3.1.
  • #278 - Received additional clarification from Seattle DOT. They will have a backend way to trigger a vehicle unlock with the provider (mechanism TBD), but this should allow for the city unlock to be reported in the MDS feed. Hunter will do a PR.
  • #268 - Emailed note from John Pena:
    • My suggestion (as mentioned in the github issue) is that we punt on a solution until 0.4.0. I have some suggestion that I will write up in the issue. If anyone wants to discuss this more, let's do it through the issue and revisit when we start talking about 0.4.0.
  • #273 - This is one of a series of issues related to the “state machine” of vehicle status. Probably a bigger topic that requires input from more stakeholders, given that it impacts everyone producing or using data. Hunter to try to link all the related issues together in GitHub. Future discussion needed, likely on side channel or in person.
  • #279
    • Background: Definition of breaking/non-breaking different in an API compared with a traditional user-facing product. Is breaking just when something breaks for the API consumer? Or, is it also when a spec change necessitates the API producer change their code as well?
    • Current thinking is that a breaking change is one that breaks the consumer client or requires mandatory changes from the implementor of the API.
    • Version parameter offers something of an “escape hatch” for the producer of an API. It’s not breaking for them if they can continue to return an older version response.
    • Need to clarify guidelines for how long old versions are supported
    • Also need to create a mechanism to know what version(s) a particular endpoint implementation supports. Could be done through a centralized mapping effort or via a query mechanism on the end point.
    • [No provider representation on the call at this point. Need to have their voice at the table.]
  • #255
    • Background: Dockless mobility is just one mode intended to be covered by MDS (eventually). For example, car share, taxi data, etc. This is an “opinionated” proposal for a folder structure to allow multiple modes in MDS.
    • Lots of discussion of the need to prevent a profusion of incompatible/overlapping APIs within the MDS spec as new modes emerge. Discussion notes added to GitHub.
  • #281
    • Background: Query parameters and headers are defined in a narrative way, rather than a machine-readable way. Leaves too much up to interpretation and makes automated validation difficult. Propose to use OpenAPI to more formally define this aspect of the spec.
    • Agreement that we would benefit to have something machine-readable and clearly defined.
    • Concern as to whether OpenAPI is the right tool, especially if we’re only using it for a subset of the spec. Need to research if that’s even possible/practical.
    • Having a more robust automated test suite could be part of the solution.
    • Strong bias towards maintaining a low barrier to entry to use/understand/contribute to the spec, especially for cities.
• Issues nominated for next week
  • #123 (related #76)
  • #288
• Potential topics for next major release
  • Provider internal representation of what vehicles are or are not on the street is very different from what you can extrapolate from status_change. How we can reduce the number of vehicles that “go dark” from the perspective of status_change? A lot of different implementation possibilities. Need to discuss w/ both consumer and providers. Issue #67.