User:Conseo-Polyc0l0rNet/Resource management

Some general theoretical thoughts on how vote-based resource management could be applied to economical problems.

The resource management is build upon Votorola's counting structure.

If you have anything to add or criticize, please contribute on the discussion page!

Technical design

My main concerns are about how to tie resources and plan targets to votes and how should these add up and match certain targets in the tree. How to combine economical formal structures with the formal structure of a vote (consensus) tree in a way which allows to let the voter express the intentions clearly?

General design questions

1. How will pledges propagate to an account of her candidates and how are counts calculated? (If I pledge for an account, but me or one of my candidates shifts their vote away from the position where the account is used, how should the counting react?)

Resources in contrast to votes (consent) are finite real objects, which can only be used once. What happens to up-roots positions (and summations in there accounts) if a plan in the tree gets executed (it's resources get used)? At the moment we assume that the nearest candidate (down-root) can enact a plan if it fulfills it goals.

1. How should targets be defined?
2. How to deal with overflow of pledges?

We can assume for now, that they stay in the account and are available for candidates down-roots (top-level plans).

1. How to define a structure for conditions of the pledges? (e.g. return of money with some interest rate, free sample of the produced product once the plan is realized)

More specifically we can also say it is the negative of a pledge, a condition necessary to draw a vote.

1. Do we have to allow blocking of votes then?

At least the problem is that false friend voters can bind their votes to conditions unfullfillable by the community.

1. How to pledge for different accounts having the same type (e.g. money or US$)? (this could also be pledges for the whole plan, filling any possible gaps in any of the targets defined)

Long term perspectives to speculate about:

1. How to mirror pledges done elsewhere? (e.g. kickstarter.com and other funding sites)
2. How to extend our trust network with "resource-dependant trusts" by counting the amounts of each resource type an identity has brought in, including labour? This will allow to judge the reliability and identity of persons engaged as they show more and more commitment for the polls. NOTE: This is not a replacement for the Streetwiki approach to general trust in the identity, but rather an additional way to verify that the pledged resources for a vote are trustworthy and a pledger is not overestimating her commitment.)
3. Are there possible banking services for the vote server, e.g. booking pledges and ensuring their availability?

Agenda

1. Find a way to define targets for accounts. (backend, SemanticMediaWiki)

Done by Mike. Pledge

1. Visualize the progress between the pledges and their target in the TrackStacks (frontend, GWT-Gui, general GUI widgets as concept)
   1. Find out how to list several accounts without adding unnecessary clutter. (smart arrangement of account information depending on selected position in TrackStacks)
2. Think about addressing conditions, first as a simple property and possible side effects (this can be modularized with seperate counting methods to some degree)
3. Test case some business models with respective polls for each plan
4. (Make this page itself a long-term poll and allow people to dedicate resources to realize new enterprises with these mechanisms)

Current design

The current design is based on the superaccount concept below.

1. The pledge counting follows the vote count.
2. Counting methods can be defined for different numerical representations of resources (money, special labour rules, binary logic, ...)
3. Accounts are defined for each resource to be pledged and are defined in the domain of a position.
4. Pledges are mapped to an account by their resource type or purpose (e.g. US$)

Counting methods

The modularity of having different counting methods is supposed to allow different resource accounting for each possible resource. It is possible to design the structural models within distinct counting methods, but the decision of structural models is actually higher level and might need an additional concept of modularity.

Structural Models

No flow, manual assignment

Following the principle of KISS, which means for us to always empower the user and remove complicated design mechanisms which might alienate the user, we simply allow to pledge directly to any account and nothing else. Pledges are counted for the account they are assigned to and that is it. That way the voter herself has to reflect how her resources are best assigned to the project. The voter is more intelligent than any mechanism and knows best where to pledge and how to shift/engage, since she understands the drafted text and the context of the pledge through the position.

Advantages

• Resources get never assigned automatically in a way which might misfit the position of the voter. Instead they become invalid until they are reassigned.

Disadvantages

