An interesting post on the gtfs-realtime group is worth following.
Beginning to addressing problems that some have with the GTFS/GTFS-rt ‘standards,’ which some sticklers decry as mere de-facto standards, as they don’t follow standards development processes.‘ Developing the GTFS in typical tech industry fashion, these practices were acknowledged, but not closely followed.
This has definitely ushered an explosion of open data and accelerated delivery of countless sucessful applications (unlike other transit data standards). But now that progress is slowing.
The complete original post saved for posterity (because you never know if it’ll be available in the future) is below the fold.
What’s wrong with current process?
Currently de-facto process of changing GTFS Realtime specification does not roll forward. Changes are proposed to the list, but even changes that have universal support do not make it to the specification. The specification is open, but maintained by Google. We want the specification to evolve, but with guidance and feedback from the GTFS Realtime community to ensure that the proposed changes are generally feasible, and providers are willing to adopt the changes. The existing process has following issues:
“Silence is acceptance.” There’s no explicit end point, and instead the lack of negative response is deemed as consensus. A proposal is accepted after some (usually 1-2 weeks) quiet period during which there had been no concerns.
Lack of clarity. A proposal is made in form of an email in the GTFS Realtime mailing list, and requires manual work to transfer it into the specification. Sometimes thread starter proposes several alternative wordings. The thread often has multiple proposals, all with differing structure to the proposals, making it difficult to assess them on the same footing, and otherwise navigate responses to each particular counter-proposal versus the original.
Lack of leadership. The owner of the proposal is not expected to drive the proposal to the accepted state, and typically does not know how to do so.
Lack of commitment. There is no formal process which would set a time limit and formal criteria for proposal acceptance or rejection.
Goal
Every proposal should be reviewed, commented, and decided on in a timely manner. There should always be a clear owner of the proposal, and single current version of proposal in a form that is easy to collaborate on, and which can be easily seen on its own and within the larger context of the whole specification. There should be explicit decision on every proposal.
Non-goal: We do not aim to accept every proposed change. We should accept only changes which have general relevance to the community at large, and not a specific provider.
Proposal
Publicly available repositoryWe propose to move the GTFS Specification and accompanying documentation to a GitHub repository in the form of Markdown documents. This gives the following benefits:
it is widely accepted collaboration tool used in the industry;
proposals can be created in a WYSIWYG editor, commented, discussed and accepted into the master branch much like in a Wiki, even if the author completely lacks Git knowledge;
Github directly renders documents in Markdown markup language, and it is much preferable to editing HTML specification.
Specification proposals process
To create a proposal one should first create a github branch with full update of the English text of all relevant parts of protocol definition, specification and documentation files.
Next, pull request on the master branch should be created. Pull request must contain an extended description of the patch. The creator of the pull request becomes the advocate.
Once pull request is registered, it must be announced by its advocate in the mailing list. Once announced, the pull request is considered a proposal. Pull request comments should be used as the sole discussion forum.
The advocate is responsible for timely update of the proposal based on the comments for which they agree to.
The advocate can call for a vote on a version of the proposal at any point in time but no earlier than 7 calendar days after the proposal was announced.
Vote lasts the minimum period spanning at least 7 full calendar days, and at least 5 full business days. Vote ends at 23:59 UTC. The specific end time should be identified at the start of the vote.
During voting period only editorial changes to the proposal are allowed (typos, wording may change as long as it does not change the meaning).
Anyone is allowed to vote yes/no in a form of comment to the pull request, and votes can be changed until the end of the voting period.
Votes before the start of the voting period are not considered.
The proposal is accepted if there were a consensus yes with at least 3 votes.
Votes against shall be motivated, and ideally provide actionable feedback.
If the vote has failed, then the advocate may choose to continue work on the proposal, or to abandon the proposal. Either decision of the advocate must be announced in the mailing list.
Once proposal is accepted, Google is committed to merging the voted upon version of the pull request, and performing the pull request within 5 business days.
Translations do not have to be included into the original pull request. Google is responsible for eventually updating translations of the protocol buffer and specification into supported languages, but pure translation pull requests from the community are welcome and do not have to go through the discussion process.