Vetting of PR #92, V1.1 before merge #93
Comments
|
Just a question on the official change process - it currently says:
I've interpreted this to be the same as the GTFS change process, which requires that the proposal actually be implemented before it can be officially adopted. The following section "Extensions Outside of the Specification" says:
...which also implies that implementation comes before adoption. Is the above saying that the PR #92 will be adopted before implementation? |
|
I wonder if some other issues should not be integrated into V1.1, specifically #15, making implementation less risky to test/deploy. Perhaps easier agreed upon minor changes for milestone 2.0 could also be integrated: #6, #9 and #10. |
|
@barbeau You make a good point. My thinking was that since @dsgermain is implementing the proposed changes in his feeds, this was covered but you're right, the work hasn't happened yet. What do you think is a reasonable time frame for testing before a something gets merged? @serialc on #15 I agree this would be a good time to include it. Versioning seems like a prerequisite to the breaking changes in #6, #9 and #10. |
The requirements for GTFS include a producer and consumer implementation to ensure that the proposed field actually works in the real world. I'd say ideally we'd have the same thing here - someone producing and consuming the new data in at least a development environment to make sure there aren't any unforeseen issues. |
|
OK, not an issue. Our mobile app will be the first consumer of this information. I'll ping back when it is live. |
|
Can both implementations be provided by the same party ? I'm no expert in
standards governance so maybe my point is moot.
…On Tue, 20 Mar 2018, 17:49 dsgermain, ***@***.***> wrote:
OK, not an issue. Out mobile app will be the first consumer of this
information. I'll ping back when it is live.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#93 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAZbi6QTzVcXvpCgRqf8JrL_FbwWWcKhks5tgXmEgaJpZM4Sug1J>
.
|
|
In GTFS, no, it has to be two parties to adopt a new field. |
|
Did anyone ever bothered reaching out to @eskerda and/or considered implementing a consumption proposal in the citybikes API wrappers ? [EDIT] |
|
@mplsmitch, I guess the discussion is still ongoing ? |
|
@f8full - Where we left it is that @dsgermain will go ahead and start publishing. Once we have a consumer implementation we can go ahead with merging if there are no issues. Maybe you'd like to be that consumer? |
|
Ok I understand. The trouble is I don't consume directly but through
citybik.es. My level in python is not good enough to create a PR on that
project. I would gladly give a hand though.
…On Wed, 18 Apr 2018, 14:37 Mitch Vars, ***@***.***> wrote:
@f8full <https://github.com/f8full> - Where we left it is that @dsgermain
<https://github.com/dsgermain> will go ahead and start publishing. Once
we have a consumer implementation we can go ahead with merging if there are
no issues. Maybe you'd like to be that consumer?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#93 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAZbi_yeIGA19rxDwtB_5Wt2MdStO62nks5tp4fmgaJpZM4Sug1J>
.
|
|
I'm guessing this conversation is about closed, but I just noticed it when I was coming to look up details of the spec. Apologies for being late to the game. I just wanted to pop in and comment briefly on the Anyway, perhaps this is a v2 thing. Thanks for all your work on getting this out! |
|
I would add to that, in my hometown there are 3 gears bikes and 7 gears
one. Being able to distinguish in client applications would be nice.
…On Mon, 23 Apr 2018, 13:50 Kevin Wilson, ***@***.***> wrote:
I'm guessing this conversation is about closed, but I just noticed it when
I was coming to look up details of the spec. Apologies for being late to
the game.
I just wanted to pop in and comment briefly on the free_bike_status.json
change: A boolean is_ebike is more restrictive than an enum bike_type. As
different types of bike-like mobility devices are coming online (I'm
thinking of scooters specifically), it might be good to support them.
Anyway, perhaps this is a v2 thing.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#93 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAZbi9ydEEKuK5SgruyLcXRCMf-_Jyyrks5trhR3gaJpZM4Sug1J>
.
|
|
PR #136 and PR #175 address these issues and represent a heap of input from GBFS consumers and producers. We're hoping we can solidify support around them as the next steps forward. It would be great to get all of your input over there on the solutions that have emerged so far as "minimum viable proposals" that better represents what operators are providing on the ground. That said, I'd like to propose we close this issue and move relevant conversation there. @mplsmitch @dsgermain @barbeau @serialc @f8full @khwilson |
Hey everybody,
We have an open PR, #92 from @dsgermain that I would like to move forward on but there hasn't been any discussion since it was submitted. This is a significant update and I'd like others in the group to weigh in before it gets merged. If no outstanding issues are identified after one week’s time, and there is general agreement that the change is worthwhile and follows the GBFS guiding principles outlined in the READ.ME I will go ahead with the merge on 3/23/2018.
Thanks
The text was updated successfully, but these errors were encountered: