-
Notifications
You must be signed in to change notification settings - Fork 290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feed_contact_email required #454
Conversation
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 |
Hi Mitch, Thanks for pointing that out! These modifications have now been pushed in the latest commit. |
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. |
+1 from myself/All The Places who consume this data |
+1 from FutureTap. Useful for our Where To? app. |
+1 from Transit |
+1 from Entur |
+1 from Google |
+1 from transport.data.gouv.fr (if we can vote 😬), otherwise just saying that this will be very useful 😅 |
+1 from PBSC |
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. |
+1 from nextbike by TIER |
+1 from Lime |
+1 from Joyride |
+1 from BCycle |
+1 from Ito |
+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. |
+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. |
This vote has now closed, and it passes! Votes in favor: |
Add language suggested by @ezmckinn for pointing to generic email rather than individual.
This reverts commit 9456f6b.
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 withinsystem_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?
Which files are affected by this change?
The only file affected by this change is
system_information.json