Open2020 - Digital infrastructure session - Design

This thread is where Mike, @petter and @wouter co-design a conference session for Open2020. And invite contributions.

A set of earlier notes is here: https://pad.disroot.org/p/2020toolsplan - Digital tools infrastructure for making the living economy. These include some back-story for the session which may be relevant, where some matters below have been discussed already.

NOTE: Assumptions are shown as block quotes like this. Please challenge as appropriate.

Below . .

  • Session aim
  • Sequence of segments
  • Process tools
  • Draft content plan - Two segments: Breakout 1, breakout 2.

Aim

Primary aim of the session is to arrive at - or move substantially towards - choices of digital tools and protocols that will be used by members of OpenCoop as a community, as an agreed infrastructure for their ongoing collaboration in projects.

Not primarily discussing state of the art in platform tools, FLOSS tools, FLOSS protocols, server architectures, hashchains, etc etc

However, some broad consideration of these is required?

Sequence of segments

If the session is 120 mins

Two hours is as much as should be attempted, attention-wise?

. . and breakouts should be given 30 mins

30 min per breakout to allow settling time, round-the-room speaking time, looping-around time, feedback formulation time. The tasks for breakouts are not simple?
Breakout group <=6 members.

. . then the agenda needs to be:

  • intro (agenda, roles, outcomes, groundrules, housekeeping)

During intro, host needs to calculate number of breakouts based on participant numbers. Rule-of-thumb needed for this based on number of breakout topics.

  • two segments of presentation and breakout, max
  • final segment - wrap-up, decision on actions going forward

In each breakout segment - The session aim above means that in each breakout segment there is a repeated pair of questions (framing the feedback from breakout group to whole session):

  • Is this a must-have? Does this thing matter right now, for our next action in project collaborations? Or are we able to manage without it or leave it open, right now?
  • Even so, does it matter down the line somewhere?

Yes? Is this the basic format?

Process plan - What process tools are needed?

Breakouts - Should breakout groups be assigned or self-chosen? Does BBB technology permit self-choosing by participants? Is it possible to prepare overflow breakouts if a room gets too many people?

It may be necessary to have specialised topics in breakout phases, relevant to different participants’ experience? Not generic breakouts.

Does each breakout room require a facilitator/rapporteur?

Need to be selected and briefed in advance?

Because a decision is aimed for, means of voting/polling are required?
Also, polling tools may make feedback from breakouts simpler and format them nicely - thus easy to summarise and easier to make summaries that the whole group can view.

Tools might be required from Consul/Decidim? @petter ?

Content - Breakout 1 - Use-cases

Comprises some frame-setting presentation, followed by breakout . .

Consider different modes of organising in ‘sectors’ that contribute to making the new economy. Do they have varying requirements for digital tools? Or is there convergence in ‘generic’ tools?

Dedicate breakout rooms by sector - ie as below? Sectors are not necessarily mutually exclusive - the obvious example is that coop internal systems (eg contribution accounting) can arise in any sector of provisioning (ie any external field of work).

A - Various sectors of practice . .

  • Commons of provisioning material means of subsistence and wellbeing (food, housing, personal care, etc)
  • Commons of means of exchange (currency, credit, distributed ledgers, etc)
  • Commons of digital means (servers, platforms, apps, media, data)
  • Commons of labour power (including paid and unpaid labour in voluntary organisations. Including wage-work, ‘care work’ and pro-bono work in coops, contribution accounting etc)
  • Cultural commons (including education, advice, research & development, intelligence gathering)

Cultural commons is the sector that ‘we’ are in (members at Open2020 conference, and in OpenCoop projects). Back-home, we may also be in one of the others above. Choose one or other context for this breakout.

B - Commoning - What are the requirements for stewarding of commons? Does this call for . . polling, voting, graphing and mapping, mass mailout, deliberation media (Discourse instance?). Etc?

C - Protocols - what protocols need to be adopted, as framework for evolving infrastructure?

Probably too much complexity here? What simpler way is there to focus use-cases, when they are in fact (?) quite diverse?

Content - Breakout 2 - Assessing platforms

Comprises some frame-setting presentation, followed by breakout . .

A - Typology of tools - What are the components of an infrastructure of digital means?
For example, the DisCO model refers to ‘the stack” (handling ‘cultural’ processes of communication, discussion and resource sharing) and ‘the deck’ (handling economic realities that need hard-nosed accounting - contribution accounting, resource tracking, resource allocation, etc). Within ‘the stack’, what categories of tools do folks recognise and expect to use?

A typology could be offered? (DisCO Handbook contains one, for example.) Or breakout group could be asked to compile one, based on their own experiences - this calls for more facilitation, is a harder task.

B - Review and assess current tools platforms according to . .

  • the scope of the toolset (in terms of the typology above)

Categories of platform toolsets might be distinguished beforehand? For example:

  • full generic range (eg Cloudron or NextCloud stacks),
  • less than full generic range (one or two apps)
  • specialist, powerful (full-featured video-meeting capability, value tracking in supply chains, municipal democratic process, commons governance, ActivityPub social media, CommonsPub commercial infrastructure, etc)
    Less than 100% convinced by this typology!
  • the set-up labour involved, the access regime, operational issues
    • free (as in free beer), open access, tools in browser tabs
    • membership based, dedicated instance, sys admin labour/cost to be covered
    • membership based, dedicated instance, no sys admin (Cloudron)

