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.

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.

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.

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:

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

I’ve structured the output of our discussion into a whitepaper, check here:
https://www.loomio.org/p/n0rR3fsb/read-and-ok-the-realities-whitepaper-or-suggest-changes

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.