Proposal: Require autodiscovery gbfs.json file, define feed names

[barbeau]

This is a proposal to address #139, which includes requiring the autodiscovery gbfs.json file and establishing a clear convention for the feed names within the autodiscovery file.

Open questions:

• Do we require gbfs.json to be named gbfs.json? Or is a path like /gbfs allowed for auto-discovery?

EDIT Nov 18, 2019 - Add text requiring that gbfs.json be named gbfs.json.
EDIT Nov 18, 2019 - Remove text requiring that gbfs.json be named gbfs.json - it can be named whatever you want.

[barbeau]

I've updated this proposal to say that the gbfs.json file must be named gbfs.json - everything else can be named whatever you want, provided the keys and URLs are correctly defined within the auto-discovery gbfs.json.

I think this is ready for a vote! I hereby call a vote on this proposal. Voting will be open for 7 full days, until 11:59PM UTC on Monday, Nov 25.

[jcn]

I've updated this proposal to say that the gbfs.json file must be named gbfs.json

This seems like a weird requirement - if we're not dictating the path structure, then knowing that the GBFS file is named gbfs.json is not actually going to help us.

I agree that we should require the file so the rest of the paths can be discoverable, but as long as someone points to the file either from the <link rel="gbfs" ...> tag or in systems.csv (wherever that ends up) it seems like that's sufficient. I wouldn't want to force a technical implementation for no reason (i.e. I could imagine some implementation that, for whatever reason, had trouble with naming their files .json because of whatever underlying framework they were using).

[barbeau]

I wouldn't want to force a technical implementation for no reason (i.e. I could imagine some implementation that, for whatever reason, had trouble with naming their files .json because of whatever underlying framework they were using).

Yes, that's a fair criticism. I was on the fence about which way to specify this, and initially leaned towards requiring gbfs.json explicitly to provide some consistency on endpoints for the directory of feeds to avoid errors. But that can be managed via better documentation and validation at the directory level.

I'll revise this to say that gbfs.json naming isn't required.

[barbeau]

Ok, I've revised this based on @jcn's feedback.

I'd like to re-start the vote on this proposal. Voting will be open for 7 full days, until 11:59PM UTC on Monday, Nov 25.

Please vote for or against the proposal to require the auto-discovery file and define the feed names, and include the organization for which you are voting in your comment.

[evansiroky]

+1 from IBI Group

[barbeau]

Voting on this proposal is now closed. There was 1 in favor.

@antrim @heidiguenin What's the minimum vote threshold for a proposal in GBFS?

[barbeau]

The previous vote didn't get enough participation. We have clarified the process for the governance pilot, and we're hoping for more input this time around - #163 (comment).

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

Please vote for or against the proposal to require the auto-discovery file and define the feed names, and include the organization for which you are voting in your comment.

[gcamp]

+1 from Transit

[evansiroky]

@barbeau can you fix the merge conflicts real quick, please?

[barbeau]

@evansiroky The merge conflicts are fixed (thanks to @antrim a few days ago). Please vote!

[evansiroky]

+1 from IBI Group

[barbeau]

Voting on this proposal closes tomorrow, 11:59PM UTC on December 6th. So far we have 2 "yes" votes, and we need one more for it to be adopted.

Please review and vote!

cc @jcn

[yocontra]

+1 from Stae

[gcamp]

+1 from Transit

[evansiroky]

In case we're looking for a producer/consumer for this, we at IBI have implemented consuming code here. We were already seeing at least one feed that produces data in this way. For example this feed.

[barbeau]

The vote is closed and it passes!

3 votes for:

• IBI Group
• Transit
• Stae

...and no votes against.

I'm going to wait to merge until we conclude the discussion at #163.

[derhuerst]

(I'm commenting on this old PR because it introduced the sentence I have a question about. Let me know if I should open a new Issue to clarify this.)

All files in the spec may be published at a URL path […].

Does this mean that the URLs/IRLs can be relative, as in they don't have to be absolute?

I would argue strongly in favour of explicitly allowing relative URLs, given that

• they make a GBFS feed (the set of files) much more portable and less brittle, because it's "common path" can be changed without having to modify the files;
• currently, "URLs" are allowed generically, which includes relative URLs, so banning them could be considered a breaking change.

[richfab]

Thank you @derhuerst for your question!
Could you please create an issue in https://github.com/MobilityData/gbfs to start a conversation on this interesting topic of relative paths? I'd be curious to get the input of GBFS consumers on this.
Thank you!

[derhuerst]

I have created #544 to discuss this.