Loomio
Fri 6 Mar

Processes and practises for informing our direction

NS
Nick Sellen Public Seen by 109

As we get on top of more of the tech infrastructure topics (we're now on latest mastodon, woo!), the question arises (within the tech team calls) of what next....?

There are still some things to do before we are ready to do much significant new tech work (see last tech meeting minutes for some tentative steps to get there), but I think now is a good time for some more meta/theoretical discussion about it - without worrying too much about the practical outcome right now...

There have been a few suggestions of what to add/do:

So far it seems hard to progress them... especially because tech capacity is not quite there yet (maybe people also don't have a good understanding of what is possible or not), but also it's hard to know what will be good/useful/desirable/fun for the wider community, and how to ensure it is supported in the longer term, and maintained, etc....

To me, it would be very interesting to explore this as a meta topic in itself (also because it touches on problems that impact all the community-oriented software projects I work on) things like:

  • community members lacking sufficient tech understanding to feel able to make informed decisions

  • perception that it's only just for techies get involved in

  • tech people having dominance and arrogance, techbros, etc...

  • bridging/connecting "islands" of "tech" and "community" people..

  • missing human/care/love/support, leading to frustration and burnout...

I'm really searching for some models/theory that can frame some of this. A human/community driven/led approach. Or something.

I haven't actually read any Ivan Illich and their concept of "tools for conviviality" (maybe this article/paper is interesting) but it really appeals to me, also E.F. Schumacher's "intermediate technology" (and "appropriate technology" later) seems related and also interesting, and this article about "Convocational Development". I don't know if they're directly relevant, partly as we're not actually building tools here (just reusing existing ones), but it gives a flavour of the direction I'm thinking in... (and for my other projects we are actually building tools "for the community").

@mike_hales already make some nice comments, I'll quote them here:

On convivial technologies . . Illich on ‘tools for conviviality’ is a great source, definitely. But beware reading this in a tech way. The point of Illich’s critique is that modern cultural and economic forms and institutions are ‘tools’ too, which attract power around specialist professionalised roles, and undermine the possibility of ‘vernacular’ capability. What Illich has in his sights is the politics of these kinds of roles and institutions, not just hammers, tractors, cars, fast food and software code. So it’s convivial processes/practices in general that we need to develop - and then tech infrastructures come into the frame just as a part of that.

Avoid tech reductionism - we’re social.coop, not app.coop?

“Convivial technologies” . . is a term that gets used quite diversely. So the principle imo is good, but the term is unreliable. Guerrilla Translations uses it to refer to the architecture of digital means of collaborative working in a DisCO - apps like Trello, Slack and Loomio, and facilities like Google Drive (aargh!). See Book 5 of the Guerrilla Translation Handbooks . For Google Drive to slide in under the rubric of ‘convivial’ - or Trello and Slack, for that matter - just goes to show how slippery the term is! Tread carefully? Just because we mean well when we use a platform or app, doesn’t make the platform or app OK. Apps have politics.

M

mike_hales Fri 6 Mar

we're not actually building tools here (just reusing existing ones)

This is key? It underlines the fact that, when tool infrastructures are designed/ developed, what in practice is being designed is the work of those who mobilise them in practice: ‘the users’. So no, we won’t need to do much (software) tool design here (maybe some FLOSS hacks?), and configuring existing apps will do just fine most of the time, but we will need to design the work that we mean to do here, the collaboration that we mean to enable - the society of social.coop. A large part of the ‘technology’ will be culture, agreements, narratives, roles, valuations.

It’s ‘design of design’ that’s at stake? This is challenging but not the first time it’s been attempted . .

In the 80s/90s - when there was great concern over ‘deskilling’ through ‘the new technology’ - there was a movement starting in Scandinavia, being taken up in the US, for ‘work centred design’, with a ‘tool’ and ‘skill’ orientation. It became part of the field of Computer Supported Cooperative Work and became labelled ‘participatory design’. Those folks always remained aware that it’s the work that’s at stake, not the code. And that the design of new ways of working (while retaining valued older modes of skilful working) was the aim, so that the work could be done skilfully and comfortably, to achieve the workers’ aims. The digital tech is just a means (sorry coders ;-).

In another comment I’ll cite some stuff from this background.

Today this is harder. The digital tech is highly distributed now, so more layers of (digital) architecture are implicated in the choices of ‘which tools’. The tool infrastructures are quite fully configured, off the shelf, especially when platformed - although they also are often in smaller modules (all the way down to individual code objects). They come ready wired with cultural/economic forms (or honeytraps, as with all things Google). Some are difficult to refuse or reconsider because they have a huge installed base on mobile devices. They are seductive because many of them seem to be ‘free’. So the 90s game can’t be played today as it was then. Some innovation to be done, in ‘design’?

NS

Nick Sellen Tue 26 May

So no, we won’t need to do much (software) tool design here (maybe some FLOSS hacks?), and configuring existing apps will do just fine most of the time, but we will need to design the work that we mean to do here, the collaboration that we mean to enable - the society of social.coop. A large part of the ‘technology’ will be culture, agreements, narratives, roles, valuations.

The core task to me, is running and maintaining a server. A sysadmin job basically. This often ends up very detached role from the whole project, and I think that has happened in this case. The discussions about what tools have become disconnected from tasks about running the server.

It's not actually that much work, but it needs to have the culture, roles, etc. in place, at least for it to be interesting/motivating to me. On our projects I work on we manage to run mailservers, forums, chat, basically whatever services we find interesting or useful with not much extra effort. It's fun even.

But in those other projects it feels like that work is done much more in the context of the project - the software tool we develop + the community of it's users. In the case of social.coop I'm kind of missing the bit about what it is. It has a community of users, but I suspect most of them see it as a mastodon instance. Aside from that a small number of people in the loomio seem to have a bigger vision, but not all the same bigger vision from what I can see.

M

mike_hales Fri 6 Mar

Illich and Schumacher . . .

Illich isn’t talking directly about the design of tech. His argument is with imposed ‘radical monopolies’ of service provision, which are in the hands of techbros of one kind or another (including medical doctors, agricultural scientists, administrative 'scientists', ‘domestic scientists’, ’management scientists’, pedagogical professionals, etc), but which serve the extractive and controlling purposes of corporate organisations and States. So it’s a deeply important argument, but not directly about the tech form of tech infrastructures.

Schumacher and intermediate technology may be nearer the mark. His argument was pitched in an era of ‘development’, in which technologies were being implanted in ‘developing’ countries via 'aid' which hooked them into value chains that delivered profits in 1st world countries, notably the US, and had unacceptable costs for the client populations in money, dependency and lost ‘sense’ of tradition and place. ‘Appropriate’ technology was designed/selected to keep things under the control of indigenous populations, within vernacular capability, affordably. Today we would say, sustainably. The argument is close to Illich. But closer to the tech choices.

I’m not very knowledgeable regarding where ‘appropriate tech’ practice has got to today, under ‘post-development’ consciousness. Must have diversified and diffused quite a lot? Who else here knows? Obviously, P2P hardware approaches are an aspect of this - design global, build local? Fablabs etc? Guerrilla Media Collective is pursuing this principle, with their evolving design for DisCOs. DisCO is a global coop design that includes organisational/cultural ‘tech’ (care work, commoning), value-accounting tech, work-coordination tech: and digital-mediation tech (actual apps). So maybe the upcoming Reading Group discussion on DisCO will feed in here?

NS

Nick Sellen Tue 26 May

Illich isn’t talking directly about the design of tech. His argument is with imposed ‘radical monopolies’ of service provision, which are in the hands of techbros of one kind or another

To my limited reading (i.e. just reading this comment, but not the source) this seems highly related - in that the ability of social.coop to provision other services is dependent on our practises/processes for doing so.

Some of the discussions in this thread suggest using hosted app platforms, which, in the case of cloudron, on the one hand open up the possibility of service provision by non/less-tech people, on the other hand it then uses this to re-enclose those service provisioning capabilities inside a private company and their proprietary software (cloudron is no longer open source, and even if it was a significant portion of the burden of running that service would still remain out of the ability of most people).

I’m not very knowledgeable regarding where ‘appropriate tech’ practice has got to today,

nor me :) but I would just love it if technology (in the case of social.coop, running various web services) was designed to be accessible to people to run, instead, all the tooling/processes/practises (software libraries, apps, frameworks, server management, etc) we use are borrowed from standard businesses, which work on the assumption there is a pool of skilled/ready/willing techies and other workers to implement it all, and a huge bulk of the development of technology goes towards enclosing capabilities, not sharing them. Oh what a world it could be.

NS

Nathan Schneider Fri 6 Mar

So glad to see my favorite friends Illich and Schumacher here:)

