-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Recommended rule type for policy #557
Comments
Thanks @robinef, this is super interesting. Could you share a bit more about how Zurich actually incentives operators to follow these recommendations? |
FYI we do have an issue open for adding Stops to Policy, see #554. Instead of replacing the
I see how the I'd also like to know more about how Zurich is using these currently with operators to help come up with a solution that meets your needs. |
Very interesting! Would love to dig into this more. A quick note: as of MDS 1.0.0 |
Thanks a lot @quicklywilliam and @schnuerle for your positive feedback ! I'm not very familiar with the I forgot to mention that the first city willing to implement that use case on our side is Bruxelles (Zurich will be later) : |
@quicklywilliam - Today Bruxelles wouldn't have specific programs to incentivise operators to deploy vehicles in these zones, except trust and communication. The regulation does not allow today for specific enforcement. However, it is expected that operators use nudging to incentivise users to finish their rides in these zones. Coming back to our discussion, I don't think In case of drop-off zones / parking corrals where parking is recommended / enforced, one case uses the new Also a fair question here is whether by default we assume (as industry) that any policies coming out of the policy API are enforced. Given the little maturity of regulations / legal framework in cities, it would be difficult to assume this. Operators would need to understand which policies are enforced, and which ones are recommended (for instance guiding users behaviour) Also, regarding the use case drop-off zones / parking corrals, a city can enforce operators (re)-deployment in these zones but not user drop-offs. I think a rule should apply to the new @Karcass also discussed using the field "Info", i believe he meant user. "Information for users, e.g. about helmet laws. Generally can't be enforced via events and telemetry." Does this mean it can't be enforced technically or legally ? Otherwise I'm struggling to understand the fit for this use case. 1/ Are policies coming out of the Policy API automatically enforced legally ? Or could there be implemented to guide behaviours before being enforced for instance ? The optional field |
I will work on a PR to add an optional field called |
In PR #605 I added a new rule optional field called
I'm not totally happy with the Note the 3 enumerated values may require more explanation, or others could be added, like testing. Let me know your thoughts on this and if it will address your use cases. |
I'm concerned that we are jumping too quickly to solutions with this one. I'm concerned that "recommended" or "optional" rules have implicit meaning, and I believe that Policy should always strive to be explicit when possible. What specifically is being required, and in what sense is a rule optional or recommended? I've heard some several use cases for recommended rules, but in each case it seems like a more explicit policy is possible. Let's take the example of parking corrals.
In each of these three stages, corrals are in some sense optional or recommended. However, an optional or recommended field isn't needed to express this fact – and might in fact confuse the situation. In two of the cases above, there is also an explicit requirement attached. As a next step, I'd suggest we solicit and work through further examples, applying the principle of being as explicit as possible and seeing what challenges we encounter in practice. |
I am aligned with @quicklywilliam on this topic |
Ok so it sounds like in the examples @quicklywilliam has put forth, everything a city could do around rules from making them optional to required to incentivized can be done now with MDS. @robinef are you following this, and do you agree? Maybe what is needed in the spec is more clarification and examples of how cities can do this. Do you all think this should be done in the spec, maybe in a new section about how to use MDS to create stages of rule, or maybe just in the examples area that can be linked to from the spec? I do think if the enumeration values are clearly defined and thought out in the spec an idea like this could be good and eliminate some confusion (though potentially creating new confusion if done poorly). |
@schnuerle I could be wrong but I don't think it is currently possible to do #2 (require providers to show stops in their apps). It seems like a fairly straightforward extension of the And yes, I agree that more examples and linking to them from the spec would be good! There are a lot of really common use cases that require you to combine multiple Policy rules in ways that are not immediately intuitive/obvious. |
@schnuerle yes, i'm following, and it triggers a lot of discussion internally. Generally speaking I agree that having a clear list of simple use cases with attached MDS policy (with sometimes complex multi-layer) could really help everybody in the community to better understand and adopt policies. But I still believe that we need more granularity in the way cities could express their wishes/needs, especially in some context that are lacking regulatory frameworks. |
See PR #605 for some conversations about this. Lots of discussions but not full consensus. |
Per the final release discussions yesterday, agreed that this needs more conversations and move to next release.
|
Tagging this for 2.0 since it aligns with Policy reworking. Please leave your thoughts here if have some new ones to share one year later. |
Is this still a pressing issue we want to address or is it ok to close it for now? |
Moving to a future release |
Is your feature request related to a problem? Please describe.
We would like to implement policy API to not only restrict some behaviours but also encourage them. We have several use cases where cities want's to dynamically propose some preferred parking spots to encourage users to park in dedicated areas. Actually the policy API rule type list does not allow us to propose that.
Describe the solution you'd like
We would like to propose 2 changes in the current specification to be able to cover those new use cases :
recommended
. This type is showing the city preference for certain statusesstatuses
to provide a list ofevent_type_reason
rather thanevent_type
which is too generic. We believe thatevent_type_reason
is much more detailed and mandatory of our scenarioFor example, if a city wants to encourage parking zone, we can have a new policy like
Is this a breaking change
It could be a breaking change for the
statuses
field. But since anevent_type_reason
is always attached to anevent_type
, there is a compatibility since it will be easy to find the parent by defining the child.Impacted Spec
For which spec is this feature being requested?
policy
Describe alternatives you've considered
We are not considering any other simple alternative, everything will be more complex and need a longer study.
Additional context
The current context is for the City of Zurich.
The text was updated successfully, but these errors were encountered: