minutes, recording and transcript

Attendees

• Mony Patel, LADOT
• Caitlin Colgrove, Remix
• Ryan Fitzgerald, Remix
• Dmitriy Yakovlev, Remix
• Ambar Pansari, Bird
• Bill Dirks, RideReport
• Geoffrey Bir, Urban Radar
• Alex Demisch, SFMTA
• Hunter Owens, LA
• Andrew Scherkus, Ford
• Lionel Panhaleux, BlueSystems
• Kegan Maher - Santa Monica
• Fletcher Foti - Populus
• Jascha Franklin-Hodge - Remix

Agenda

• Quick intros for new faces (5 minutes)
• Working groups and communication channels update (2 min)
• Issue discussions (5-10 minutes each)
  • #288 - Include version number in README
  • #123 / #76 - Add membership type field / Access method (follow up)
• Review potential candidates for 0.3.1 release and assign follow ups (5 min each)
  • #289 - Add an associated trip id to status changes when a trip ends
  • #279 - Clarify breaking vs non-breaking changes
  • #288 - Include version number in README
  • #293 - Add versions endpoint
• Branching process for 0.3.1 (5 min)

Follow up actions

• Release process
  • Caitlin will collect everything into final release recommendation
• Issue discussions
  • #288: Hunter will update README, Ryan will update release process
  • #123 / #76: Caitlin will schedule working group follow up
  • #293: Lionel to follow up with explanation on PR, Bill to finish up

Discussion summary

• Communication channels update
  • Slack/Gitter options being investigated by LA for compliance considerations
  • Until then, Github/email will be preferred communication channels
• Working groups
  • Status change ids working group email went out - time will be scheduled week of 4/22
• Issue discussions
  • #288 - Include version number in README
    • Background: It’s often confusing when you open up the repo about what version this is. The default branch is develop, but that’s not the branch you should be consuming or implementing.
    • Having master be the default branch is not desirable because then all new PRs get opened against master by default.
    • Conclusion: we’ll start with the easy thing and move forward with adding this to the README. But we should add this to the release process to make sure it gets updated.
  • #123 / #76 - Add membership type field / Access method (follow up)
    • Background: These were brought up by Alex at SFTMA for equity analysis
    • Two main unresolved questions: we’re collecting additional information from the user so we need to be thoughtful about that, and also there are a bunch of technical questions about how to do enums in the spec - are changes breaking? Can we iterate faster than every 6 weeks?
    • Another issue raised was that providers may be tracking this information separately for general equity reporting.
    • Next action here is to have a separate breakout group to answer the open questions and come back with a proposal.
• Review potential candidates for 0.3.1 release and assign follow ups
  • #293 - Add versions endpoint
    • All in agreement that this should be an OPTIONS request. Some discussion about whether or not we may already have this for free given that the content type should contain the version number starting with 0.3.
    • Lionel and Bill to follow up on PR.
  • #289 - Add an associated trip id to status changes when a trip ends
    • Background: we want to make sure we have a valid transition from trip end to the unavailable status, e.g. if a scooter runs out of battery. The minimally invasive change that we had suggested was allowing an optional trip id on those status change events.
    • No schema change is required here since this is optional, so we can just add some clarifying text to make it clear that this is allowed.
    • This has also been tagged with the “state machine” tag as a record for historical purposes to see which issues were related to state machine questions. But that’s a larger conversation and not for this release.
  • #279 - Clarify breaking vs non-breaking changes
    • Not actually a change - consistent with language in the issue template. Just provides some clarifying examples.
    • Enum values are kind of an open question since it’s possible for them to be breaking, but the sense from the room is that enum additions should be non-breaking.
    • Leave comments on PR if there are further questions.
• Branching process for 0.3.1
  • We should just move to the new process for this release. Originally we thought that the branches were in an intermediate state but they’re not, so we can just cut over now.
  • #294 documents new release process and has been merged.
• Next release: 0.3.2 or 0.4.0?
  • Consensus: people are just now starting to implement 0.3.0, so we still don’t know what issues the 0.3.x series will have. We should let it sit in production for a while before making major changes.
  • But if something comes up that needs to breaking, we can always make a call later in the cycle and go with 0.4 instead.
• 0.3.1 release
  • Release date: 4/30
  • Caitlin will write up final release recommendations (but it sounds like there’s already consensus on all the issues going in)
  • Hunter will give final approval to release