Tue 21 Nov 2017 11:27PM

Realities platform concept notes

H Hugi Ásgeirsson Public Seen by 369

In this thread we'll go through the background, context and concept notes we currently have for the Borderland. This thread is aimed primarily at discussing technology choices but is rather a discussion about the underlying model and assumptions behind the Realities platform and how it integrates with the Borderland community.

For an overview of the concept, see this film: https://youtu.be/i6ivb0iRC3M


Hugi Ásgeirsson Tue 21 Nov 2017 11:44PM

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.

An overview of the Realities concept

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.


Fredrik Bränström Wed 22 Nov 2017 9:13PM

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


Emin Durak Fri 24 Nov 2017 1:46AM

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 :)


Hugi Ásgeirsson Fri 24 Nov 2017 3:12AM

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.


Emin Durak Fri 24 Nov 2017 2:00PM

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.

- 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 :)


Emin Durak Fri 24 Nov 2017 2:02PM

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


Emin Durak Fri 24 Nov 2017 2:11PM

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


Hugi Ásgeirsson Fri 24 Nov 2017 6:00PM

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.


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.


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


Hugi Ásgeirsson Fri 24 Nov 2017 6:07PM

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.


Daniel DeTerrence Brooks Sat 25 Nov 2017 3:24PM

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


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.


Emin Durak Sun 26 Nov 2017 6:39PM

Thank you Daniel for your in-depth explanations. It's very nice to have you guys think about them and write down.

I'd personally like to make sure to know a few things, such as why and for who we're building this.

Is this for pre-BL/preparation phase, or usage for on-the-ground during BL? Or both? In that case to what proportion? And is it mainly for BL core-team, or for every each participant? Or both? In that case to what proportion?

I think it's very important to do something that works very well on mobile too, if not mobile-first. Because you know people carry their mobiles all the time and use it much more often than computers. To show such correlated graphs could be not only hard, but also user-unfriendly on a mobile display. So we might wanna re-articulate the UI on that matter. I don't mean to say to abolish graphs or anything like that, but I'd like to invite us to re-iterate how the UI will be - how people see and interact with it... We will spend months/years building it, so it's really good to brainstorm in the beginning rather than during (of course also during).

So I just think it's good to make these points, "why" and "for who", very explicit, before we decide "how", although, of course, we might change...

About the technology, I totally feel you. But there'll always be limitations to whatever we will use; and yet limitations are necessary factors of evolution :) I think we just have to prioritise which parts of the system we are crafting ourselves, and which parts we just reuse...

In my experience, there's kind of 3 different user-personas as an active participant at the BL. Of course this is an over-simplification and might be wrong.

  1. Deep planner: That who has an overview of the entire organisation, who knows the critical people (from inside or outside), and who helps arranges fixes for such important concerns as life needs: fire, electricity, healthcare, local permissions and dialogue with stakeholders, the toilets, and the aftermath etc. She's most likely on the board or works a lot with people on the board. Takes the whole year to plan.

  2. Dreaming planner: That who plans a dream, most usually with at least a few others and cooperates to make a camp or a dream or both come to life in BL. Although she doesn't take active part in the entirety of BL logistics, she makes sure throughout a long time that she and her gang are as autonomous as possible during the gathering and have a lot to gift to the rest of the community. Takes several months to plan.

  3. Wanderer: That who comes with least planning, preparation and coordination to the site. She comes the latest, and leaves the earliest. She has a lot of love to give and generous, but has limited time, resources and labor to propose. She loves to help, but she needs to know how and when. She will love to take responsibility and do things, but she might be too busy having fun ;p. Takes from weeks to hours to plan, if any...

I think it's good to keep these in mind while we approach the tool we're building. In my experience, the number of people in these groups are like: 3 > x > 2 > 1. I don't know if we wanna change it a bit, or maybe we wanna blur the distinction in between these, I don't know... :)

