Who decides when a governance process should end?

[gigxz]

There are a few ways a governance process can be "closed". It can either be closed by a human, or by a system. If it's closed by a system, I'm estimating that there are 3 categories of "conditions" that lead the system to close the process:

1. System closes the process because some condition related to time is met.
   • "7 days have passed"
2. System closes the process because some condition related to the outcome is met.
   • "one option reached at least 10 votes," "that was a single veto vote," "10 ballots were cast"
3. System closes the process because some condition related to the community met.
   • "half of eligible voters voted," "majority of active community members voted," "all of the trust-level-4 admins voted"

Finally, all 3 of these can be combined using conditional logic: "Close the vote if 3 days have passed, OR if 15 people have voted, OR if (it's Tuesday AND the majority of group X has voted)".

The "System" could be:

• The system where the vote is being administered (Loomio, Discourse, etc). I'm calling this the "Platform." OR,
• The system that kicked off the vote. This is the Driver. OR,
• Metagov, the governance layer between the Driver and the Platform.

The Driver should always be responsible for determining what the closing condition is, since it's the system driving the governance. But my question is –– does it necessarily need to be the Driver that is evaluating that condition against the current environment?

Current: The Driver decides when to close a process.

Currently, this decision can be made in several different places. Importantly, though, there is (sometimes[1]) a way for the Driver to decide to close a process. In order to support complex logic for this decision, the Driver needs to know the current outcome (votes cast so far), the community (who are the eligible voters, how many), and the time. I've been prioritizing this approach because it is in line with our general principle that "policies live in the Driver."

Implications for Driver complexity: If the Driver is implementing a policy like "close vote when 30 people have voted" then it needs to be aware of the latest outcome. This can happen via "pull" (Driver has some scheduling system that requests latest outcome from Metagov every X minutes) or "push" (Metagov notifies Driver each time the outcome has changed[2]).

[1] This isn't possible for all platforms. Certain platforms will function as a "black box" where you tell it to start a vote and just wait for the result. Other platforms will provide API access or webhooks for state changes (eg a webhook emitted when a vote is cast).
[2] Not implemented, but would be easy to add.

An alternative: Metagov decides when to close a process

If Metagov is responsible for evaluating the closing condition based on the current state, then the Driver can be less complex, because it doesn't need to know the state of the process at all times. It can just tell Metagov to start the vote, tell Metagov what the closing condition is, and give Metagov a callback URL to hit when it completes. With this approach, the governance process is opaque to the Driver. The Driver has less control, but the Driver doesn't have to implement so many things (like the scheduler, which is not trivial).

This approach is only feasible if the conditional logic for "when-to-close-this process" can be represented as JSON, or as a DSL (Domain-specific language). Here's a rough example of what I mean by representing that conditional logic in JSON:

      ```python
      metagov.start_process(
          name="discourse.vote",
          parameters=parameters, # information needed to construct the vote, like what the options are
          closing_condition={"conditions": [{"type": "minimum", "count": 15, "option": "vote-option-1"}]}
      )
      ```

I don't think this is feasible right now, because it seems like we'd need a pretty complex DSL to really be able to express all of the useful closing conditions. Also, I'm not convinced that these closing conditions I've laid out are really are a closed set. There may be other data required to evaluate the closing condition that I'm not considering right now. SO, we should still leave it open to allow the Driver to close processes.

However, we could add some simple closing conditions. We already do this with the closing_at parameter. Are there other simple and common closing conditions that we can implement in Metagov, to shift some complexity away from the Driver for the simplest cases?

[thelastjosh]

Yes, that closing_condition clause does seem like it could get very complicated, very quickly. I see the reason to support simple closing conditions, but don't most voting / polling applications support their own logic for closing? E.g. see Loomio. Why is this a decision that either Metagov or the Driver has to make?

…

