Gr*・。゚. erica .*・。゚gr

From Media Design: Networked & Lens-Based wiki
Revision as of 22:17, 28 March 2022 by Erica (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


pro:

educational value, experimental/"explorative" value, risk with no fear, push the limits, we were super cool, we did a super interesting project, we worked on building blocks rather than polished finalized contents + appearance (which sometimes could also be a bug and not a feature) "building meaning retroactively", cit. kimberley, is someting supercool and we did it in a very nice way, because the need for finding a meaning could also block the production/practice sometimes, especially if it's crazy experimental, and I think it's extremely important to learn to give meaning to try-outs, tests, errors, failures, non-finished things etc. and to be flexible with it. SI16 has been in a way a crash course for giving meaning retroactively, and I believe it's a fundamental skill for any experimental practice.

unexpected horizontality of the production process.


cons:

"explorative" phase very long: it didn't allow us to take as much care of the contents as they deserved. (it can also be a feature and not a bug tho, like: it's a starting point for a project that has a lot of potential and a very long life after the launch.) the previous cons led to play safe in the distribution of roles and workload especially towards the end of the production phase (although we actually tried the most horizontal and collective making process for what we were doing), less awareness of the launch.

difficulties in working together on the soupboat, it's too fragile and sometimes it can be disempowering to work on the same notebook/script if people in the group are confronted with a page full of code without neither understanding nor seeing the succession of steps and the updates of the work. the consequence is that someone might feel useless or even afraid of making changes on a shared code, and it shouldn't work this way.


room for improvements:

make clearer reciprocal expectations, make clearer what everybody finds interesting in what we're doing, how to empower each other's interests and production phase with realistic distribution of roles and workload.

communication for sure, i'd be down for writing to nor and ask her tips or exercises that we could do in order to improve our group communication and work. also: cristina was a superhero in helping us to take decisions, now that she won't guide us I'd like to discuss how we take decisions in our group, bc I think voting is not (most of the times) the best solution at all. also because __I_NOTICED__ many if not all of us have quite particular ways of leading some aspects of the production process and a need for understanding and foreseeing the bigger picture beforehand; we did a very good job of real trust there already, for the next time we could be more mindful towards our needs on this take and trying to express them, and compromise them (?) if they clashes with other people's ones.

dunno if this is a reasonable take on the topic of the needs, because on one side compromising the satisfaction of one's own need can also be frustrating, but then could it be a solution to make them explicit and also let others to respond to it and give or ask for trust/agency?

note: many time the frustration came from the need for feeling useful and capable and of having a meaning in what we were doing

Something to improve for myself as well, the communicaiton in the soubgroups. During the last days I had a lot of difficulties in communicating and let go things because of time pressure and work load, but also desynchronization and unclear decision making

clarity on where we work, which folder is the most updated one, what is the pipeline--> MICHAEL & MANETTA PLZ LET'S LOOK AT GIT WHEN WE'LL BE BACK AND MAKE A GIT PIPELINE FOR COLLECTIVE WORK.