Skip to content

Raising Objections #81

@elenadimitrova

Description

@elenadimitrova

9.1 Raising Objections

The user raising an objection submits the following data:

  • the data that should be changed
  • the reputation(s) that should vote on this issue (a maximum of one from each of the domain and skill hierarchies)
  • proof that these reputations should be allowed to make the change in question.
    The first item identifies the subject of the objection, and what the initiator believes the state should be.* The second and third points concern escalation.

*The exact structure of this is dependent on the method used to implement contract upgradability. The function that uses it is likely to require being coded with inline assembly in the contracts, and require significant effort in the client to make it intuitive to generate and verify.

In Colony you cannot escalate a decision to higher management, you can only escalate to bigger groups of your peers.

For example, suppose that the objection concerns a task in the domain ‘development of our website’. The objector could choose to have all ‘development’ reputation vote on it — we say the decision was ‘escalated to the development domain’. In this example, the third point would be a proof that the domain ‘development of our website’ was indeed a subdomain of ‘development’.
The highest domain any decision can be escalated to is that of the entire colony, where all domain reputation is entitled to vote. Similarly, an escalation to the all-encompassing top-level skill allows all skill reputation to vote.
Whenever an escalation occurs, we need to ensure that the reputation we are escalating to is a direct parent of the reputation associated with the variable being changed. This is possible to do efficiently because of metadata that is placed on the reputations (for skills and domains) when they are created, which includes pointers to at least the direct parent.** When a user creates an objection, instead of directly specifying the skill or domain they are escalating to, they provide the steps needed to get there from the skill or domain associated with the variable that is to be changed.
This ensures that the skill or domain they escalate to are direct parents of those associated with the variable.

** Each reputation type contains pointers to its parent parent_id and its “nth parent” parent_n_id for all n that are powers of 2. See also Section 6.3

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions