New Field - termination_date

[mplsmitch]

Adds a new field, termination_date, to system_information.json to notify data consumers when feeds will be discontinued.

What problem does your proposal solve? Please begin with the relevant issue number. If there is no existing issue, please also describe alternative solutions you have considered.

The specification lacks a way to notify data consumers when a feed is shutting down permanently and will no longer be available. This has come up a number of times in the past but we have yet to formalize a best practice for feed end of life. Relevant issue with further discussion is #492.

What is the proposal?

Add a field termination_date to system_information.json that contains the date when the feed will go off line. Define best practice for communicating with data consumers about feed end of life.

Is this a breaking change?

• Yes
• No
• Unsure

Which files are affected by this change?

gbfs.md > system_information.json

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ richfab
❌ mplsmitch
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[mplsmitch]

I hereby call a vote on this proposal. Voting will be open for 10 full calendar days until 11:59PM UTC on May 4th.
Please vote for or against the proposal, and include the organization for which you are voting in your comment.
Please note if you can commit to implementing the proposal.

A few notes on voting:

• Anyone may vote on a proposal. You do not need to be a member of MobilityData.
• A vote passes if there is unanimous consensus with at least 3 votes in favor.
• At least one of the 3 votes MUST be from a GBFS producer and at least one MUST be from a GBFS consumer.
• Votes against a proposal can stop it from passing if they provide a specific reason for voting against and contain actionable feedback.
• If you represent an organization, only one vote per organization will be counted.

CC: @mwillmott

[mwillmott]

Note that the original comment refers to station_information.json but i believe it is meant to be system_information.json as reflected in the actual changes made.

On that basis, Lyft (operator) votes for this proposal.

cc @ArashMansouri

[mplsmitch]

Note that the original comment refers to station_information.json but i believe it is meant to be system_information.json as reflected in the actual changes made.

@mwillmott thanks for catching that, I've corrected it

[futuretap]

+1 from FutureTap / Where To? (consumer)

[cmonagle]

+1 from Transit

[benwedge]

+1 from Joyride

[fbouchPBSC]

+1 from PBSC

[josee-sabourin]

Voting on this PR closes in 2 calendar days. Please vote for or against the proposal, and include the organization for which you are voting in your comment. Please note if you can commit to implementing the proposal.

[ezmckinn]

+1 Superpedestrian supports this proposal.

[josee-sabourin]

This vote has now closed, and it passes!

Votes in favor:
FutureTap / Where To? (consumer)
Transit (consumer)
Joyride (producer)
PBSC (producer)
Superpedestrian (producer)


There were no votes against.

[richfab]

LGTM