Particip.io Realities
This white paper is a continuation of the work that was done when Realities was a project run by the Borderland community. Some content relevant only to that community has been removed, other clarification have been added. This post is the current reference for the Realities project since it was brought into Particip.io.
I. What is Realities?
We’re building a tool for decentralised organizations to track keep track of their structure while helping them make decisions. This particular tool uses the Advice Process and TEAL organisations as it’s point of departure. In such organisations, work is not organised in a top down way. Instead, everyone in the organisation is allowed to make decisions as long as they seek advice from key stakeholders. Identifying those stakeholders and making sure you’ve sought their advice can be cumbersome and difficult, especially without deep knowledge about an organisation. Realities is a tool which aims to meet that challenge.
We don’t want top-down leadership, but we recognize that an organization can’t be leaderless. We want to build a tool that makes it as easy as possible for community leaders to find and claim their place, and in doing so, change the very structure of the organization. We also want to make sure that if they leave, the structure doesn’t collapse in their absence.
II. Mission statement
We will develop a software system that helps people in a decentralised organisation plan and execute projects without traditional top-down management. As to not make the use case too abstract, we will use the organisation The Borderland and its participants as our user group and develop explicitly for them, while not adding features that are only relevant to that organisation. Realities should give users the ability to create Needs and then Responsibilities and to assign a Guide and a Realiser to each Need and Responsibility. Needs and Responsibilities are connected by Dependencies which clarify how they are connected. Creating and assigning Needs and Responsibilities and connecting them with Dependencies should be simple and intuitive. The UI of the software should also transparently indicate the correlations of these elements to each other for a faster overview of the larger scope, for example by drawing graphs and connecting them to each other.
III. Introduction to strange and unusual words
Reading the following list of terms will give you an idea of how the parts of this project fit together. This glossary is not definitive, and it is specific to the Realities project. It is just a way for us, who’re working on the project, to sync our shared vocabulary.
The Borderland: The Borderland is a participatory event, a collaborative community where we co-create events and gatherings as prototypes for our dreams. It is an empty container, open to your initiative. It is an invitation to play, to reflect, and to engage. The event is for co-creators only, and not open to spectators. “The Borderland” refers to the borderland between dreams and reality. We use the Borderland as an example organisation when developing Realities.
Borderling: A participant of the Borderland is a Borderling.
Dream: A Dream is something that one or many Borderlings want to bring to the Borderland. Dreams can include but are not limited to art projects, events, workshops, spaces, or any of their combinations which can go as far as the imagination of the dreamer takes it.
Dreams Platform: A web based system for prototyping, planning and funding Dreams for the Borderland. First developed by Borderlings, but now developed and maintained by an international community of Burners.
Dreamer: A Borderling who brings or wants to bring a Dream to the Borderland.
Dream Guide: A Borderling who helps Dreamers get their Dreams ready for funding on the Dreams Platform by helping them follow guidelines. Guides can enable the process of receiving the grants for Dreams on the Dreams Platform. Some Dream Guides are also admins on the Dreams Platform.
Dream Admin: An administrator on the Dreams Platform. Dream Admins can edit and remove Dreams on the Dreams Platform, manage users and add or remove grants.
Reality: Something that must happen or exist at the Borderland so that the Dreams can be brought to the event.
Realities Platform: A planned web-based system which helps Borderlings define what Realities must be realised, who is releasing them, and how these Realities connect to each other.
Need: A concrete and defined condition that needs to be true for Borderlings to create their Dreams.
Responsibility: A role or task that a Borderling can assign herself which partially or completely fulfils a Need.
Dependency: A directed relation between a Need and Responsibility, between two Needs or between two Responsibilities. When a Borderling wants to make a decision that will affect a Responsibility, she can look at Dependencies to see who could be affected by this decision.
Realiser: A Borderling who is assigned either to coordinate many Responsibilities needed to completely fulfill a Need, or to carry out a Responsibility.
Reality Guide: A Borderling who is assigned to make sure that a specific Need or Responsibility has an active and competent Realiser. This may include defining requirements and headhunting for a fitting Borderling. Reality Guides will be a collaborating group of people that coordinate their efforts and support each other in this work.
Reality Admin: An administrator on the Realities Platform who can edit and delete Needs, Responsibilities and Dependencies as well as remove Borderlings from roles as Reality Guide or Realiser. Most Reality Guides should also be Reality Admins.
IV. Why are we doing this again?
The project we are now getting ourselves into is creating a frame for the organisational aspects of the Borderland. We sometimes say that we organise the Borderland through “Consent-based Do-ocracy”. That means that the power to decide on activities rests with those who are going to execute them. In order to do this skilfully and without stepping on other’s toes, the do-ocrat needs to gather perspectives of those affected by her decision, seek their advice, and take principled objections into consideration. By doing this, she becomes the best qualified in the community to take on (or take over) a responsibility, in part by gaining the knowledge and competence necessary, and in part simply because the act of connecting with those who are dependent upon them places them in the right position in the social network to act and influence what they need to. Thus, the Borderland is managed not through commands and control of a central authority, but rather by a network of contextual hierarchies based on the principle that power should flow to those who need it to take leadership. Realities are meant to facilitate this process. Along with the Reality Guides, the Realities Page is a module in a system where the Needs of the community can be processed into Responsibilities, supporting them to navigate the steps to flesh out their roles, ending in a clear set of accountabilities that they may execute. And also to provide structure and transparency so that these responsibilities may be handed over from those who find themselves unable to fulfil them to those who want to help, with minimal bureaucracy and confusion.
Realities is both a software platform and a process
Our current aim is to create a first iteration of a system based on the principles of organization that the Borderland has arrived at through vision and experience. Again, it’s important to note that this system isn’t just the Realities Platform and its users, but the platform, its users and its custodians and facilitators. Note the word facilitator - their role is to support and make things easier, not to manage. These Reality Guides may be viewed as the principal customers of the first version of the Realities Platform. Because of the artistic and individualistically expressive nature of our community, we are not expecting all our users to adopt a new platform and be able to use it from the beginning. Indeed, we don’t want to impose a system that they have to adapt to fit into, but rather a system that is able to adapt to their needs as much as possible. This is why the platform can best be thought of as a tool to be delivered to the Reality Guides to assist them in handling the back-end complexity of a network-based organization structure. Its purpose is to to map who has assigned themselves which tasks as well as who their dependents are (the ones they need to be in connection with to execute). Later, this tool can evolve once real-world experience and data has accumulated and lessons have been learned.
Why create something new?
Nothing quite like what we need exists. What we’re trying to do is not to create another task management tool. What we’re doing is creating a dynamically created organizational chart, creating needs and responsibilities in a rhizome. It might look like task management tool, just like a burn just looks like a party in a quarry until you go there.
Also, we are a community of artists, and create is what we do. We should view our code as art. Art is something that happens in service of creating a human connection. It is also something that happens at the boundaries. What ‘boundaries’ exactly means is intentionally left vague. But in the context of Realities, what it refers to is the ability to be an author to one’s own responsibilities without coercion so that the possibility is opened to execute as a work of artful self-expression.
V. Guidelines for development of the Realities Platform
-
It all starts from a Need: There must always be a Need initialised for other elements to relate to it (Responsibility, Reality Guide, Realiser etc).
-
A Need cannot be created without a Reality Guide assigned to it, and the person creating the Need automatically becomes the first Reality Guide for that Need.
-
A Need element has: A Reality Guide, a Realiser, a title, a description, a link to where discussion of the Need happens (Loomio or other platform), a list of Dependencies.
-
A Responsibility element has: A Need (required), a Reality Guide (automatically becomes the user creating the Responsibility, but can be reassigned), a Realiser, a title, a description, a link to where discussion of the Responsibility happens (Loomio or other platform), a list of Dependencies.
-
Every Need and Responsibility can also connect to other Needs and Responsibilities through Dependencies. A Dependency is directed so that one element is Dependent On another element. Dependencies are added to Needs or Responsibilities by selecting from all existing elements. Dependencies are tools to understand how elements fit together, but do not block any functionality.
-
Each Need and Responsibility can only have one Reality Guide and one Realiser. This principle is in place so bystander effect is minimized. We want for individuals to be empowered and be held accountable when holding a responsibility and have it as clear as possible who to contact when inquiring about some aspect of organization.
-
The end-user experience should be made as simple as possible. Essentially their experience can be contained by answering these questions for them, “How can I help?”, “What am I supposed to do next?” and “Who do I need to talk to?”
-
The correlation between elements should be made visually explicit in a manner via which participants can easily grasp the big and small picture.
VI. User stories: Who, how and when?
Our first priority is to use the Realities Platform for planning the Borderland in the months running up to the event. Our second priority is that the Realities Platform is suitable to use while at the event to answer questions about Responsibilities and who to contact.
All Borderlings are welcome on the platform from day one, but the most likely first users of the Realities Platform will be the Reality Guides. They arrive at an empty canvas, and it’s their responsibility to define the first Needs and Responsibilities. Most of them will also be administrators on the platform, and able to modify all elements. We want to make it easy for them to develop system thinking and update Needs and Responsibilities with additional information and Dependencies as needed.
When the platform has been populated with content, describing the current needs and responsibilities of the Borderland in rough terms, the Reality Guides will invite Borderlings to add their own content as well as fill roles as Realisers. Essentially their experience can be contained by answering these questions for them, “How can I help?”, “What am I supposed to do next?” and “Who do I need to talk to?”.
Borderlings who are creating Dreams or have questions or concerns can then filter through these Needs and Responsibilities to find answers.
Eventually, these Needs, Responsibilities and Dependencies will form a network of interconnected elements that could be represented as a graph.
This is helpful to us when a Borderling wants to make a decision regarding a certain responsibility. By looking at the connections in the graph, it becomes easy to map out dependencies to other responsibilities in many steps. This is vital information in a self organised community, because these connections tell a story about who the Borderling needs to seek advice from before making that change. This information could either be represented in a visual graph in a different view, or in lists generated by predefined queries. This is not a use case for the first version, but the system should be designed and built to allow for this in the future.
User Roles and Authorisation
Anyone can view all information on the Realities Platform without an account. Anyone can create an account on the Realities Platform to become a User, giving them rights to create Needs and Responsibilities connected to those needs. A User automatically becomes both Reality Guide and Realiser for any Need they create. A User automatically becomes Reality Guide for any Responsibility they create. If a User is either Reality Guide or Realiser for a Need or Responsibility, they have full write access to that Need or Responsibility.
A User who is Reality Guide for a Need or Responsibility can delete that Need or Responsibility, but a Need can only be deleted if no responsibilities are connected to it. If a Need has connected responsibilities, those must be deleted first.
If a User is Reality Guide for a Need or Responsibility, they can assign another User as that Need or Responsibility’s Reality Guide or Realiser, pending that User’s approval in the system. If a User is Realiser for a Need or Responsibility, they can only assign another User as that Need or Responsibility’s Realiser, pending that User’s approval in the system.
Most Reality Guides will also be Reality Admins. Reality Admins have write access across the entire Realities Platform. A Reality Admin can change a User’s role to make them a Reality Admin. A Reality Admin can assign a User as the Reality Guide or Realiser for a Need or Responsibility instantly (without approval from that User in the system).
An incomplete list of user stories for development
- As a User, want to create a new Need.
- As a User, want to create a new Responsibility for a Need.
- As a Reality Guide for a Need, I want to invite a User to take over as Reality Guide for that Need.
- As a Reality Guide for a Responsibility, I want to invite a User to take over as Reality Guide for that Responsibility.
- As a Reality Guide for a Need, I want to invite a User to become Realiser for that Need.
- As a Reality Guide for a Responsibility, I want to invite a User to become Realiser for that Responsibility.
- As a Reality Guide for a Need without connected Responsibilities, I want to delete that Need.
- As a Reality Guide for a Responsibility, I want to delete that Responsibility.
- As a Realiser for a Need, I want to invite a User to take over as Realiser for that Need.
- As a Realiser for a Responsibility, I want to invite a User to take over as Realiser for that Responsibility.
- As a Reality Guide or Realiser for a Need, I want to edit that Need’s title.
- As a Reality Guide or Realiser for a Need, I want to edit that Need’s description.
- As a Reality Guide or Realiser for a Need, I want to edit that Need’s discussion link.
- As a Reality Guide or Realiser for a Need, I want to assign a dependency to another Need.
- As a Reality Guide or Realiser for a Need, I want to assign a dependency to another Responsibility.
- As a Reality Guide or Realiser for a Need, I want to delete a dependency.
- As a Reality Guide or Realiser for a Responsibility, I want to edit that Responsibility’s title.
- As a Reality Guide or Realiser for a Responsibility, I want to edit that Responsibility’s description.
- As a Reality Guide or Realiser for a Responsibility, I want to edit that Responsibility’s discussion link.
- As a Reality Guide or Realiser for a Responsibility, I want to assign a dependency to a Need.
- As a Reality Guide or Realiser for a Responsibility, I want to assign a dependency to another Responsibility.
- As a Reality Guide or Realiser for a Responsibility, I want to delete a dependency.
- As a Reality Guide for a Responsibility, I might want to reassign its Fullfills property to a different Need.
VII. Future scope of the Realities Platform
The system should be scoped so that future versions can allow for tools to make collaboration more efficient and powerful. This section includes a set of possible future features, but this is more to get a sense of the needs we see for the community in the long term.
-
A capability for users to email everyone connected to a certain Need, either directly or through Dependencies.
-
Notifications or emails to go out to Realisers and Guides when changes are made to elements that they are linked to directly or through Dependencies.
-
Connect Dreams to Realities, where Dependencies can be added to Dreams on the Dreams platform, which in turn creates a Dream element and a Dependency on the Realities platform. This could help the community understand which Needs and Responsibilities are most critical for them to create their Dreams. This would also make it possible for Realisers to email Dream owners and Dream Guides that depend on their assigned Need or Responsibility.
-
Move deliberation into the Realities platform and allow for comments, change history for Needs and Responsibilities, and more thorough documentation.
-
Users can subscribe to updates on Needs and Responsibilities and get emails or notifications when these are changed.
-
Ask custom questions of a large and complex graph in the future when the Borderland might have 10.000 participants and all Dreams are connected to Realities to see what the most connected Nodes are and where in the network there is most activity.
) from clicking around in it was that Guides are people who’ve probably had a specific Responsibility before, doesn’t anymore, but is available for questions if the new Realiser has any. From reading the definition here the Guides sound more like a “Nominating committee” (valberedning). Just thought I’d mention that, maybe the UX/naming around this could be improved.
