Practising Protocols X Femfester Workshop Pad
In the workshop to write the Femfester, In-grid members came together in person and online, ate some nice food and tasty snacks, caught up, but also set up their new server with Servus, and along the way (con)figured out what relations and politics we wanted to bring there and how!
These are the prompts we made alongside setting up our VPS server with our members. Each step we reflect, re-imagine, and re(con)figure out what we desire each relation, space and dynamic to be for us together. These were done to enable us to find our collective orientation whilst orienting our infrastructures. These are all notes of much deeper and complex conversations, but try to map and inform where we are at.
Here was a pre-figuring out of what we desired our coding relations to be.
Doing things in pairs / groups
Making sure everyone is on the same page before starting work
Documentation *so choices can be rolled back/remade if necessary
Be soft with sudo
Working slowly, doing things in steps, not rushing through, stopping at a step rather than getting half way through something.
double check what you are about to do before doing it, as may be irreversible * Talk
Consider institutional implications for managed machines
Keep everyone up to date.
Here we logged into the server through SSH and questioned the metaphor and figure it brings of a handshake.
Here we approached the "sudo" command (means super user do), which enables admin rights on a system and for you to undertake maintenance. Here we imagined how we desired to configure these processes and rights.
When sudo we should take extra care to make sure what we are doing is wanted by all. Work in pairs (if you can)? For any major changes at least...
Should we be anonyms sudo? Or su user to track
Should sudo be used alone?
Here we set up the users for the server, but also took time to manifest the figures we imagined being on this server. Here questioning the norms of user/server and individualized relations and how we want to enact them together otherwise.
Not users but:
maintainers?
carers?
Member?
Players?
Collaborators and caretakers
it is nice to be individuals in a collective
characters
Conversationalists
persona
Infra as another collaborator not users/using
Fistulas
Here we uploaded SSH keys for those accounts and then closed password access to the server. This in norms makes the server "sercure", we took up this to imagine what safety means for us instead of security.
Is transparency safety? No single point of failure/hidden information or is it helpful not to be able to delete something.
Understanding the risks and making decisions based on understanding
Not having knowledge lie with one person
Everyone should have ability to access knowledge
Don't make ring-fence around particular roles
How do we make people feel unafraid of making changes
But at the same time aware of what the "risks" are
Is it more about learning how to move with caution and care
The idea is not to move fast / gung-ho / "trigger happy",
but rather checking and double checking before doing
How can we do things like check a process before doing something, I'm thinking of Nginx command to check if the config file is valid before restarting the server... can we try to research that for all software we use? If we end up making our own tools, can we build caution / testing / care into our procedures, so that people feel confident that the changes they are about to make are safe to do?
Demystifying what is safe protocols etc.
Boundaries are helpful between the server and outside the server
Here we logged into TMUX an SSH multiplexer (basically a way to collaborate on server work). We wanted to imagine what collaborative relations we desired, but got caught up on TMUX technicalities. . .
Turns out that typing exit in a string seems to exit it also
Nominate who will type, and check in when people are getting tired.
Take turns, maybe signal end of a string/phrase? Over, fin, out! fnx your turn bbz