Supporting `grace_period` field in the system pricing plans

[elouanlbrs]

Have you read our FAQ? It's possible your question can be answered there!
Yes

If you are new to the specification, please introduce yourself (name and organization/link to GBFS). It's helpful to know who we're chatting with!
My name is Elouan LE BRAS, and I am currently a backend developer at Ecovelo, a French organization that provides all-inclusive shared mobility solutions focused on e-bikes for cities and metropolitan areas.

What is the issue and why is it an issue?
We recently implemented a new pricing option following a request from one of our customers: a grace_period feature. This grace_period allows cyclists with certain plans to receive X minutes of free trips each day/week/month. However, we cannot properly represent this behavior within the current GBFS per_min_pricing structure. The current per_min_pricing model charges from the first minute of usage, but our grace_period feature needs to provide a certain number of free minutes that reset at regular intervals (day, week, ...). This could be an interesting pricing model to implement in bike-sharing systems that cannot be accurately expressed with the existing specification.

Please describe some potential solutions you have considered (even if they aren't related to GBFS).
We propose adding optional grace_periodand grace_distance fields to the system_pricing_plans.json specification. While we specifically need the grace_period for our implementation, we believe grace_distance could also be valuable for operators who want to offer free distance-based allowances.
Here is our proposed solution:
system_pricing_plans.json

Field Name	REQUIRED	Type	Defines
plans	REQUIRED	Array<Object>	Contains one object per pricing plan.
...	...	...	All existing defined properties
plans[].grace_period	OPTIONAL	Object	Period of time for which the trip is not charged, resetting at a given interval.
plans[].grace_period.interval	REQUIRED	String	Interval at which the grace_period is reset (possible values: day, week, month).
plans[].grace_period.interval_count	REQUIRED	Non-Negative Integer	Number of interval units before resetting the grace_period.
plans[].grace_period.minutes	REQUIRED	Non-Negative Integer	Number of charge-free minutes provided to the cyclist, reset at the specified interval.
plans[].grace_distance	OPTIONAL	Object	Distance for which the trip is not charged, resetting at a given interval.
plans[].grace_distance.interval	REQUIRED	String	Interval at which the grace_distance is resetted (Could be : day, week, month, ...).
plans[].grace_distance.interval_count	REQUIRED	Non-Negative Integer	Number of interval units (
day, week, ...) before resetting the grace_distance.
plans[].grace_distance.kilometers	REQUIRED	Non-Negative Float	Number of charge-free kilometers provided to the cyclist, reset at the specified interval.

Example usage:

{
  "plan_id": "daily_commuter",
  "grace_period": {
    "interval": "day",
    "interval_count": 1,
    "minutes": 30
  }
}

This would provide 30 minutes of free usage per day before standard pricing applies.

Is your potential solution a breaking change?
[ ] Yes
[X] No
[ ] Unsure

[mplsmitch]

I would recommend you pursue just the grace_period for now since grace_distance seems speculative and therefore unlikely to meet the implementation requirements to become part of the specification.

What I'm struggling with is how these grace_period data in your example would be used. In the example above, the first 30 minutes per day are free but a consuming application has no access to the user's usage data so this couldn't be used to price a trip. How would it be displayed? Why wouldn't you just put this in plans[].description ?

{
        "plan_id": "daily_commuter,
        "name": [
          {
            "text": "Daily Commuter",
            "language": "en"
          }
        ]
        "description": [
          {
            "text": "First 30 minutes per day free.",
            "language": "en"
          }
        ]
}

plans[].description(as of v3.0)	REQUIRED	Array	Customer-readable description of the pricing plan. This SHOULD include the duration, price, conditions, etc. that the publisher would like users to see.

Another example where this type of pricing is used is Hamilton, Ontario. Their feed is v1.0 so very out of date but they're using the description field:
http://hamilton.socialbicycles.com/opendata/system_pricing_plans.json