The changes below are recommended for inclusion in the 0.3.1 MDS release, scheduled for April 30th.

This process was announced on March 18th. Since then LADOT, Remix, and many other organizations have participated in web conferences and worked in GitHub on this release. Some highlights:

• More than 20 participants from across the MDS ecosystem, including cities, providers, software companies, independent researchers, and non-profits.
• Four web conferences that have facilitated substantive discussion on complex issues affecting MDS. Meeting minutes: 3/28, 4/4, 4/11, 4/18
• 16 changes recommended for inclusion in the release, which affect both the substance of the underlying spec and the process/structure by which it’s managed .
• Recommended changes reflect contributions by cities, providers, and software companies.
• Consensus to include or defer reached on 100% of issues considered for 0.3.1.

(*) indicates change is not merged as of 2019-04-23

#256 - Updating schema version - Schema now properly reflects 0.3.x version. Release process modified to include schema version updates for future releases.

#263 - Add codeowners file to clear up review process - Subdivides repository maintenance responsibilities for the agency and provider APIs. Also removes 5 second telemetry requirement.

#264 - Release process and contribution guidelines - Updated ReleaseGuidelines.md and created CONTRIBUTING.md to reflect the new release process.

#286 - Initial check in of issue and PR templates - Created templates for issues and PRs to aid in proper labeling and milestone assignment #299 (*) - Formatting tweaks to above

#295 (*) - Flesh out definition of breaking vs. non-breaking changes - Provides clarity in the release process on what changes should be considered breaking.

#294 - Update branching process in release guidelines - Changes to the release process branch mechanics to smooth out workflow.

Various updates to providers.csv:

• #265 - Added Bolt to list of MDS providers
• #266 - CSV rendering fix - Minor cleanup to above PR
• #267 - clevrmobility.com update providers.csv
• #296 - Update Providers.csv with corrected SPIN API URL

#283 - Added to vehicle event deregister the event_type_reason decommissioned - Created an event_type_reason code to describe the removal of a vehicle from service due to non-repairable damage.

#278 (*) - Add event_type_reason codes to provider status_changes API - Provides a way to record when a city locks/unlocks/moves a vehicle using special administrative access rights granted to it by the provider.

#297 (*) - Add an associated trip id to status changes when a trip ends - There are certain circumstances in which the spec is ambiguous as to whether a trip_id can be associated with an event. For example, a scooter that is taken out of service at the end of a trip due to low battery may not have had an associated_trip_id. This modifies the language of the spec to allow an associated_trip_id for any event at the conclusion of a trip.

In addition to the above changes, there are two consensus changes which are still awaiting pull requests:

• #288 (*) - Include version number in README - Improve the ease with which someone looking at docs can identify the version of the spec they are looking at.

• #293 (*) - Add versions endpoint - Allow an MDS client to query an endpoint to determine what version of MDS it supports.

Thanks to everyone who contributed to the above issues in GitHub: @avigmati, @billdirks, @ccolgrove, @craastad, @dirkdk, @dyakovlev, @hunterowens, @jfh01, @karcass, @lionel-panhaleux, @margodawes, @morganherlocker, @rf-, @thekaveman

A number of topics were discussed during the 0.3.1 cycle. While all are good candidates for inclusion in a future patch release, participants felt that we have not yet arrived at an optimal technical solution and require further work.

• Mechanisms to see how a vehicle was accessed and paid for

  • #76 - Access method
  • #123 - Add membership type field

• Extending MDS beyond bikes and scooters

  • #170 - Determine how to support multiple modes

• Improve performance of MDS when working with large datasets and complex queries

  • #268 - Discussion: make MDS queries more predictable

• Address issues related to event ordering and allowable vehicle state transitions

  • #272 - Event timestamp unicity
  • #276 - Provider API: status changes order

• Provide a more formal definition of certain parameters of MDS requests

  • #281 - Use OpenAPI to define Provider API request shapes and query parameters

Consensus was reached on all issues or it was agreed that discussion should continue for a future release.

Based on the lack of urgent breaking change proposals and the desire to implement some of the deferred issues on an optional/non-breaking basis, the next release will be another patch release: 0.3.2.