Not at all convinced by this classification. But some framing is needed? Alternatives? Folks here know much more about these practicalities than I do.

Content - Final segment (wrap-up)

The session aim means that the final segment (wrap-up/decisions) needs to have this form:

  • Review the work done here in this session, notably feedbacks.
  • What decision can be made right now? What decision options need to be framed by a working group for early decision by the community?
  • Decide what is decidable right now.
  • Specify ongoing work, to be planned and executed by a working group.
  • Determine timeline, group members.
  • Determine mode of collaboration for team, means of collaborating

Maybe do this offline, post-session?

  • Determine mode of review of group’s work by the collective - decision making frame
  • Recognise questions/decisions to be brought into final conference wrap-up session

Related, for inclusion in final conference wrap-up:

  • Discuss and agree stewarding practice, of the ongoing, emergent cultural commons that is being formed at this meeting.

Digital tools and protocols are only parts of this commons (ie resources). Non-digital protocols - of commons stewardship - are pivotal?

  • Commit future attention to ‘use cases’ of digital tools infrastructure, in the communities of non-geeky commons outside of OpenCoop, which our geeky members here are also participants in (eg in localities, in non-geek cultural commons, in economic sectors like money, community care, regional food chains, land & housing, etc)

These points for @osb to consider in planning final sessions?

Hey Mike
All this looks like great planning…
I’ve replied more directly via Telegram

Oli SB, [28.05.20 09:48]
I like the aim:

Primary aim of the session is to arrive at - or move substantially towards - choices of digital tools and protocols that will be used by members of OpenCoop as a community, as an agreed infrastructure for their ongoing collaboration in projects.

Oli SB, [28.05.20 09:49]
I’d kind of like to link it in to the concept of “working groups” as mentioned in https://open.coop/2020/02/20/making-groups-work/

Oli SB, [28.05.20 09:50]
so the aim might become:

to arrive at - or move substantially towards - choices of digital tools that will be used by members of OpenCoop as a community, as an agreed infrastructure within ongoing working groups

Oli SB, [28.05.20 09:50]
(I took out ‘protocol’ because I don’t think this session will / should cover that … mainly because it’s too much for one session to do tools and protocols)

Oli SB, [28.05.20 09:51]
and I’d kind of like to promote Murmurations as the protocol which groups / other projects should be signing up to…

Oli SB, [28.05.20 09:58]
RE content - It’s hard to know how best to kick off / who should / can present what…

What I would really like to get out of this session is some agreement on Pattern 6 from Rich and Nati: “agree how to use tech” - (and which tech to use!!)

see: https://open.coop/2017/09/25/belonging-superpower-patterns-decentralised-organising/

Pattern 6 address the elephant which lurks in every room by asking groups to “Agree how you use tech”. I’ve never seen it put so simply before and this was a little revelation to me; the vast proportion of tech tools can be split into what Rich refers to as the ‘holy trinity’ for group management: A tool for realtime communication (i.e. chat), a space for asynchronous comms (email or a forum etc) and, a space for static content (a wiki or doc management app). If you can clearly define and agree which tool/s you will be using for each of these three essential areas of group work, your team is bound to be more effective.

Oli SB, [28.05.20 10:00]
this might be a nice way to introduce the session i.e. “every group that starts trying to collaborate ALWAYS NEEDS to chose a HOLY TRINITY of communication tools”… and we all end up wasting time making these choices… and get tangled / lose opportunities for synergy and overlap and cross pollination, when different groups use different tools …

So we want to see if we can collectively agree on a suite of collaborative tools - that become the default, go to set of tools for ANYONE starting or joining a working group…

Would it help to have accounts on the wiki for this?

Thanks @chris. I think most of what we’re doing here is transitory - prep for the event in June. Along the way we hope to learn things, and then maybe we might want towrite wiki-type stuff? Is that how you see the difference?

I’m in the wiki, thanks.

That’s indeed a very good way of putting it, 1) realtime, 2) asynchronous and 3) “static” documentation. I wonder where the tasks go. in 2) would seem reasonable, what do you say?

I’m a fan of stygmergy (learnt from the ants), to leave traces to empower others to join and contribute to the shared mission, promoting self management, without the need to waste a lot of energy on getting people up to speed. A guiding principle for operational transparency.

In the session on tools I’ll use this trinity as part of the framing for the breakouts :slightly_smiling_face: Also, the notion of a ‘stack’ and a ‘deck’ of software tools, as used by DisCO/Guerrilla Translations in their infrastructure strategy

The current design for the conference session is here:
https://notepad.diglife.coop/s/rk3LqJrhU#

I’m seeking contributors to a panel in the June 12th session. See this request . .
https://notepad.diglife.coop/s/SyFwhZH2L#
Do let me know if you or a colleague wants to talk about this. The timescale is short, sorry. I would like to hear from folks if possible by the weekend, Saturday June 6th.

1 Like

Added a note to the agenda for tomorrows meeting!

1 Like