My inclination is to take a highly experimental and playful approach, testing out various tools on a trial basis and seeing what people like. I'm particularly interested in ideas like the DAO experiment and Matrix, which is a really fascinating project.

My recommendation is to create a [testing] framework in which we run trial efforts to test user interest and technical requirements, for say a month at a time.

NS

Nick Sellen Tue 26 May

To date, the tech team (of which most of it is me right now) has barely had enough motivation/capacity for keeping mastodon running and updated.

I do like an idea to add more tools, and a methodology to work out how to do it, but it has to be grounded in the reality of now too. You can see a nice place to sit across the valley, but how to get there when there is no bridge?

I have a feeling there is a possible fork in the approach here:

1) work with the small seed that I hope is still growing in our tech team, we can work to build up a bit more communication between people, and find out how to motivate people more... step by step

2) re-imagine social.coop as a cloudron/yunohost/sandstorm/collective-tools/fairapps instance

Personally, I can work with 1 - most of my life the past few years has been working with tech projects that lose all the developer/tech motivation, and help build it back up (not really happening with social.coop so fast, in truth, social.coop doesn't motivate me very much, I don't really know what the project really is besides the place I go and scroll posts occasionally, and only really joined the tech team to save it from being turned off entirely).

If 2 is the way, then it wouldn't be for me for a variety of reasons, but I could help the transition.

M

mike_hales Tue 26 May

A couple of significant prompts put up by you here today @Nick Sellen thanks. I'm a bit snowed, and can't respond substantially at present. But I feel these are things all social.coop folks should be pondering.

We still don't seem to have a core (or identifiable, recruitable cores) of collaboration to organise around - except hosting and moderating a mastodon instance - two commitments which, as you're pointing out, fall into two distinct buckets of attention anyway, and lack somewhat in real-world grounding?

The collaboration that there is, happens in streams of toots (yes?). But THAT isn't 'a project' by a collective, is it? It's peer-to-peer communication in multiple networks. Is being a 'common carrier plus ethics' what social.coop set out to be? Twitter plus ethics? Telegram plus ethics?

M

mike_hales Fri 6 Mar

Work-oriented design of computer artefacts

Some references attached, to Scandinavian 80s/90s tradition of work oriented design of computer artefacts, and 'collective resource' tradition of codesign with labour unions . . From the days before git/P2P/agile code hacking, web apps & digitally mediated organisation, this tradition invites remixing in today’s coop practice. Its 'tool' notions, coproduction principle and weaving of tech/theorising/democracy are valuable for us here?

A key item is Pelle Ehn’s 1988 PhD thesis/book drawing on 20 years politicised design practice in Denmark Sweden Norway: Work oriented design of computer artefacts. It's posted here.

The approach cross-fertilised in the 90s, as trade union drivers faded, field anthropology (ethnography, ethnomethodology) made an appearance, and cooperation tech became generic. The fields of Computer Supported Cooperative Work and Participatory Design emerged. There’s a 2016 Handbook of Participatory Design. Some samples of this stuff are here.