Proposal: Add feed_contact_email field to system_information.json

[yocontra]

Issue

Currently as a consumer of a feed, you have no real way to contact the operator of that feed. The email attribute is meant for general support purposes, so doesn't solve this issue. This results in issues being opened on this repository and causes a really painful feedback loop of trying to locate the person who can fix the actual problem. This is particularly relevant as we've been discussing more systematic validation tools for feeds in systems.csv in the GBFS workshop.

Solution

Non-breaking, adds an optional technical_email property to system_information.json where providers can specify where to send bug/validation/etc. reports.

Feedback needed

• Open to changing the actual property name, but this was the clearest I could come up with.
• Should email be renamed to support_email to clarify it's purpose?
• Should this be required and released as a breaking change?
• Is this useful for feed consumers?
• Is this easy for operators to add, or is it too much of a burden?

[barbeau]

+1 for optional technical_email. I've had the same experience where it took me a long time to track down the person that can actually fix a problem in the feed. GTFS has analogous fields agency_email for transit agency customer support and feed_contact_email as a technical contact.

See issues #149, #177, #178, and #179 for examples of data quality issues being reported on this repo.

Should this be required and released as a breaking change?

IMHO I would say no. It should, however, be a best practice to include the field.

Should email be renamed to support_email to clarify it's purpose?

I don't think that's necessary - the current description makes it's purpose pretty clear - "A single contact email address for customers to address questions about the system"

[yocontra]

@barbeau Thoughts on using feed_contact_email instead of technical_email to align w/ GTFS?

[mplsmitch]

+1 for aligning the name with GTFS. I think there's a case to be made for this being a required field but that could come later as part of a major release. In the interim it could be added as an optional field.

[barbeau]

Using feed_contact_email to align with GTFS works for me.

[yocontra]

Updated.

[kanagy]

+1 Thanks for adding this field.

Just a thought: Should this be an array of emails to be more flexible? I don't lean either way. A group alias can always be defined instead.

[jcn]

Should this be an array of emails to be more flexible?

To stay consistent with GTFS and with the existing email field I'd propose sticking to a single valid email address.

[yocontra]

Seems like we have consensus here, what are the next steps for including this in the upcoming version of GBFS?

[jcn]

As an optional field, it seems like this would be ready for the formal approval step with a merge into master, with inclusion into the next minor release.

[antrim]

Hi @contra: Thanks for pinging on this. Please go ahead and call the vote! Here's an example "call the vote" comment: #188 (comment).

[yocontra]

I hereby call a vote on this proposal. Voting will be open for 7 full days, until 11:59PM UTC on Thursday, Nov 28.

Please vote for or against the proposal to add the feed_contact_email field, and include the organization for which you are voting in your comment.

[jcn]

👍 from me as an independent developer

[barbeau]

👍 from me from OneBusAway/USF

Prior to merging this, though, do we need a producer and consumer of the field?

[kanagy]

+1 from me from Google Maps

[MuteQ]

+1 from Transit

[mplsmitch]

👍 from me as an independent mobility enthusiast

[heidiguenin]

@barbeau We do need a producer to vote on this. And as part of the governance pilot, we're going to work on language about implementor commitment happening in parallel with vote.

[heidiguenin]

@kanagy @MuteQ Are either of you able to commit to implementing this change on your end?

[gcamp]

I don't think consumer have anything to "implement" here, more than just using the field internally when appropriate. Nothing to change in the consumer application.

[evansiroky]

+1 from IBI Group

[heidiguenin]

Sorry, folks, to have to do this, but we're going to re-open the vote. Since it closed on a holiday in the US, and we still need a producer to chime in, we're giving it another go and keeping it open an extra day.

I hereby call a vote on this proposal. Voting will be open for 7 full days, until 11:59PM UTC on Monday, December 9th.

Please vote for or against the proposal to add the feed_contact_email field, and include the organization for which you are voting in your comment.

[madupras]

+1 from PBSC

[heidiguenin]

@MuteQ @evansiroky @kanagy Would you all mind voting again now that we had to re-open the vote? Thank you!

[MuteQ]

+1 from Transit

[evansiroky]

+1 from IBI Group

[johnpena]

+1 from Lime

[quicklywilliam]

+1 Ride Report

[kanagy]

+1 Google Maps

[charlesjump]

+1 JUMP

[mdwestervelt]

+1 Bird

[antrim]

The vote has passed!

4 votes in favor from producers:

• PBSC
• Lime
• JUMP
• Bird

4 votes in favor from consumers:

• Transit
• IBI Group
• Ride Report
• Google Maps

[antrim]

Are there any GBFS feeds that are supplying this field? I have gone ahead and merged this, expecting GBFS feeds to provide this field soon. I expect we'll need to be more rigorous about waiting for producer/consumer implementations before a release in the future, but right now GBFS in catch up mode.

[heidiguenin]

We'd love to make this an official part of the spec, but first we need to see this change being implemented. Could you comment here if your organization has implemented this?

[evansiroky]

We at IBI Group may not imminently implement code to ingest this, but will definitely manually inspect feeds for this data if we need to.