Finally, Bivouac, the voting documents. Bivouac votes are represented in PLAINTEXT POLLS. These do not use advanced cryptographic PhD schemes, anybody who can decrypt the documents (typically the auditor role) can read your vote.

Why Vote

Just because you can do something solo (like forking a group), doesn't mean it's all that fun. It's nicer to agree to work on something as a team.

Philosophically, digital stuff can be forked as much as you like (especially in this petname system). Voting as a body of people forces limited options, bringing it back to meatspace where you can only pick some not all, either due to space, money, or volunteer time.

The different ways you can construct the voting options are because plurality is different from a majority. They're also because some decisions you want to unstick and take action (disallowing filibusters), while others you might want to stick (for example, core beliefs of the group or amending a constitution). It's your sandbox.

State Machine

Decisions in bivouac are represented in a turn (or "phase") based state machine. During a phase certain actions might be disallowed. For example, there might be a time period to propose Options. Later, the options would be locked in and it'd be time to vote on options. You may decide that late entries to options are allowed. Or maybe a petition once started must gather enough signatures before a deadline.

Each of these distinct phases goes through a full Cicada sync, for example any machines that need it can get all the submitted options in the first sync of the first phase.

Who Officiates

Bivouac votes only really need to end up at the people running the decision, you don't all have to mirror everybody's vote (you can if you have the ability to witness the votes).

Facilitator

Decisions are run by a facilitator role, that handles unsticking the state machine or moderating the debaters. They approve changes to Options and decide whether the new edit is in the same spirit as the old one that people already voted on.

Who Argues

Debaters may submit "option" documents, paths that voters may choose. Options define short wiki articles and Actions that will result.

When the options are created, debaters may discuss each other's options in "Argument" documents, one per each of the other debaters' proposals.

Facilitators may choose to allow facets of discussion (similar to multiple tables of data) by creating "Criteria" documents, for example allowing comments about budget specifically, and marking arguments that don't fit the table as off topic.

What Kind of Decisions

Decisions are great when they result in actions. Bivouac is kinda like an event bus, the state machine can listen for events and then change things based on what's subscribed to a vote or what action was picked.

You might be picking:

• a representative (even multi-member elections) verified by membership in the new role
• a change to group rules (verified by signing the new document)
• an outside digital action from a plugin (like talking to an API)
• a manual action (performed and then notes taken)

Choice Templates

Bivouac actions are taken using workflow templates called "Choices". These are templates that don't have a specific instantiation with dates/times or specific related language.

For example, a group might have a general "yearly representative election" choice that occurs in March, and a "petition to recall" choice that occurs when 50 signatures happen. Or, the admission of a new moderator might be a choice template :) - some choices might prohibit syzygy delegation or limit its reach.

Choice templates define what the boundaries are for a decision. When a particular instantiation of a choice is started, this is a "decision" document. It has the dates of the particular phases, the crew lists, the Mores ACLs, etc - all pinned into a particular round of evaluation for that decision.

Choice templates detail a delta of days between phases, for example the minimum and maximum amount of times to wait for candidates. Facilitators can work within those ranges.

Decisions

A Choice template is taken to create a specific instance called a Decision.

Where a choice is like a playbook, a decision is an individual run of that playbook.

A user could specify a threshold number of volunteers for the motion to pass, for example.

Decisions detail the exact start and stop days for each phase of action. Users have to act before those periods end or they miss the bus (or perhaps their default delegation is run if configured). The peers then render their sites after those days and pass around results.

Most decisions happen rather sedately (as in meatspace voting). However, some decisions need to happen rapidly (like moderation decisions). For those it makes sense for the mod to be pinged (via webmention) quickly, or for the mod to be contacted via another editor on the same machine, or some other method. Not settled on that.

Voting

When users are ready, they make "Selection" documents (one per user, enforced by a quirk of Cicada). Depending on the kind of election, that could be a direct proposal, or perhaps electing multiple representative users to a role.

Tagging still functions (it does on profiles or groups, too) - and users might base their delegation decisions on whether or not someone's tagged a particular option a certain way.

