Realities platform concept notes

I'll start by going through background to the concept. This is essentially the same material that I go through in this video, so if you prefer you can look at that instead.

I'll start by showing an overview of how we're been thinking about Realities. Because we often like to think about the Borderland as an interconnected network, we have thought about Realities as a graph. I just want to make clear that that does not imply that we need a graph database. That's up to all of us to decide, and all of this is of course possible to implement in other ways. But we'll save discussions about stacks for later.

At the core of organising the Borderland there are certain NEEDS that must be FULFIILLED. In order for us to create our DREAMS, we must make sure that these REALITIES are being taken care of by the community.

All work on Realities starts by defining a need for the Borderland. In this example, we have defined two needs. One need is to have "Safe burns that follow fire regulations". Another need is "First aid and care for participants in need at the Sanctuary". When a need is created, the user creating the need automatically becomes the "Reality guide" (shortened to GUIDE in the chart) for that need. A need cannot be created without attaching a reality guide to the need. A need can only have one active Guide attached.

A need is then fulfilled by defining RESPONSIBILITIES. These should be defined enough that they can be taken on by a single person. Just as with needs, responsibilities are created with a single Reality guide attached to them. In addition, all responsibilities need to fulfil a need, so it's not possible to create "orphan" responsibilities that don't fulfil a need.

The role of the reality guide is to make sure the needs are fulfilled and that the responsibilities are met. They do this by finding people to realise these needs and responsibilities. Each need and responsibility can have exactly one REALISER. Realisers must not be assigned to all needs and responsibilities when they are created, making sure that happens is the job of the guide.

Finally, needs and responsibilities can be interlinked with dependencies. In the example, the disaster plan for burn accidents depends on that volunteers have been scheduled at the Sanctuary. In turn safe burns depend on a disaster plan for accidents.

At an early stage, this sort of graph will not be of much consequence, but as it gets populated and as the Borderland grows, being able to ask questions from the graph could become a valuable tool. Also, it might be easier to understand the self organised structure of the Borderland for all stakeholders.

Just visualising a graph like this can be useful to understand how the Borderland works. An example could be to understand the consequences of Freya dropping out of the community. In that case, it would be easy to see that this is a very serious problem. We can easily see that this affects Shivas work but also we actually have dependency where Freya has been carrying critical load for two vital needs. She has also been a Guide for a need that dependent on her own work. If we had seen this before Freya dropped out, we would probably have tried to find another person to fill either her roles as Guide or her role as Realiser.

Another future application would in case we need to contact everyone who has responsibilities somehow related to burns. In this case, Shiva is the realiser for the burn related first aid, but she is not directly connected to the main burn node. However, because of the dependency of safe burns on first aid, Shiva could be included in a search which includes anyone linked to the burn need. In the future, where we could envision ways to reach exactly the right people.

In the future, we should also link Dreams to this and add a field in Dreams where you can choose needs that the dream depends on. That would make it possible to see what needs are important for what dreams, and make it easier to get dreamers to step up and fulfil those needs to make their dreams happen.

We could also envision having this system link to our member profiles, which could list skills or interest in helping out in a given field, and based on that do automatic recommendations of responsibilities that need to be filled.

I'm on board so far. Will try to be more contrarian in the morning and give whatever constructive criticism I can muster.

I want to start with re-elaborating the entire way we want to resolve the problem: Do we need a dedicated (web)app for this? What we're trying to do at the end: isn't it a sort of another task management app, like Trello etc but with a different UI? Could we potentially use an existing system and fetch the data with an API that renders graphs for people to visualise right away? And actually that's great, because there's so many existing solutions out there that we can adopt and change/transform...

For example, Trello has an api: https://trello.readme.io/v1.0/reference#api-key-tokens

Though there's definitely a big input you provide with the interconnectedness of the entire elements which is much more relevant in real-life problems than in the software ecosystems. But I want to warn you that people will not get it in the way that you intend, and that they will start assigning dependencies thinking that they are creating needs, or stuff like that... Therefore we shall probably do some brainstorming on this before implementation. I feel our biggest challenge would be to make this error-free (to an extent of course) for people to use, if we do a custom solution. And I believe, if we do a custom solution, we shall try to use as much existing technology as possible to not reinvent the wheel and focus on what we're doing different than existing ones. I don't know how much resources we have, but I imagine it's not much. So we really need to be smart in being productive. Don't you think so?

I've checked the Grandstack and Neo4J a bit. It seems a bit too much of an enterprise class software tools to me honestly. It's way above standard than what we need for this kind of project I feel... This is not necessarily a problem; but I just know that I can't personally promise much of my efficiency given that I haven't work with neither Apollo+GraphQL, nor Neo4j. And the complications that come up with new stuff tend to be even higher when they are supposed to work together... Also I work full-time, so it's very limited time I can spare in general.

I've got the feeling that we can do much more sophisticated product if we only focus on the parts you point out regarding the:

Needs(dependencies) => Realities(guides) => Responsibilities(actions) etc..

