Skip to content
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

Merged
merged 4 commits into from
Jan 23, 2023
Merged

Feed_contact_email required #454

merged 4 commits into from
Jan 23, 2023

Conversation

Sergiodero
Copy link
Contributor

@Sergiodero Sergiodero commented Oct 11, 2022

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
Copy link

CLAassistant commented Oct 11, 2022

CLA assistant check
All committers have signed the CLA.

@mplsmitch
Copy link
Collaborator

mplsmitch commented Oct 11, 2022

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
Copy link
Contributor Author

Hi Mitch,

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

@josee-sabourin josee-sabourin added the v3.0-RC Candidate change for GBFS 3.0 (Major release) label Oct 17, 2022
@mplsmitch mplsmitch mentioned this pull request Oct 28, 2022
3 tasks
@josee-sabourin
Copy link
Contributor

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
Copy link
Contributor

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

@futuretap
Copy link
Contributor

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

@cmonagle
Copy link
Contributor

+1 from Transit

@testower
Copy link
Contributor

+1 from Entur

@bdferris-v2
Copy link
Contributor

+1 from Google

@AntoineAugusti
Copy link
Contributor

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

@fbouchPBSC
Copy link
Contributor

+1 from PBSC

@josee-sabourin
Copy link
Contributor

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
Copy link

+1 from nextbike by TIER

@kheraankit
Copy link

+1 from Lime

@benwedge
Copy link

+1 from Joyride

@cait32
Copy link

cait32 commented Jan 19, 2023

+1 from BCycle

@rickbruce
Copy link

+1 from Ito

@ezmckinn
Copy link
Contributor

+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
Copy link
Contributor

+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
Copy link
Contributor

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.

Add language suggested by @ezmckinn for pointing to generic email rather than individual.
@josee-sabourin josee-sabourin merged commit 9456f6b into master Jan 23, 2023
@josee-sabourin josee-sabourin deleted the Feed-contact-email branch January 23, 2023 17:30
@josee-sabourin josee-sabourin restored the Feed-contact-email branch January 23, 2023 17:43
josee-sabourin added a commit that referenced this pull request Jan 23, 2023
josee-sabourin added a commit that referenced this pull request Jan 23, 2023
Adds in-line annotations to changes made in v3.0-RC (#460, #454, #457, #462, #470)
Removes "RC" from annotations in v2.3-RC and RC2
josee-sabourin added a commit that referenced this pull request Jan 23, 2023
* Add versions to new and updated fields

Adds in-line annotations to changes made in v3.0-RC (#460, #454, #457, #462, #470)
Removes "RC" from annotations in v2.3-RC and RC2
Editorial changes
@josee-sabourin josee-sabourin deleted the Feed-contact-email branch March 13, 2023 14:30
@richfab richfab added the gbfs.md label Mar 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gbfs.md v3.0-RC Candidate change for GBFS 3.0 (Major release) Vote Passed
Projects
None yet
Development

Successfully merging this pull request may close these issues.