These are tallied into a summary by auditors, who can see who voted for what (bivouac is plaintext and dumb). You can see the example voting algorithms towards the bottom of the pages.

Actions

Putting it into Action

The results from the auditor role are transmitted to the evaluator role as defined in the original decision doc. That could be a virtual role that just points to a key being used to sign a statement, or perhaps an API being called to swap some property in the digital realm. Or maybe Ralph the admin gets emailed and needs to do XYZ physical action. Evaluators then produce a document showing they carried out the action. Decisions specify how immediate/live a decision is, and whether there's fully automated, manual approval, or fully manual actions.

Finished

At this point, observers can see the vote tally, and see that the options that won the decision were acted upon. The vote can be kept around, or discarded out of state.

Voting Algorithms

Selections are counted using an algorithm.

Depending on the voting algorithm, that could be first past the post, approval voting, ranked choice voting, threshold, lazy consensus, consent, etc. - a human may be involved in approving the results and hitting a final OK. Auditors release the summary of the votes, without who voted how.

Approval Voting

Approval voting asks users to check which options they're okay with. It's simple to understand, simple to count, and usually gives outcomes you'd expect.

RCV

Ranked Choice Voting votes record via an ordered ranking. They have some desirable properties but it gets complicated fast. Counting them is also hard to explain, as is picking multiple options.

Rated voting

Rated voting asks you to rate candidates. Unlike RCV, options can have the same rating.

Lazy Consensus

Lazy consensus for example is where:

• +1 - I like it and I'll help
• +0 - I like it but I can't help
• -0 - I don't like it, I have no alternative
• -1 - I don't like it and I'll help with this other thing

It's particularly interesting because it records willingness to volunteer for an option.

Zombie Votes

In delegated votes, a user may not delegate any lazy vote other than +0 or -0. That is, they may not "volunteer" a member on autopilot (called a "Zombie"). Similarly, when electing a Representative or a curator, who's liable to have an inbox of duties, they cannot be a Zombie representative. Users can, however, be passthrough zombies, so long as the entity they've passed through has decided they're a volunteer.

They can also be zombies for matters of simply what preference someone wants to display their wiki with (like tag views). These come into play when a user makes a mini list of say, "if all three of these users tag something XYZ, I'll consider it tagged that".

Each choice template needs to take a stance on what happens during non-response. This is related to Warnock's dilemma and tacid acceptance or acquiescence, or passive assent.

Consensus / Unanimous Votes

Consensus (or unanimous) votes work on the following options:

• yes
• yes, with concerns
• stand asside
• block (with reason) - these vetos typically come with conditions and aren't indefinite
  • reference a specific group core document or start a choice template document (e.g. could spin off to a threshold vote or turn the election into RCV if you're blocking for too many rounds)

During consensus votes, an issue is introduced and clarified, discussion is opened, ideas explored, proposals formed and amended, tested for agreement, and implementation is worked out. Blocking usually requires specific grounds and usually involves presenting a viable alternative.

Consensus votes are good for things like core principals of a group, where it's okay to stall on and not do a bad thing.

Threshold / "Four Eyes"

A threshold vote requires a minimum number of people to say yes, for example two mods must approve an admission. E.g. a two-man-rule system.

It's the opposite of consensus voting, where very few people are needed to block a decision. You're probably familiar with doer-approver systems and separation of duties.

You can also clarify that a decision must come from aprovers in two different roles (like one from role A and one from role B).

Coordinated "Random"

Where a decision uses sortion (random selection), it can either use truly random (e.g. random to each node), or seeded random (that will be the same on every rendered node). This is useful for example in decisions where you want to split 1/3 of say an inbox to preferably each user, and then on day two open up the overdue tasks to anyone in the flow, because it allows each node to deterministically compute how things will be split between nodes.

Playbook Chaining

Since decisions function like state machines, you can chain playbooks together into flows. You can also define things like circuit breakers or guard conditions.

Moderation flows could include parts that are encrypted only to moderators, or sections in meta-moderation or appeals where a user can see the decision and why, or can see the accusation but not the accuser. It depends how you build your decision flows.

The example on the next page details a meta-moderation playbook where someone can appeal a moderator decision!