I would rather have this upgraded to required, without the constraint.

I would rather have this upgraded to required, without the constraint.

I think you're not the only one, but making feed_info.txt Required would make existing data invalid & be a breaking change, which goes against our guiding principles.
Recommended is one solution for encouraging the industry to produce feed_info.txt while following these principles.

Upgrading anything from optional as required would be a breaking change. Hence, I would like to have a vote on the right solution. This still does not help us forward.

Unsure what you are arguing here @skinkie, that we break backward compatibility without a versioning scheme or other means to have a transition? Should consumer start rejecting dataset the minute the vote has passed?

Unsure what you are arguing here @skinkie, that we break backward compatibility without a versioning scheme or other means to have a transition? Should consumer start rejecting dataset the minute the vote has passed?

As we both know nobody is actively rejecting data. Not even when their data is not in UTF-8, a requirement which is also part of this great standard. Making an extra file mandatory as part of the specification does not break the existing implementations only new implementations.

Now, the suggestion is that we could make feed_info.txt mandatory once when translations.txt was provided. Was that then a breaking change? Or can we introduce any new feature (without versioning) and then just say: "If you use this feature, then you must provide feed_info.txt."

I assume consumers would only reject files unsuitable for their particular system, which could be different from what that standards require.

This PR doesn't change the requirement level for feed_info.txt, it updates the table at the top to match the requirement we have at the file level.

The change to make feed_info.txt go from Optional to Recommended was voted on in #386.

Discussing changing it from Recommended to Required would have to happen in another issue, and we have an issue open for discussing backward compatibility and versioning.

Given that this PR is not changing the spec but rather adding an amendment that was missed in #386, I was thinking a review would be enough to merge this PR, and that a vote wouldn't be necessary.

That being said, I am happy to call a vote if others think it's needed.
Thoughts? Do we need a vote before merging this PR?

Even if it was a mistake from a previous PR, this is not from an editorial change. I would do a vote.

This PR has been open for at least 7 calendar days. As per the Spec Amendment Process, I am opening a vote for updating the requirement of feed_info.txt in the top section, so that it matches what is described below.

Voting ends on 2024-07-17 at 23:59:59 UTC.

+1 UrbanLabs

+1 OpenGeo

+1 Transit

+1 from @interline-io

+1 Caltrans

The voting period ended on 2024-07-17 at 23:59:59 UTC.

With 5 votes in favor and no votes against, the vote passes.
The votes came from:

• @e-lo (UrbanLabs)
• @skinkie (OpenGeo)
• @gcamp (Transit)
• @drewda (Interline)
• @evansiroky (Caltrans)

Thank you to everyone who participated!

This recommendation has been incorporated into the Canonical GTFS Validator V6.0.0. Please refer to the release page: https://github.com/MobilityData/gtfs-validator/releases/tag/v6.0.0.