As you noted, we don't really need graphDB indeed. We can draw graphs with D3 or HTML5canvas or some other solution based on whatever data we have. At the end of the day: People are going to enter text inputs, and assign relationships in between those text inputs right? I also think perhaps usage of hierarchic taxonomy could prevent from quite some headache. For example when you create a need, often you might wanna insert it under an existing higher-need; such as:

NEED: Fire-free borderland.
Need: Fire extinguishers in every camp.

There'll be many many needs whose correlation is often just directly consequential. Therefore maybe we want to focus on the hierarchies...

An option is to really use the Trello api.
Another option is to get a TODO app like this one from Meteor and extend it: https://www.meteor.com/articles/todos-example-app
Another advantage of Meteor is that it's super easy to export native apps with the Cordova builtin. So we'll have native apps as well. User accounts, Emails, Websockets, MongoDB are all builtin with Meteor and they just work brilliantly...

But I think we can/should research more before sticking to any decision regarding stacks...

These are my honest opinions :)

Thank you Emin for your valuable input and for questioning! I very much appreciate it!

Indeed, Trello is what comes closest to what we want. And prototype for Realities started on Trello about a year ago, and resulted in us running a prototype on Trello for Borderland 2017: https://trello.com/b/8t6Zq8t2/borderland-reality-platform

Essentially, there are quite a few problems with any solution that we have tried to adapt to the Borderland philosophy. And when it comes to our philosophy of doing things, there is a very strong will in the community to not be forced into other philosophies by systems that a generalized for doing almost what we want, but not quite.

A few of these philosophical requirements are that: Each need and responsibility has exactly one guide and at most one realizer, and that a need or responsibility cannot exist without a guide. Another is that a responsibility (or a task or role using other terminology) can not be created without belonging to a need. A third philosophical requirement is dependencies to interconnect needs and responsibilities. There are other philosophical underpinnings of the Realities process, and I think @danieldeterrencebr can fill us in.

It's important to note that this system is not meant to be used with any general process. It comes with a philosophy and a method that is being developed simultaneously, with @danieldeterrencebr at the helm. Indeed, in parallel at the hackathon, another group will be doing the "social hacking" to continue work on this process, following what we've learned in the last year. It was this human-technology synergy that made the Dreams platform a success, and it's from the Dream guide system that we get the idea for Reality guides. The reality guides will be stewards of the Realities platform, just like Dream guides are stewards of the Dreams platform. They are community managers and will have the responsibility of keeping track of the pathways and networks so that they actually make sense and represent reality. In the best case scenario, some of them are power users and use graphs they generate on demand with queries to assist them to create custom graphs to answer certain questions about the community.

I'm also super open to look for stuff that we could adapt, but I haven't found anything that does enough of what we want that adaptation would be easier than rebuilding. But there is one project we should look into more closely, that's being developed friends of ours in Israel who also collaborate with us on the Dreams platform. However, the approach they've chosen philosophically is quite different from ours, but they have essentially done what you are proposing, re-using a core from another task-app: https://github.com/Metaburn/doocrate

It's possible that I've overestimated the differences between these projects. Unfortunately, it's all in Hebrew right now, but they are good friends and really want to collaborate. Until now, my view has been that it would mean that we compromise too much with the philosophy (which has wider ownership than this development group) but I'm definitely open to think more about that.

Thanks a lot for the feedback too Hugi! Of course, I'm glad to contribute.
So, I want to write a brief statement of what we want, and sketch a list of guidelines which thoroughly explicate the important parts of the system. These are like the foundation of the system.

Brief: Develop a software system that helps BLers collaborate better, by giving them the ability to create Needs and then Responsibilities, and also to assign a Guide and a Realiser to each Responsibility. The UI of the software should 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.

Guidelines:
- It all starts from a Need: There must always be a Need initialised for other elements to relate to it (Responsibility, Guide, Realiser etc).
- Every Responsibility must be created as part of an existing Need. It is sort of a more practically explained task, to be realised.
- Every Responsibility is realised by maximum one Realiser, along with maximum one Guide to help realise it successfully.
- The correlation between elements need to be visually explicit in a manner via which participants can easily grasp the big and small picture.

Am I missing anything, or am I wrong somewhere? Please point! :)

I just thought of the Need->Responsibility relationship: It fits well to the logic of Lists and Cards at Trello. Cause no Card(Resp.) can exist without List(Need)... Just saying :)

By the way, I want to include the dependency issue on the guidelines too, but I didn't get it exactly :)

Is the dependency thing kind of a "blocker" between responsibilities? So e.g. me fixing the toilet papers is dependent on (or blocked by) you fixing the toilets at first? Is this the dependency logic - blocking between responsibilities..?

Yes! Writing a brief is an excellent next step. I've added to your great draft. I need to make clear though that we do not need to live up to all theses guidelines to have a functional first MVP. Things that can wait include graph visualisation, constraints on always having a Guide, moving Responsibilities between Needs and implementing Dependencies. Those are features I envision being developed in the coming year if we manage to get the foundations up and running. Right now, building something that just does the basics, even without authentication, is enough.

