Role system - Revision history

TiberiusB at 19:29, 19 April 2026

2026-04-19T19:29:05Z

TiberiusB: /* Implementation */

2026-03-17T23:30:04Z

Implementation

TiberiusB: /* Implementation */

2026-03-17T23:29:27Z

Implementation

TiberiusB: /* See also */

2026-03-17T23:28:12Z

TiberiusB at 23:27, 17 March 2026

2026-03-17T23:27:47Z

TiberiusB: /* Praxis */

2025-07-13T17:33:07Z

Praxis

TiberiusB: /* Praxis */

2025-07-13T17:31:15Z

Praxis

TiberiusB at 16:41, 9 February 2024

2024-02-09T16:41:21Z

TiberiusB at 07:42, 19 November 2022

2022-11-19T07:42:01Z

TiberiusB: /* Organizational determinism */

2022-11-19T07:39:51Z

Organizational determinism

@@ Line 1: / Line 1: @@
-A system designed to surface/identify [[roles]] and relationships among them, to describe [[requirement]], [[access]] to roles ([[credentials]], authorization), incentives for adoption of roles (role allocation, i.e. skills allocation to [[processes]]), commitment/accountability/responsibility, [[authority]] (temporary and contextual in the case of OVN)
+A system designed to surface/identify [[roles]] and relationships among them, to describe [[requirement]], [[access]] to roles ([[credentials]], authorization), incentives for adoption of [[roles]] (role [[allocation]], i.e. skills [[allocation]] to [[processes]]), commitment/accountability/responsibility, [[authority]] (temporary and contextual in the case of OVN)
 =Organization=
@@ Line 22: / Line 22: @@
 =Flow of agents to roles=
-Requires: [[requirement]], [[access]] to roles (credentials, authorization), incentives for adoption of roles (role allocation, i.e. skills allocation to [[processes]]), commitment/accountability/responsibility,  [[authority]] (temporary and contextual in the case of OVN)
+Requires: [[requirement]], [[access]] to roles (credentials, authorization), incentives for adoption of roles ([[role]] [[allocation]], i.e. skills [[allocation]] to [[processes]]), commitment/accountability/responsibility,  [[authority]] (temporary and contextual in the case of OVN)
 As opposed to traditional [[organizations]], individuals are not appointed to roles in OVNs and other types of open communities. Moreover, one individual cannot monopolize a role for any period of time. Experience shows that in absence of formal/instituted power relations (no formal authority) there is no guarantee that the appointee will maintain his/her role (it is difficult to establish accountability) as promised or agreed upon. In some cases, one can experiment with appointing a given individual to essential roles, if these role explicitly bring with them some sort of rewards (money, reputation/influence, etc.), and if there is a mechanism to record the individual's commitment to the role and to make it public, and if there is a mechanism to punish failure to keep the commitment by affecting [[reputation]] or the ability to benefit from the system (through a [[benefit redistribution algorithm]] for example), or by other punitive mechanisms.

@@ Line 35: / Line 35: @@
 =Implementation=
-We believe that the proper implementation of the role system needs an ontology of activities and a method to extract patterns from logged activity, which are turned into [[roles]] and surfaced in real time. For example, some [[agents]] will only [[contribute]] with cash, financing infrastructure development and maintenance and/or specific [[ventures]]. That would be a strong pattern of engagement that would be linked to a [[role]] that could be named "financier", or "investor".
+We believe that the proper implementation of the ''role system'' needs an ontology of activities and a method to extract patterns from logged activity, which are turned into [[roles]] and surfaced in real time. For example, some [[agents]] will only [[contribute]] with cash, financing infrastructure development and maintenance and/or specific [[ventures]]. That would be a strong pattern of engagement that would be linked to a [[role]] that could be named "financier", or "investor".
 In the a Nondominium implementation of [[NDO]], roles are related to [[governance]] tiers (progressive trust levels):

@@ Line 35: / Line 35: @@
 =Implementation=
 We believe that the proper implementation of the role system needs an ontology of activities and a method to extract patterns from logged activity, which are turned into [[roles]] and surfaced in real time. For example, some [[agents]] will only [[contribute]] with cash, financing infrastructure development and maintenance and/or specific [[ventures]]. That would be a strong pattern of engagement that would be linked to a [[role]] that could be named "financier", or "investor".
 =Praxis=

← Older revision		Revision as of 23:28, 17 March 2026
Line 58:		Line 58:

	* [[Role map]]		* [[Role map]]
