Feed_contact_email required

[Sergiodero]

Hi everyone,

Sergio from MobilityData here! Please see below our proposed change.

What problem does your proposal solve?

As a consumer, it is often useful to know how to contact data producers to solve potential issues with their feeds. Contact information is in some cases provided voluntarily by producers, but frequently this is not the case for most of GBFS feeds, producing some painful back and forth when consumers scramble to find help from the producer's side.

What is the proposal?

Version 1.1 implemented the optional feed_contact_email field within system_information.json file (see PR #181) in which producers could include a single contact email, so that consumers could reach out and report any technical issues from the provided feed.

In pursuit of implementing best practices that lead to high quality data, we would like to propose for this field to change from “OPTIONAL” to “REQUIRED”, so that all feeds include the necessary information for consumers to know who to contact in case any technical issue presents itself.

Is this a breaking change?

• Yes
• No
• Unsure

Which files are affected by this change?

The only file affected by this change is system_information.json

[CLAassistant]

All committers have signed the CLA.

[mplsmitch]

I'm in favor of this change, however you should also update the language (from SHOULD to MUST) in the Feed Availability section here: https://github.com/MobilityData/gbfs/blob/master/gbfs.md#feed-availability

Also, if it's to become a required field, the feed_contact_email definition needs to change from "SHOULD contain" to MUST

[Sergiodero]

Hi Mitch,

Thanks for pointing that out! These modifications have now been pushed in the latest commit.

[josee-sabourin]

I hereby call a vote on this proposal. Voting will be open for 10 full calendar days until 11:59PM UTC on Friday, January 20th.

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.

[Cj-Malone]

+1 from myself/All The Places who consume this data

[futuretap]

+1 from FutureTap. Useful for our Where To? app.

[cmonagle]

+1 from Transit

[testower]

+1 from Entur

[bdferris-v2]

+1 from Google

[AntoineAugusti]

+1 from transport.data.gouv.fr (if we can vote 😬), otherwise just saying that this will be very useful 😅

[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.

[rootsixtysix]

+1 from nextbike by TIER

[kheraankit]

+1 from Lime

[benwedge]

+1 from Joyride

[cait32]

+1 from BCycle

[rickbruce]

+1 from Ito

[ezmckinn]

+1 from Superpedestrian — although I would suggest that the GBFS spec add language like "This email address should point to a stable email address, that does not correspond to an individual but rather the team or company that manages GBFS feeds." This both protects PII and ensures that staff turnover does not disrupt the GBFS feed.

[schnuerle]

+1 from me as OMF staff, though I do agree with @ezmckinn and it might be good to clarify it's a generic email and not a personal one as this is a public feed.

[josee-sabourin]

This vote has now closed, and it passes!

Votes in favor:
All The Places (consumer)
whereto.app (consumer)
Transit (consumer)
Entur (consumer)
Google Maps (consumer)
transport.data.gouv (consumer)
PBSC (producer)
Nextbike (producer)
Lime (producer)
Joyride (producer)
BCycle (producer)
Ito World (producer)
Superpedestrian (producer)
OMF (3rd party)


There were no votes against.
Thank you to everyone who took the time to review and to vote on this! We incorporate it into 3.0-RC, which should be ready to go in the coming week.