You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Of course, without structure, a large colony could quickly become difficult to navigate due to the sheer number of tasks —– domains solve this problem. A domain is like a folder in a shared filesystem, except instead of containing files and folders, it can contain sub-domains and tasks. This simple modularity enables great flexibility as to how an organisation may be structured. A
toy example is shown in in Figure 1.
This compartmentalisation of activity provides a tangible benefit to the colony as a whole. When objections are raised, they can be raised to a specific level in the colony’s domain hierarchy. This means that people with relevant contextual knowledge can be targeted for their opinion, and that when a dispute occurs, the whole colony is not required to vote in the dispute. Rather, only members with the relevant experience are asked for their opinion.
It is ultimately up to individual colonies to decide how they wish to use domains — some might only use them for coarse categorisations, whereas others may use them to precisely group only the most similar tasks together, or even multiple tasks that other colonies would consider a single task.
We aim to provide a general framework that colonies may use however they see fit, and to only be
prescriptive where necessary.
In order to create a domain, the creating user must have sufficient reputation in the domain that will become a parent, and must stake a small amount of colony tokens. These thresholds will be larger than for task creation, as the creation of a domain is more significant than the creation of a task.
The token stake for creating a domain will be able to be claimed by the creator once a task has been successfully paid out inside the domain — this indicates the domain is legitimate. In the event of a dispute being raised over the creation of the domain, if the domain is determined to be spurious, the stake is lost and the creator loses reputation.
6.2.3 Bootstrapping reputation
We note that the same is not required when a new domain is created in a colony. We do not wish to allow the creation of new reputation here, as this would devalue reputation already earned elsewhere in the colony. This bootstrapping issue is resolved by instead using reputation within the parent domain, when a child domain contains less than 10% of the reputation of its parent domain.
A domain below this threshold cannot have domains created under it.
The text was updated successfully, but these errors were encountered:
4.2 Domains
Of course, without structure, a large colony could quickly become difficult to navigate due to the sheer number of tasks —– domains solve this problem. A domain is like a folder in a shared filesystem, except instead of containing files and folders, it can contain sub-domains and tasks. This simple modularity enables great flexibility as to how an organisation may be structured. A
toy example is shown in in Figure 1.
This compartmentalisation of activity provides a tangible benefit to the colony as a whole. When objections are raised, they can be raised to a specific level in the colony’s domain hierarchy. This means that people with relevant contextual knowledge can be targeted for their opinion, and that when a dispute occurs, the whole colony is not required to vote in the dispute. Rather, only members with the relevant experience are asked for their opinion.
It is ultimately up to individual colonies to decide how they wish to use domains — some might only use them for coarse categorisations, whereas others may use them to precisely group only the most similar tasks together, or even multiple tasks that other colonies would consider a single task.
We aim to provide a general framework that colonies may use however they see fit, and to only be
prescriptive where necessary.
In order to create a domain, the creating user must have sufficient reputation in the domain that will become a parent, and must stake a small amount of colony tokens. These thresholds will be larger than for task creation, as the creation of a domain is more significant than the creation of a task.
The token stake for creating a domain will be able to be claimed by the creator once a task has been successfully paid out inside the domain — this indicates the domain is legitimate. In the event of a dispute being raised over the creation of the domain, if the domain is determined to be spurious, the stake is lost and the creator loses reputation.
6.2.3 Bootstrapping reputation
We note that the same is not required when a new domain is created in a colony. We do not wish to allow the creation of new reputation here, as this would devalue reputation already earned elsewhere in the colony. This bootstrapping issue is resolved by instead using reputation within the parent domain, when a child domain contains less than 10% of the reputation of its parent domain.
A domain below this threshold cannot have domains created under it.
The text was updated successfully, but these errors were encountered: