Hi all,
As some work ramps up with GTFS-flex, we figured it would be a good time to set up an initial structure for a change process. This is a natural follow-up to Aaron Antrim's
previous post about moving the spec to Github - it now exists at
https://github.com/CUTR-at-USF/gtfs-flex.
In a
pull request there, I proposed that we roughly follow the
GTFS-realtime/
GTFS change process, which is structured around voting via comments on Github pull requests. A Github pull request is a set of proposed changes/additions to the spec.
Here is the general structure we'd like to follow for GTFS-flex at this point:
- Proposer/pull requester becomes advocate for the proposal
- 7 days for feedback - votes are indicated via commenting with a "+1" to indicate support for the change, and a "-1" to indicate that you don't believe the change should take place.
- Then merge if no -1; require constructive feedback/alternative suggestions with downvote (-1)
We're early in the spec process now, so I think we want to find the right balance between being able to iterate quickly based on real-world examples but also limit purely speculative additions.
For those new to Github, you'll need to create an account there, and then you will be able to comment on any pull request. You can also choose to "watch" the repository to be emailed any time someone proposes a change. Here are two guides that those new to Github might find useful:
Please let us know if you have any questions/concerns/comments about this process!
Thanks,
Sean
Sean Barbeau, Ph.D.
Center for Urban Transportation Research
University of South Florida