Firstly, forgive the protracted follow up from myself and others - as you may have clocked many of those actively working on unMonastery at the moment are under particular strain, the last month or so has been flat out with projects, site visits and generally trying to steer the ship through rocky water.
I checked in briefly with Kei yesterday and have looked over some of the documents that have been started - which I'll feed into shortly. I think Kei will have mentioned this when you spoke but we have been wrestling with our documentation in an attempt to rationalise it and distil it into a usable template/toolbox for quite some time. This has turned into a greater task than we first anticipated, or at least rather than rationalising we seem to be producing more before finishing existing key aspects.
Your prompt and active move towards establishing this unMonastery node has catalysed a few of us to pick up where we left off last month. Myself @Bembo_Davies and @katalinhausel are going to have a call this Saturday to put back together the road map for completing the first iteration of the toolkit and as part of this I will prioritise getting some more useful material to you - given that you're essentially user testing this for the first time it would be really appreciated if you can flag issues, gaps, lack of clarity and general questions as you review material.
There is also two other conversations in process with regard to other possible unMonastery sites - one in Australia and one in Portugal which as soon as we’re on top of we’ll stitch into this conversation and see if we can connect the processes.
To respond directly to your first thought - yes we've been thinking through this for quite some time, we have an update in the pipeline that's aligned with the above. We've been looking in particular at the Open Data Institutes model https://theodi.org/nodes and obviously Hackerspaces - if there are any good points of reference you've come across for distributing models that resemble the unMonastery (i.e not hardware, not software, but still open source) we'd love to know about them. Given that we intend this as a network it feels important we get this right from the beginning - all thoughts and provocations appreciated.
On the second thought, RE: financial support - this has been a real patchwork of approaches, as you know we first received funding for the prototype in Matera which was brokered by EdgeRyders and existing relationships, as well as close alignment with the city's goals (with support and a direct line to the cities administration).
Since then, we've been running general operations (not sites) on a mix of personal incomes and small grants for specific work/events - whilst working towards a number of funding bids. One of which we have been successful on (more on that soon) and so given the mandate of that bid there may be scope for replicating the initiative and seeking match funding but this is probably more efficiently done as a call to discuss funding approaches with you directly. We also collect and collate funding opportunities, and schedule sprints for applications so that they can be done in bulk and overlap (this has only happened once though, a few months ago) - see here: https://trello.com/b/I3o2cKYh/funding
In terms of patterns I have a couple of models that we could hash out together that are yet untested but iterate on others existing work that I’ve been in contact with, I anticipate that there’ll be a considerable context shift though between Europe and the US.
Lastly, on Leadership and decision making process - I could write a book on what hasn’t worked, has sort of worked and the diversity of current thought on this but I’ll keep this short(ish) right now. (Probably worth noting that part of the reason that the BGLO is lacking, is because I haven’t gotten around to giving my input on the subject there.)
Going from the beginning, In Matera we had three dynamics that governed decision making, process and structure.
1) We replicated the Monastic model of the Abbot, that was me. See here for how it was defined.
2) When everyone arrived, we sat in a circle and decided on a decision making process - the group chose Consensus - but with a few provisos, “everything is a prototype”, “trust in the process”.
3) There was a soft inheritance of EdgeRyders “the person that does the work calls the shots” - but this ran in symbiosis with consensus.
Now how did these elements workout (in my opinion)?
Essentially there was too much contradiction between each system, but specifically:
1) This only works if everyone has read in detail the nuanced function of the rule, and conditions under which the Abbots roll actually functions (see code/uncode interviews for greater insight, I will pull some specific references from this to explain further - but Agamben’s The Highest Poverty is also essential reading in this respect) - in practical terms we observed that one unAbbot isn’t enough, then we also only had 2 roles, unMonk and unAbbot, actual monasteries also have more roles.
2) From all prior experience I was against consensus from the start (people have strong views on this) - my belief is consensus only works if a) you know each other exceptionally well, b) you have mechanisms for dealing with how internal allegiances influence the group, c) have a process for dealing with blocks. Sociocracy seems to have solved much of this - a consent model is infinitely preferable in my experience and I would personally recommend this as a good plugin (and would be happy to connect you to people developing it further).
3) What we’ve found to date, is that this approach to decision making and process works well up upto a point on the internet, see "dictatorship of the active", but fails hopelessly in a shared living and working environment, e.g if someone’s chosen work involves rearranging the whole house.
It’s also important to note that much of this is underscored and supported by a certain ethos and shared (implicit) values system - that you captured remarkably well in the metamap - and perhaps most importantly we use circles to face each other regularly.
Something essential we learnt though that relates to all of this is; make sure that everyone turns up at the same time at the beginning, that you have at least 3 months at the start with a fixed group, so that you can build the culture and test the processes. If someone leaves and another person joins at this foundational stage, you’ll find alignment and maintaining shared processes exceptionally difficult.
Now that’s the history. Recently we’ve been looking further afield for decision making processes recognising it’s not our strong point when alignment is low, so we’re seeking to adopt and learn from existing well tested models that will fuse well with the monastic slant. Recently we’ve been in dialogue with Robinhood Coop and will be speaking with Enspiral shortly - I can link you into these conversations and share material when they’re more developed.
The other aspect of this that’s worth mentioning is the technology stack - we use loomio for making decisions remotely that we think require visibility or affect the group, this is supported with Slack / Discourse / Some email / Regular Conference Calls (worth noting that this stack is the same as Robinhood and OSCEdays - hence recent discussion).
But to be direct and short in response to your final question don’t leave it in suspense - but design an initial chunk with emergence and flexibility in mind.
This turned into a quite a lengthy response - partly because I wanted to outline with broad brush strokes various aspects that we can delve into later in more detail (perhaps with recorded conversation on specific subjects so they can be shared later), but also to offer some entry points for direct possible collaborations. I’m personally very excited about what you’re doing and would like to help as much as time grants me.
I hear Bembo will be popping by here some time soon, so I’m sure he’ll fill in the gaps, correct me and give you a slightly different angle.
enter link description here