Policy Rule Necessity options

[schnuerle]

Explain pull request

Per #557 adding a new rule optional field called necessity which enumerates some options for policy makers to attach to a rule:

• required (default)
• recommended
• optional

Is this a breaking change

• No, not breaking

Impacted Spec

Which spec(s) will this pull request impact?

• policy

Additional context

I'm not totally happy with the necessity field name, but it does seem to make some sense, describing how necessary the rule is. Other options could be requirement, enforcement, or importance.

Note the 3 enumerated values may require more explanation, or others could be added, like testing.

[quicklywilliam]

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.

1. Suppose the city installs some corrals. Initially, the City is OK with scooters parked elsewhere, and would merely like to make information about corrals available to encourage their use. In this case, the City isn't really hasn't expressed a rule at all – they are merely describing a feature of the right of way. They would do this simply by creating a list of Stops.

2. Now suppose after 3 months the city sees that corral usage is low. In fact, some providers have not even bothered to show the corrals in the app. To address this, the city might wish to express a Rule with a list of stops that requires providers to expose these stops in their app. This might work similarly to how Policy currently requires helmet law notifications.

3. Another 3 months go by and the city is still getting complaints downtown. To address this, the City decides to make a 25 cent fee for parking outside corrals downtown. They do this by adding a Rule for a 25 cent parking fee downtown, and a separate Rule making a 0 cent parking fee in corrals.

Each of these three stages, corrals are in some sense optional or recommended. An optional or recommended field isn't needed to express this fact – and might in fact be confuse the situation since 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.

[tybaltspark]

I think where the discussion lies is whether the Policy API has been designed as an actual Policy expression which could then either be an enforced regulation or recommended course of actions to allow changes of behavior.

For context, most European countries / cities have (for now) rather loose legal frameworks around the regulation of shared micro-mobility. Hence, by conveying that the Policy API only expresses legally enforceable rules, most cities would not take the risk to actually express the right policies to better manage micro-mobility. These policies have indeed no legal backing. Most cities have today a loose code of conduct with operators.

It is crucial for cities to engage into the policy API, but conveying only rules that are legally enforceable will diminish greatly the range of use cases and hence the popularity of the policy API in Europe.

Some cities have also expressed the wish to test policies and monitor behavior of operators/riders. However without the right regulatory framework, most cities will prevent from trial & error on developing new policies. Regulatory bills have a 1-2 year cycle. This is an eternity for micro-mobility management.

Two examples below:

1 - City A in the UK sets parking areas as part of their tender. The operators and the city agree afterwards to set Incentivised Parking Zones (IPZ). Those IPZ are not part of the tender, however both wish to apply it. The Transport Authority cannot enforce it legally since the tender requirements have passed already. The good course of action would then be to express a policy to the operator that is not legally enforceable, but still part of the iterative policy management process of the authority.

2 - City B in Sweden has analysed that most of the fleets are getting deployed in the two central districts. The new mayor election comes at the end of next year and no new regulatory bill will be issued for another 12 months. The city wishes to test a fairer distribution by communicating to operators min fleet size in outskirt neighbourhoods, however can't make it enforceable (i.e. as part of the permit). The city will then communicate the new policy to operators relying on their goodwill to apply it until the new bill passes.

[schnuerle]

@tybaltspark In scenario 1, can the city as part of their tender specify that operators agree to use the MDS Policy API as published by the city? Then the city can change it as needed, and the operators can abide by it and the 3 scenarios laid out by @quicklywilliam would be possible without having to wait 1-2 years for the regulatory bill cycle.

It seems like the City A and City B examples can be expressed in MDS Policy. Is there something with the way tenders work that is preventing this? How does the proposed necessity field help with these scenarios?

[tybaltspark]

@schnuerle yes, they could/should specify to use the Policy API as well as the policy requirements. But here you suppose two things:
1 - the city sets tenders - the most advanced regulatory framework so far
2 - they have enough maturity to know the Policy API and know all the policy requirements they would wish to set-up in advance

You are right they can be expressed by the policy API technically, but not within the regulatory framework of the city.
As a consequence, only cities with tenders and a thorough regulatory framework will use the policy API.
In my examples, both cities will be able to test policies with a field called recommended or test, progress in their understanding of policy management and use of the policy API without being outside the law.

[schnuerle]

Per the final release discussions yesterday, agreed that this needs more conversations and move to next release.

• Need cities to consider legal considerations of requiring all policy, especially in Europe
• Need cities in the discussion for use cases and how this could be implemented, especially in Europe
• Is there liability for cities by publishing Policy API and implying that everything listed is required by law?