−		+	* See [https://docs.google.com/document/d/1hpvltcqUV_XxK-dmevkR6_G3fwG3mCG5yy6CQ55HMIY/edit Sensorica's original role document].
−	~~-----------~~
−	See [https://docs.google.com/document/d/1hpvltcqUV_XxK-dmevkR6_G3fwG3mCG5yy6CQ55HMIY/edit ~~SENSORICA~~'s original role document].

@@ Line 55: / Line 55: @@
 '''Kurt''': A [[role]] is a collection of competencies, accountabilities, authorities, typical activities and relationships.  A typical org chart calcifies these into a position which is then assigned to one person using a process that includes merit and politics, accidents and circumstances. The positional assignment is then scarcely revisited as stability is a goal in a fixed structure like an org chart. I would encourage you to consider fluidity in all role assignments.  To use [[roles]] as attributes and descriptively, not as investitures of power or exclusivity of ability to act. In particular, decision authorities should be algorithmic, based on an evaluation of skills and competencies required to make a decision (as well as other relevant factors, such as experience, tenure and others as decided in designing governance), not on the formal assignment of a role. In other words role "assignment" should be fluidly attributed (filled in real time based on an algorithm) redundant, and assigned to the maximum possible actors.  Quorum for a decision can be one or perhaps more of those who are qualified.
 -----------
 See [https://docs.google.com/document/d/1hpvltcqUV_XxK-dmevkR6_G3fwG3mCG5yy6CQ55HMIY/edit SENSORICA's original role document].

@@ Line 38: / Line 38: @@
 =Praxis=
-[https://docs.google.com/spreadsheets/d/1dx4W2zRqLMc21F_CiHiwHfIXHig6vQvo4pM9CBl0eqg/edit?gid=267898460#gid=267898460 Roles used by Sensoricans].
+[https://docs.google.com/spreadsheets/d/1dx4W2zRqLMc21F_CiHiwHfIXHig6vQvo4pM9CBl0eqg/edit?gid=267898460#gid=267898460 Liste of roles used by Sensoricans].
 =Discussions=

@@ Line 42: / Line 42: @@
 =Discussions=
-'''Ampie''': I think that, whilst the role topology must be flexible, there is a limit to how emergent a role can be. Yes, there is an emergent aspect to it. The assumption of a role by an agent/participant should be absolutely voluntary and based on a consensus reached in the collaboration. This is in line with the requirement that a collaboration should be self-organizing. Participants should be allowed to relinquish and change roles from one [[venture]] to a next. Roles should be fine-grained, and highly contextual. The work/activities associated with a role should be able to change and adapt over time, as long as there is consensus.
+'''Ampie''': I think that, whilst the role topology must be flexible, there is a limit to how emergent a role can be. Yes, there is an emergent aspect to it. The assumption of a role by an [[agent]]/[[participant]] should be absolutely voluntary and based on a consensus reached in the collaboration. This is in line with the requirement that a collaboration should be self-organizing. [[Participants]] should be allowed to relinquish and change roles from one [[venture]] to a next. Roles should be fine-grained, and highly contextual. The work/activities associated with a role should be able to change and adapt over time, as long as there is consensus.
-However, once an agent/participant performs a certain activity/work in a given collaboration such as a [[venture]], it would be fair of other participants to expect that agent/participant to also take responsibility for other activities.
+However, once an [[agent]]/[[participant]] performs a certain activity/work in a given collaboration such as a [[venture]], it would be fair of other [[participants]] to expect that [[agent]]/[[participant]] to also take responsibility for other activities.
 Example:
 In a collaboration, a certain type of [[venture]], one activity involves the request for a service. This activity is associated with a “Customer” role. Another activity associated with this role details the requirements that need to be fulfilled for the specific request before payment is done. Is it fair for the Customer to now refuse to take responsibility for that activity, because we want to keep the Customer role emergent? Is it wise to let someone else specify the requirements if the Customer is the one to provide sign-off before payment? I find it hard to see that it could be. Performing one activity should automatically imply a responsibility to perform other activities, and this responsibility is encapsulated by the role associated these activities.
-The roles that a participant has fulfilled over time will also guide us as to what kind of reputation metrics could emerge for that participant. A customer could have a reputation for providing solid, well thought through requirements. Providing requirements is not really expected from the “Programmer” role. It is very possible for a participant to fulfill the “Customer” role on one [[venture]], and the “Programmer” role on the next, in which case that participant would indeed have a reputation score for his/her ability to provide solid, well thought through requirements. But it would not make sense to evaluate a participant that has never fulfilled the “Customer” role for his/her ability/tendency to provide solid, well thought through requirements. In fact, it would be blatantly unfair to rate such a participant on his/her ability to provide solid, well thought through requirements, and such ratings are irrelevant, destructive and should be disallowed.
+The roles that a [[participant]] has fulfilled over time will also guide us as to what kind of reputation metrics could emerge for that [[participant]]. A customer could have a reputation for providing solid, well thought through requirements. Providing requirements is not really expected from the “Programmer” role. It is very possible for a [[participant]] to fulfill the “Customer” role on one [[venture]], and the “Programmer” role on the next, in which case that [[participant]] would indeed have a reputation score for his/her ability to provide solid, well thought through requirements. But it would not make sense to evaluate a [[participant]] that has never fulfilled the “Customer” role for his/her ability/tendency to provide solid, well thought through requirements. In fact, it would be blatantly unfair to rate such a [[participant]] on his/her ability to provide solid, well thought through requirements, and such ratings are irrelevant, destructive and should be disallowed.
 '''Tibi''': In March 2013, during Lynn and [[Bob]]’s visit to Montreal, we had some discussions about the role system. In my opinion, the [[role]] is an emergent property of an [[agent]], that relies on all the [[activities]] recorded by the [[agent]]. Examples of activities are: writing, reading, demo, tutoring, traveling, R&D, meeting... See more examples in the [https://docs.google.com/spreadsheets/d/1bn6Nl07lLEIvQ65wacJ3QChMOQHl3PerrHS2_EiJzU4/edit#gid=0 Back office catalog spreadsheet] (precursor of the [[NRP-CAS]]) or [http://nrp.sensorica.co Sensorica's NRP-CAS]. A [[role]] is defined by a cluster of [[activities]] recorded by an affiliate, as you can find in the [[Sensorica]]'s old time log spreadsheet. Examples of [[roles]] are: animator, evangelist, engineer, … Thus, an animator would be someone that logs activities related to communication, organizing events, meetings, perhaps some traveling... The activity base of a [[role]] forms the reference of the [[role]], it in fact its semantic basis.

@@ Line 1: / Line 1: @@
-A system designed to surface/identify [[roles]] and relationships among them, to describe [[requirement]], [[access]] to roles (credentials, authorization), incentives for adoption of roles (role allocation, i.e. skills allocation to [[processes]]), commitment/accountability/responsibility, [[authority]] (temporary and contextual in the case of OVN)
+A system designed to surface/identify [[roles]] and relationships among them, to describe [[requirement]], [[access]] to roles ([[credentials]], authorization), incentives for adoption of roles (role allocation, i.e. skills allocation to [[processes]]), commitment/accountability/responsibility, [[authority]] (temporary and contextual in the case of OVN)
 =Organization=
-The role system starts with a set of predefined categories and lives space for emergence of new roles. An OVN is an adaptive structure, therefore the role topology MUST be flexible and emergent.
+The role system starts with a set of predefined categories and leaves space for emergence of new [[roles]]. An OVN is an adaptive structure, therefore the role topology MUST be flexible and emergent.
 The [[organizational structure]] is essentially the topology of [[roles]] within the OVN, plus the relationships that emerge between these [[roles]]. En emergent role system will result in an emergent [[organization]].

@@ Line 25: / Line 25: @@
 As opposed to traditional [[organizations]], individuals are not appointed to roles in OVNs and other types of open communities. Moreover, one individual cannot monopolize a role for any period of time. Experience shows that in absence of formal/instituted power relations (no formal authority) there is no guarantee that the appointee will maintain his/her role (it is difficult to establish accountability) as promised or agreed upon. In some cases, one can experiment with appointing a given individual to essential roles, if these role explicitly bring with them some sort of rewards (money, reputation/influence, etc.), and if there is a mechanism to record the individual's commitment to the role and to make it public, and if there is a mechanism to punish failure to keep the commitment by affecting [[reputation]] or the ability to benefit from the system (through a [[benefit redistribution algorithm]] for example), or by other punitive mechanisms.
 =Organizational determinism=
 OVNs and open communities become statistically stable and can prosper only if all the essential roles are filled with high probability. This require redundancy, i.e. at any given moment there are enough individuals in the [[organization]] that can occupy an essential role, so that the probability that someone (anyone who has access to the role) performs an essential task as needed becomes close to 100%. Open communities become unstable and are in danger of collapsing if there is not enough redundancy into the system to allow essential roles to be filled whenever needed. In other words, open communities require a critical mass to function properly. Usually this critical mass is around 150 affiliates or members.
 The ''role system'' incites [[voluntary subordination]] and thus it plays an important role in [[self-organization]]. By [[voluntary subordination]] we mean one's willingness to invest someone else with [[authority]] for a given time, in a particular context, based on hos/her experience, knowledge, [[reputation]], or just based on circumstances.
 =Implementation=