Voting in Collection maintenance

You may be the only user of a Collection, the only person who uploads and downloads information. In this case, life is simple. But on the moment people are sharing data, life gets much harder: you need to organize access rights, put the data on a network location you can both see, and so on.

In complex situations, the decissions how to organize coorperation within a Collection requires agreement between the users. On various places, your configuration may introduce voting rules to facilitate cooperation.

Identities are traced

When the collected data gets more sensitive, —when other people or your employer start to depend on it— then the processes in the Collection need to get tightened more and more strictly. Especially around "who is doing what" with the data.

To be able to manage a Collection, all actions are taken for people with a known Identity. Identities provide authorization for actions. The process (server daemon) which runs the Collection checks the autorization. As user of collected data, you can check the Identities of owners, authors, and processes.

Critical transitions

In the process of maintaining data, there are quite a number of places where the managers of the Collection may want to keep control. Let me give some examples:

When a new Unit is created, the owners of the Collection may want to check whether the name is not an abusive word;
When a Unit with illegal content is reported, any owner of the Collection need to be able to withdraw the Unit;
When a new Unit is uploaded, the Author may want to have the release accorded by his boss;
When the Rules of the Collection change, then all its administrators need to agree. Or the majority needs to agree. Maybe only one.

The moments where people may want to intervene in the process are all related to steps in the life-cycle of a Unit (which contains the data where is decided upon).

Even in the case of the last example: remember that the Rules of a Collection are also kept in Unit inside that same Collection. It follows the same voting mechnisms are supported for any other Unit type.

Life-cycle state transitions

The Collection knows for every Unit the current state in its life-cycle. When the Collection Rules change, that state is re-evaluated for all Units.

When the Unit gets a new revision, then (of course) the state of that Unit gets re-evalated again. It may cause Units to appear or disappear.

Re-evaluation also happens when an Identity gives it consent for Unit state changes. Typically, the Identity sends a signature to the Collector administration as confirmation. The Collection maintaining process keeps track on these approvals.

Voting

Part of the Rules of the Collection, is a life-cycle state transition plan. The simplest plan is "Everyone can upload, publish, and remove Units without limitation". In a more complex plan, any owner of the Collection must consent with the name of the Unit first. And all authors of the Unit must approve the publication before it becomes visible.

Meshy Space Concept specifies various explicit ways how Identities can sign for their consent. In Base, we only define the effect of these signatures. How many signatures do we need? From which pool of Identities? These decision are configured in the Collection's Rules, and can differ per name pattern and unit type (any boolean expression).

The vote expression has components:

"vote"
"by" some Identities or Identity-groups, being
- the authors of the Unit,
- the owners of the Unit, (default)
- the owners of the Collection,
how many:
- "percentage=50", at least half of the selected Identities,
- "percentage=100", all of the selected Identities, (default)
- "count=3", minimal three signatures
- "all-but=3", three may abstain, disagree, or lacking

Votes do are not only positive:

"yes", agree with the possible transition;
"no", disagree with the transition; and
"abstain": will not count.

When a Unit requires a vote, it is reported via the Collection to the people who can vote. It is configurable how reports are send. When you say "no" or "abstain", it will stop asking you for your attention.

You may also cast you vote for transitions which are not yet possible. For instance, you may agree for publication before the Unit is validated.

This could look like (exact syntax still under design)

json
xml

<let name="is-picture-type">
   unit.type like iana:MIME.image/*
</let>

<let name="is-picture-name">
   unit.name =~ '\.(jpg|jpeg|png|img)$'
</let>

<vote name="board-majority"
   by="ietf:Members.Board"
   percent="51"
/>
<unit-set name="pictures"
    selects="#is-picture-type and #is-picture-name">

   <change-unit-state
      name="vote-accept-name"
      from="ms:UnitState/Free"
      to="ms:UnitState/Reserved"
      satisfy="board-majority"
   />
   <change-unit-state
      name="vote-reject"
      to="ms:UnitState/Withdrawn"
      satisfy="vote-unit-owners"
   />
</unit-set>

{ "let" : [
   { "name" : "is-picture-type",
     "_" : "unit.type like iana:MIME.image/*"
   },
   { "name" : "is-picture-name",
     "_" : "unit.name =~ '\.(jpg|jpeg|png|img)$'"
   } ],
  "unit-set" :
   { "name" : "pictures",
     "selects" : "#is-picture-type and #is-picture-name",
     "life-cycle-plan" : "ms:LifeCyclePlan#simple",
     "change-unit-state" : [
       { "name" : "vote-accept-name",
         "from" : "ms:UnitState/Free",
         "to" : "ms:UnitState/Reserved",
         "satisfy" : "board-majority"
       },
       { "name" : "vote-reject",
         "to" : "ms:UnitState/Withdrawn",
         "satisfy" : "vote-unit-owners"
       } ]
   }
}

mark@overmeer.net Web-pages generated on 2023-12-19