On Wed, Apr 28, 2021 at 4:21 PM Miriam Ashton ***@***.***> wrote: There are a few ways a governance process can be "closed". It can either be closed by a human, or by a system. If it's closed by a system, I'm estimating that there are 3 categories of "conditions" that lead the system to close the process: 1. System closes the process because some *condition* related to *time* is met. - "7 days have passed" 2. System closes the process because some *condition* related to the *outcome* is met. - "one option reached at least 10 votes," "that was a single veto vote," "10 ballots were cast" 3. System closes the process because some *condition* related to the *community* met. - "half of eligible voters voted," "majority of active community members voted," "all of the trust-level-4 admins voted" Finally, all 3 of these can be combined using conditional logic: "Close the vote if 3 days have passed, OR if 15 people have voted, OR if (it's Tuesday AND the majority of group X has voted)". The "System" could be: - The system where the vote is being administered (Loomio, Discourse, etc). I'm calling this the "Platform." OR, - The system that kicked off the vote. This is the Driver. OR, - Metagov, the governance layer between the Driver and the Platform. The Driver should always be responsible for determining *what* the closing condition is, since it's the system driving the governance. But my question is –– does it necessarily need to be the Driver that is *evaluating* that condition against the current environment? *Current: The Driver decides when to close a process.* Currently, this decision can be made in several different places. Importantly, though, there is (sometimes[1]) a way for the Driver to decide to close a process. In order to support complex logic for this decision, the Driver needs to know the current *outcome* (votes cast so far), the *community* (who are the eligible voters, how many), and the *time*. I've been prioritizing this approach because it is in line with our general principle that "policies live in the Driver." *Implications for Driver complexity:* If the Driver is implementing a policy like "close vote when 30 people have voted" then it needs to be aware of the latest outcome. This can happen via "pull" (Driver has some scheduling system that requests latest outcome from Metagov every X minutes) or "push" (Metagov notifies Driver each time the outcome has changed[2]). [1] This isn't possible for all platforms. Certain platforms will function as a "black box" where you tell it to start a vote and just wait for the result. Other platforms will provide API access or webhooks for state changes (eg a webhook emitted when a vote is cast). [2] Not implemented, but would be easy to add. *An alternative: Metagov decides when to close a process* If Metagov is responsible for evaluating the closing condition based on the current state, then the Driver can be less complex, because it doesn't need to know the state of the process at all times. It can just tell Metagov to start the vote, *tell Metagov what the closing condition is*, and give Metagov a callback URL to hit when it completes. With this approach, the governance process is opaque to the Driver. The Driver has less control, but the Driver doesn't have to implement so many things (like the scheduler, which is not trivial). This approach is only feasible if the conditional logic for "when-to-close-this process" can be represented as JSON, or as a DSL (Domain-specific language). Here's a rough example of what I mean by representing that conditional logic in JSON: ```python metagov.start_process( name="discourse.vote", parameters=parameters, # information needed to construct the vote, like what the options are closing_condition={"conditions": [{"type": "minimum", "count": 15, "option": "vote-option-1"}]} ) ``` I don't think this is feasible right now, because it seems like we'd need a pretty complex DSL to really be able to express *all* of the useful closing conditions. Also, I'm not convinced that these closing conditions I've laid out are really are a closed set. There may be other data required to evaluate the closing condition that I'm not considering right now. SO, we should still leave it open to allow the Driver to close processes. However, we could add some simple closing conditions. We already do this with the closing_at parameter. Are there other simple and common closing conditions that we can implement in Metagov, to shift some complexity away from the Driver for the simplest cases? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#25>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACHA5PBCYQCOCJ7DESUEWPTTLBU6LANCNFSM43XYXISQ> .

-- http://www.joshuatan.com/research/

[gigxz]

I haven't seen any examples of voting software that support closing logic beyond simple time frame ("close at XYZ date and time").
I'm assuming that people do want more complex closing conditions, but maybe I'm totally wrong about that.

[shaunagm]

There's a bunch of really interesting questions here. I'm going to try to take them one by one.

1. Is the set of closing conditions (outcome, timeout, manual, or some combination of the three) exhaustive?

I don't know if it's exhaustive, but I think it covers enough initial use cases for us to treat it as exhaustive for now. I don't see why doing so would necessarily prevent us from incorporating more conditions/triggers in the future.

2. Can Metagov help a driver to determine when closing conditions on a process are met?

I think the answer to this is yes. For one thing, while many third party plugins don't have anything beyond timeouts or manual closing to end a decision process, some more complex ones do. At least, Kybern does - and we'd talked before about creating a Kybern plugin so its resources and decision processes can be used even if something else like PK is being used as the driver. Just to give an example, Kybern has a "loose consensus" decision process that let's you optionally specify a minimum time, or lets specified users manually end it; it also determines whether the decision passes or is rejected based on whether anyone is for it, and/or if there are blocks (people can be against without blocking). The Driver should be able to override this logic, but it should have the option of simply accepting the plugin's logic.