I've also included three extensions of the brief at the end. One is an explanation to clarify what is meant by "Responsibility" and how this differs from a task that can be completed. Another is a few points on user classes that do not need to be implemented for an early version. The last section is on future vision and scope, outlining some more optimistic hopes for future versions, but most of those probably lie beyond Borderland 2018.

Brief:

Develop a software system that helps Borderlings plan and execute co-created events without top-down management, by giving them the ability to create Needs and then Responsibilities, and also to assign a Guide and a Realiser to each Need and Responsibility. Needs and Responsibilities are interlinked by Dependencies that clarify how these are connected. The UI of the software should 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.

Guidelines:

• It all starts from a Need: There must always be a Need initialised for other elements to relate to it (Responsibility, Guide, Realiser etc).

• A Need cannot be created without a Guide assigned to it, and the person creating the Need automatically becomes the first Guide for that Need.

• A Need element has: A 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 Guide (automatically becomes Need Guide, 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.

• The correlation between elements need to be visually explicit in a manner via which participants can easily grasp the big and small picture.

(*) Notes on how Responsibilities relate to Needs:

A Responsibility partially or completely fulfils a Need. For example the Need "we need electricity for all camps and dreams the Borderland" could have different sorts of responsibilities:

• A significant task that can be finished (like "research, decide on and order new transformers")

• A role of active leadership (like "lead the electricity team")

• A passive advisory role (like "expert point of contact for questions on electricity safety")

• Some other class of responsibility that fits the process.

All responsibilities work the same in terms of how the technical system operates.

If there is no Realiser for a Responsibility, it is the job of the Guide to define requirements and to find a suitable Realiser. It is likely that the Guide for a Need will also be the Guide for Responsibilities that belong to that Need, but more complicated Needs with many Responsibilities that might not be feasible.

User classes:

• All users can remove themselves from the role of Guide or Realiser. Moderators (Reality Guides) can remove other users from the role of Guide or Realiser. Desired process is that most Guides join the moderator group.

• All users can create needs and responsibilities, and delete needs and responsibilities they have themselves created. Moderators can delete needs and responsibilities created by other users. A need cannot be deleted if it still has responsibilities connected to it, any responsibilities must be removed first.

Vision and future scope:

The system should be scoped so that future versions can allow for tools to make collaboration more efficient and powerful. In this section I include 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 dependancies.

• 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.

I edited my post a little when I realized that some of the Guidelines I wrote were way too specific, so the post is different now than the one that just went out by email.

Thank you Hugi for going into detail. I will now attempt to paint a background big-picture background perspective of the philosophical underpinnings of this project to further clarify what our intentions are in this work.

The Borderland essentially organizes itself using two processes: Dream Prototyping and Consensual Do-ocracy (aka the Advice Process).

Dreams

The stated purpose of the Borderland is to explore the space between dreams and reality. One way of explaining this is that we build a frame that allows and supports our cocreators to gain a real-life sample taste(a prototype) of a dream they've had and explore it together. The system we have set in place to organize these art projects is Dreams, which consists of the Dreams Page where ideas are shared and crowd-funded and the Dream Guides that facilitate the development of them so they are aligned with our community guidelines.

Realities and Consensual Do-ocracy

The project we are now getting ourselves into is creating a frame for the organizational aspects of the Borderland as a counterpart and complement to Dreams, one which we will be calling Realities. The term Consensual Do-ocracy means that the power to decide on activities rests with those who are going to execute them. In order to do this skillfully and without stepping on other's toes however, the do-ocrat need to solicit perspectives, advice and consent from those who will be affected by their decisions. By doing this they become 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 is meant to facilitate these processes. 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 fulfill them to those who want to help, with minimal bureaucracy and confusion.

Guides vs Page

The aim of this stage of the Realities project 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 Page and its users, but the page, its users and its custodians and facilitators. Note the word facilitator - their role is to support and make easy, not to manage. These Reality Guides(as well as some early-adopting superusers) may be viewed as the principal customers of the MVP. Because of the artistic and individualistically expressive nature of our community, we are not expecting all our users to adopt a new IT platform from the beginning 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 page can best be thought of as a tool to be delivered to the RGs to assist them in handling the back-end complexity of a network-based organization structure. It’s purpose 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 a real-world experience and data has accumulated and lessons have been learned.

Design principles

Perhaps it is useful to talk about three design principles for Realities RP+RG:
1. 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?”. This also includes information filtering: one should gain just the right information to work. Too much or just useless information is a blockage to creativity and motivation.
2. There is always a single lead for each need and responsibility. 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. A lot of problems stem from it being unclear who is the lead.
3. This system aims to be support for a human process, not be a human process that serves a system.

Structure vs Ambiguity and Trello vs Custom Solution

We are a community of artists. 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 ones own responsibilities without coercion so that the possibility is opened to execute as a work of artful self-expression.

As far as I'm concerned, if we can accomplish the same things using something off-the-shelf with modifications, that's great. However, I'm quite concerned that by using a closed source system like Trello with addons, we'll be cutting off many potential avenues of evolution and that adding stuff to a general-usage system rather than going for a simple custom solution to begin with will not set and adjust the balance between structure and ambiguity that makes Consensual Do-ocracy effective.