Policy: Address unknowns related to change management

[brianellin]

Is your feature request related to a problem? Please describe.

The Policy API makes it possible for Agencies to quickly make changes to the rules governing their micromobility programs. This is a powerful feature, but it leaves a lot unspecified. The lack of certainty around change management is something we have heard as a concern from both cities and operators. In particular:

• The Policy API does not reflect what rules can change or how frequently. This makes it difficult for a provider to design both their software systems and their accompanying operational strategy.
• It is unclear whether and when a provider will have a chance to share feedback or acknowledge a proposed rule change. There is not a clear mechanism for publishing a "draft" Policy, or recommendation of how that workflow should be handled.
• While a new Policy can be published with a published_date that is before the start_date, providers have no way of knowing in advance how much warning they will get. Again, this makes system design difficult.
• The operational implications and time required to implement a change can vary widely across types of rules (e.g. new deployment requirements vs new parking zone).

The above concerns are typically addressed outside the specification in a City's actual permitting language. Hence, it could be argued that adding them to the specification is unnecessary. On the other hand, much of what the Policy endpoint seeks to do is to "translate" permitting requirements into a standardized machine-readable format. It wouldn't be feasible or helpful to translate every permitting requirement, but it does seem worth translating those that impact the provider's software stack.

More practically speaking, the lack of specificity on the above concerns represents a barrier to adoption for the Policy API.

Describe the solution you'd like

No specific recommended solution at this time, just wanting to raise some real concerns and unanswered questions. Welcome feedback/solutions from the community.

Is this a breaking change

• I'm not sure

Impacted Spec

• policy

Describe alternatives you've considered

A strong best practices guide might address the concerns outlined above.

[Retzoh]

Hi @brianellin, thanks for raising this issue ! I agree we need to do something about this.

I also think that the current versioning system for policies could be improved. Today you need to create a new policy referencing an incorrect one through the prev_policy field to update or cancel it. This means that looking at one given policy is not enough to know if it should be respected or not, you need to look at all of them. Is this in the scope of this issue?

[schnuerle]

Discussed on our call today. We are looking for community thoughts and feedback on this proposal. Great idea that needs a resolution. Targeting release 1.1.0 for now.

[brianellin]

I also think that the current versioning system for policies could be improved. Today you need to create a new policy referencing an incorrect one through the prev_policy field to update or cancel it. This means that looking at one given policy is not enough to know if it should be respected or not, you need to look at all of them. Is this in the scope of this issue?

@Retzoh that is also an interesting issue, though I would consider it to be outside of the scope of this topic. I think we should track that separately.

[Retzoh]

Just did in #529

[schnuerle]

#567 is related to this, and possibly a duplicate.

[schnuerle]

This needs some more discussion and consensus so targeting that in the next release.