Should ballot be only always on ?

[virgile-dev]

In the paper we describe the different caracteristics of [Issues](https://github.com/DemocracyEarth/paper#253-issues)

One of them is Timespan which can be of 2 types:

• tactical: voting on decisions happen limited in time (has a closing date)
• strategical: voting is always on

Recently the tactical nature of issues were removed from Sovereign's code which has led us to a lot of really interesting thinking. Here are some excerpts of conversations about this on slack.

Santi's take on it

our design currently contemplates never-ending issues: makes the vote real time, without a closing date. this enables a couple of interesting things: prevents coercion, since its pointless to ask someone to change vote if it can be modified later on; and makes voting always strategical (ie: you might choose to take your vote out from an issue already being dominated 90%+ by an option). regarding enforcement: operating on the blockchain should make any budgeting very transparent. we are planning on incorporating budgeting tools in the app.

John Kune's take on it

Never-ending issues are also really great, I hope u guys will implement that. The system I proposed also uses that :-) it is IMHO also a much better representation of what we need: normal 'limited' issues mean we're setting things in stone after a deadline, and it's impossible to change later on. However, reality is much more fluid. The world is changing constantly around us, we're discovering new evidence for so many things, new technology enables us or brings new threats. Ask that can change someone's views about an issue, and in an e voting system it should be able to reflect that change! We should handle issues much more as status quo. (I guess the main/only reason why we have those deadlines on votes was historically that we simply can't do it otherwise?) Another point is that we actually want people to change their opinion based on the situation (with some weeks fluctuations evened out). I mean, we all know some people that just insist on something that's so outdated, and wish they could acknowledge the new evidence against that viewpoint. Having issues set in stone just enhances that stubbornness, while never-ending issues will hopefully achieve the opposite.

I would argue that in order to act upon a tactical decision it needs closing so we should leave the option to the user when creating its issue. A good example is with budgets, once validated and start spending the funds it's hard to go back.

So how about we include back into Sovereign the calendar component to allow user to choose an endate for their polls @DemocracyEarth/sovereign-development ?

[santisiri]

Julio Coco the Venezuelan dissident once said to me:

Santiago, what is politics to you?

I replied:

I don't know.. the art of the impossible?

He laughed and said:

No.. politics is one thing, and one thing only: what you say on a given moment in time.

Neverending means backwards accountability to where were you standing at a given point in time. That's the interesting thing about storing such positions on an immutable ledger no one else can corrupt.

@virgile-dev executing a budget is simply processing this specific kind of data. I think we'll see many creative ways of operating with the political memory we're building. From a feature perspective is simply using the ongoing condition (yes or no / true or false) of the ballot to something that drips crypto from A to B.

This mechanism (always on aka neverending) is far more powerful than analogue methods because it includes already includes all those use cases. And it's less complexity codewise.

[herbstephens]

Love the "backwards accountability" aspects @santisiri ... and thinking thru the mechanics of such vis a vis blockchains ... thinking, is it as simple as deducing democracy from the 'movements' within a blockchain over time ... with public addresses representing everything:

• individuals [physically verified via retina scan]
• organizations [agreed to by verified individuals only]
• choices [if token send TO choice address, FROM address 'agrees'] [created ONLY by verified orgs]

If later ... said individual sends token to different (opposing) choice address .. signals change of vote

This enables backwards accountability... no?

Better method to 'revoke' vote?

[RyanCwynar]

The strategical timespan seems like a way to put a policy issue into an experimental mode if enacted.

Seems like there would be several phases or states of such a proposal

1. proposal - whenever it's created and submitted, starts accumulating votes towards a quorum threshold of some kind
2. enactment - maybe proposals have to sit in review for... say a month before they're eligible to be acted upon if they reach quorum AND there was a "yes" consensus on the policy. otherwise it stays dead unless something changes that makes it more popular
3. deactivation - so a proposal has reached quorum and has been enacted, but then becomes unpopular and falls below the necessary threshold for public support and triggers a countdown to deactivation (maybe the policy has a month to regain popular support before it's deactivated)
4. solidification - maybe there's a threshold at which a proposal reaches high enough consensus at which it's "ratified" and no longer subject to the flux of daily opinion. At which point it's a tougher law to remove and a new proposal is required to repeal it.