Role system
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 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.
With respect to infrastructure
A module of OVN infrastructure.
The Role system must interface with the individual profiles and has write access to them. The contribution accounting system, reputation system and role systems must interact with each other.
Roles (+reputation) can be modulators in the benefit redistribution algorithm. In other words, a group of affiliates collaborating on a venture can decide to weigh time contributions according to the type of activities performed (according to the role played). Thus, {one hour of engineering work} can be evaluated at 2 x {one hour of manual labor}. It is up to the group to decide how to use roles in the benefit redistribution algorithm. The NRP-CAS allows for any kind of arrangement, from egalitarian to very meritocratic.
The contribution accounting system records and evaluates every affiliate's input, or contribution. Revenue is calculated in terms of affiliate's contributions. Se also the value system page.
The reputation system incentivizes good behavior within the OVN and helps to focus attention. It plays an important role for the performance of the OVN by filtering agents for adequate tasks. It also informs the service system.
All these systems are necessary to induce tight self-organization within an OVN, and to render the network creative and productive. These systems are also designed for network-to-network interface.
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)
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.
The role system and digital identities
The role system can be used to construct digital identities.
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
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
Todo ---> Tibi fix this link See a simple implementation of the role system implemented on Sensorica’s website.
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. 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.
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 Back office catalog spreadsheet (precursor of the NRP-CAS) or 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.
Joshua from Enspiral [captured by Tibi during a conversation]: It is desirable to have pre-established roles, rather than totally emergent, because as soon as someone puts a role hat on information starts flowing towards this individual in a preferential way. Joshua also distinguished between Roles (accountability, responsibility and metrics, like facilitator, coordinator...) and Crafts (skills, like engineer, designer…, somewhat independent of context).
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.