Add GTFS-realtime producer/consumer requirement, limited time for experimental fields

[barbeau]

Per discussion in #109, this proposal updates the GTFS-realtime change process to:

1. Add a requirement of a GTFS-realtime producer and consumer prior to the adoption of GTFS-realtime experimental fields officially into the spec via the "Specification amendment process". This mirrors the GTFS producer/consumer requirement.
2. Add a limited time window for GTFS-realtime experimental fields, after which they would be deprecated if not officially adopted. Deprecated fields can be "undeprecated" if voted on via the "Specification amendment process". An example case is the situation in which a consumer and producer can't both implement the new field within the 2 year window, but after the 2 year window expires both consumer and producer are now using the field, and therefore a vote to officially adopt the fields via the "Specification amendment process" can now be held.

Announced on the GTFS-realtime Google Group at https://groups.google.com/forum/#!topic/gtfs-realtime/bFC2rwxxylk.

[gcamp]

👏 Agree 100%

[abyrd]

Looks good. What do you think about the "pre-approval" idea I mentioned in #109 (comment)? In short: if there is unanimous support for an experimental change, then the producer/consumer implementations are submitted within the deprecation time window, there is no need for another vote. This reassures the people building the implementation that they are not working on something that won't be accepted.

[barbeau]

@abyrd Personally I'm a little wary of automatically adopting experimental changes into production without final approval by the community, given that a lot can change in two years. Given the current proposal even if a vote to adopt a change officially fails, with the soft deprecation existing producers and consumers can continue to use the field as-is, without needing to yank it out of their implementation. But I'd like to hear from others on this.

Also, technically, reading the existing change documentation again I don't believe it's explicitly stated anywhere that you must submit a field as experimental before calling for a vote for official adoption (but someone correct me if I'm wrong). So if you had a producer and consumer you could call for a vote to officially adopt the field immediately. Related to this, we should probably state in the process that the proposer should explicitly say whether they are calling on a vote for an experimental field or production field.

[barbeau]

I just added another sentence saying advocate should clearly state if vote is for production or experimental fields in 96ea5ec.

[abyrd]

@abyrd Personally I'm a little wary of automatically adopting experimental changes into production without final approval by the community, given that a lot can change in two years.

That makes sense to me, I was just wondering.

I don't believe it's explicitly stated anywhere that you must submit a field as experimental before calling for a vote for official adoption (but someone correct me if I'm wrong)... we should probably state in the process that the proposer should explicitly say whether they are calling on a vote for an experimental field or production field.

Also makes sense. An experimental field can be requested when an idea is too new or undeveloped to have unanimous support or producer/consumer implementations. Otherwise one can aim directly for official adoption.

[barbeau]

This pull request has been open for more than one week, so per the Official Process I'm calling for a vote.

Vote will be closed on Friday March 1st at 23:59:59 UTC.

[gcamp]

+1

[jrsanbornjr]

+1

[laidig]

+1

[abyrd]

+1

[prhod]

+1

[skinkie]

+1

[barbeau]

Voting is closed on this proposal and the results are:

Yes - 6

So it passes! Thanks all!