Just trying to be a bit pragmatic... Hope it helps.


Hugi Ásgeirsson Tue 28 Nov 2017 8:26PM

I've personally always seen this tool as being more important for planning before the event than for using on your phone during the event. I also envision the view for assigning needs, responsibilities, dependencies (which is priority 1 and should also be good on mobile) and the future view of graph visualization (priority 2 and perhaps not good on small screens) to be separate. Btw, I also think that if we had a graph, it would be really cool to hook up a big touch screen to a computer at the Borderland so people can get information by coming to a physical place.

As for your categories of Borderlings, I think that this is correct in broad strokes. However, I feel that it should be the goal of an event "exploring the boundaries between Dreams and Realities" to blur those lines as much as possible. Likewise, we should always blur the lines to the "core team" as much as possible, transform dreamers to responsible logistics generals and turn reality prone bores into dreamers.

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 by creating needs and responsibilities in a rhizome as we go. It might look like task management tool, just like a burn just looks like a party in a quarry until you go there. We're building a tool for tribal anarchist organizations. 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.

That's the bombastic aim for this humble tool. Just like "exploring the boundaries between Dreams and Realities" is the bombastic aim of a week long party in a quarry. We want to bring the ethos of how and why we burn into how and why we code.


Hugi Ásgeirsson Tue 28 Nov 2017 6:22PM

I just want to note that I've read you post @emindurak, and it has a lot of excellent points. Perhaps we should meet and discuss a bit?

I'm thinking about these issues now, and I know @danieldeterrencebr is looking at it too.


Hugi Ásgeirsson Tue 28 Nov 2017 8:31PM

And while I think that the user case is important, we should do our absolute best to treat citizens like kings and kings like citizens. Thinking about people in tiers of responsibility and depth also helps to freeze those tiers in place.

At the same time, I very much appreciate your pragmatism. I very rarely get to be the bombastic visionary. This is a welcome change. :relieved:


Emin Durak Wed 29 Nov 2017 1:27AM

Haha, love it. The last paragraph of your earlier post is the best thing I've read today, a caress on my soul to go to sleep with... Thanks my dear <3


Poll Created Thu 30 Nov 2017 2:44AM

Read and OK the Realities Whitepaper or suggest changes Closed Sun 3 Dec 2017 2:03AM

by Hugi Ásgeirsson Sun 3 Dec 2017 1:15PM

We’re going ahead with the concept as described in this whitepaper. It will be our point of reference when we start development. Next step is now to decide on a stack: https://www.loomio.org/d/867aSKi5/choice-of-stack

It would also be good if we could set up a repository with simple setup of our stack that we can start from next weekend.

To make things as clear as possible before we choose our stack and group into teams, I've structured the content from the discussions had by @danieldeterrencebr, @emindurak and me in the thread on concept notes.

As I went on, this kind of grew into a whitepaper for the project. You can find it here:

If you're okay with it and feel that it's enough and well thought through, just "OK" this proposal. However, feel free to propose changes to the document by enabling "Suggest changes" in Google Docs.

One part that might need some more fleshing out to be useful for development is the "User stories" part. Feel completely free to do whatever you want – add new parts or change the structure.


Results Option Voters
Yes 3 EF GL VM
No 0  
Undecided 8 DDB H CU JLH FB R ED AC

3 of 11 people have voted (27%)


Hugi Ásgeirsson Thu 30 Nov 2017 1:10PM

I’ve structured the output of our discussion into a whitepaper, check here:


Erik Frisk Thu 30 Nov 2017 11:30PM

Great description! I think it communicates the purpose and concepts pretty clearly. Since you mentioned it in your "Check" post, I began listing user stories for development in the document based on the overall text. I got stuck on the question on authorisation though. Which types of users have the rights to edit what? I'm writing a rough proposal for this in the document right now. Feel free to jump in and add to it or completely rewrite it if you've already thought of doing this a certain way.