MetaGov could provide a standardized template for third party plugins to pass along information about the decision process, perhaps as an arbitrary dictionary (like { decision_started: date, participants: [1,2,3,4], blocks: 0, approves: 3, stand aside: 1, no choice: 2), as well as the overall status, as status_on_third_party_platform or something less verbose. The Driver could then choose to accept the third party's assessment of status, if it exists, or examine other information, including the arbitrary json dict passed along by metagov, to make its own determination of status.

3. Can Metagov go beyond passing along information from the plugin process, to guess at the status when it's not provided by the plugin?

This seems doable to me, although I'm a little wary of giving this information a third place to live. The other thing is that it doesn't seem like a very high priority, as much as creating a governance DSL sounds fun.

The simpler option seems to be to help the Driver avoid complexity by creating a more robust decision-making plugin library, and creating a standardized process by which the Driver can comfortably accept the third-party's decisions.

If we want to then add some logic in MetaGov itself, to help the Driver even in the absence of help from the plugin, I think it's ok to start with very simple cases, like timeouts, and add coverage from there.

[gigxz]

1. Is the set of closing conditions (outcome, timeout, manual, or some combination of the three) exhaustive?
   I don't know if it's exhaustive, but I think it covers enough initial use cases for us to treat it as exhaustive for now. I don't see why doing so would necessarily prevent us from incorporating more conditions/triggers in the future.

I was asking because, if there was a closed set of simplistic closing conditions–– say, if the only way voting periods ever ended was either due to Time or Number-of-votes –– then we could define a standardized template for it. That would allow us to make Metagov(incl Plugins) always be responsible for evaluating closing conditions, and the Driver would never be responsible for it. we could entirely remove the capability for the Driver to close ongoing processes (currently it can close a process by invoking DELETE /process/[id]). That seems somewhat desirable because the Driver is spared from this responsibility. But I don't think we should do this, because it closes off expressivity in the driver, which may want to apply arbitrarily complex closing conditions.

2. [..]MetaGov could provide a standardized template for third party plugins to pass along information about the decision process [...] The Driver could then choose to accept the third party's assessment of status, if it exists, or examine other information, including the arbitrary json dict passed along by metagov, to make its own determination of status.

I agree with all of this. Definitely, Metagov should define a standard template for vote "outcome" (which is the current result from the vote, not necessarily the end result. maybe I should rename in the code..). GovernanceProcesses can optionally adhere to that type, or they can define their own. Right now, the outcome field on GovernanceProcess can be any JSON blob, but I've been using this shape for all the voting plugins:

```
{
     "vote_url": "https://...",
      "votes": {
             "vote option one": 10, # vote "option" to number of votes
             "vote option two": 2,
 }
```

As far as coming up with a standard type, the Loomio data model (built around a unit called a "stance") is worth looking at - actually @thelastjosh is already mapping out their model.

From a UX perspective I'm worried about vote statuses being different in different systems, but I think it can be mitigated if the Driver is appropriately communicative. Also, the extent to which Driver/Metagov/Platform have mismatched statuses is dependent on what the "voting platform" makes available via API, because we won't necessarily be able "close" the vote on their system from Metagov. So that is not fully in our control.

3. Can Metagov go beyond passing along information from the plugin process, to guess at the status when it's not provided by the plugin? ...

Agree it's not priority at all, and that we can start with the very simple cases like timeouts. I think PolicyKit is a great tool to experiment with because we can see if any patterns emerge for the logic around when to close a process.

To make it suuper concrete, in PolicyKit, the existence of the "closing_at" input parameter lets the author write a policy that looks like (B) instead of (A).

# A: Driver evaluates closing condition

#initialize - gets called once
metagov.start_process("my-vote", {...})

#check - gets called on a schedule (or later, could get invoked by webhook notification that the "outcome" has changed)
if action.proposal.get_time_elapsed() > datetime.timedelta(minutes=60):
    result = metagov.close_process()
    yes_votes = result.outcome["votes"]["yes"]
    no_votes = result.outcome["votes"]["no"]
    return PASSED if yes_votes >= no_votes else FAILED

# B: Metagov evaluates closing condition

#initialize - gets called once
metagov.start_process("my-vote", {"closing_at": "2022-01-01", ...})

#check - gets called on a schedule (or later, could get invoked by webhook notification that process is closed)
outcome = metagov.get_process()
if outcome.status == "completed":
    yes_votes = result.outcome["votes"]["yes"]
    no_votes = result.outcome["votes"]["no"]
    return PASSED if yes_votes >= no_votes else FAILED