• Pledges of all voters down the candidate shifting her vote will become invalid until they adjust their pledges. This can render the pledge counting pretty useless, depending on the speed of fluctuations/shifts.
• Endcandidates might have no resources, although they are scattered around to positions further down the tree. Voter's have to assign resources to their accounts directly to make the plan realizable. This has the advantage that for the plan to become executable every voter has to understand where her resources will be in the endcandidates position.

Indeed this seems like some kind of verification, but is off-topic since it has to be done for every account and for every higher level agreement. Better is to allow the user to confirm pledges before they are taken once when the plan is going to be realized.

• Huge polls will need a lot of administrative work of all candidates to become executable.

Again, this is disqualifying such an approach.

Superaccounts as static categories (current model)

Instead of pledging for a specific account, you pledge for a superaccount which is shared by the account you want to pledge to. No matter where in your upstream candidates the account is defined, the superaccount will ensure that your pledge will be assigned to the next account upwards which matches its definition. The superaccount itself is not counted, but only accounts towards different endcandidates which match the superaccount.

Advantages

• Pledging for a superaccount keeps the pledge valid during vote shifts.

Disadvantages

• Super accounts might match to different resources, making assignment after vote shifts random/contextless.

Generic superaccounts which are defined by resource type (e.g. money) or even unit type (e.g. $US ) unify very different instances of resources, which can lead to unwanted resource assignment. (E.g. I want to support the playground with some money, but the superaccount mapping assigns my pledge to organisational expenses I don't explicitly want to support after I shifted my vote.)

• Not routing the resources is a break from the delegational structure below it. While this is because resources are finite real entities, not flowing through nodes, but being consumed by them, just taking them at the lowest candidate in form of a superaccounts seems like a limitation in delegation. In fact it models resource flow as a grass-roots activity, never contributing to the top level (end-candidate's) plan's accounts, which can be necessary to smooth the process.

Possible Solutions

• Don't define superaccounts by type, but by purpose. This weakens the generalisation of the "super-category" idea a bit, but centers around the meaning of the pledge. NOTE: To properly calculate the amount pledged, types need to be accounted properly. So you could pledge in any currency and the counting engine would add that up in the target unit type (e.g. US$). This target type must be defined in the account and not the superaccount.

Routing of pledges to upstream accounts

Each account can define one or more upstream accounts it maps to. That way accounts can be fine grained and explicitly assigned to more generalized or specific upstream accounts.

Advantages

• The drafter herself decides to map to certain accounts in her own account definition. As long as upstream accounts match one or more of the mappings, resources flow upwards. But they are only directly available for the next candidate's account up-roots.
• This also means that upstream assignment does not happen automatically, but can be discussed with your candidate directly and not with candidates further away.
• This also means that one can always say where a resource is pledged (at the the end of the route). This means that positions voting for the endcandidate's position can decide to keep (not route) resources, if they define distinct particular plans or parts, which might be enacted independently once they reach the necessary consent conditions.
• There is no necessary superstructure in form of superaccount categories which need to be shared by as many positions as possible to make routed resource management feasible, since routing can allow additional unification of specific accounts to more general ones inside the tree, while superaccounting would still allow a unification for easier vote shifts.
• Routing can fine grain the amount of resources pledged upwards specifically, allowing chosen counting decisions (even mechanisms are imaginable) in each node of the tree.
• You don't need to study the whole poll to understand which superaccount you should use, rather you simply decide how your pledges map to your candidates position and you are done. You can still check where your candidate's decisions lead the pledge to (the end of the route).

Disadvantages

• Routing allows to reassign resources to a different purpose up-roots, which has to be understood by the voter. But this is no different then to follow your candidate's voting decision and carefully study your endcandidate as this is where your vote lands by the very means of delegation. Not delegating resources is biased against a particular organisational grass-roots structure. Whether routing (within delegation bounds) can fullfill delegational intentions is arguable.
• The overall structure of the resources is less common, making comparisons of different endcandidates more difficult. NOTE: Endcandidates could still share superaccounts to make them somewhat comparable. Still this needs a structural agreement.