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

From XPUB & Lens-Based wiki
Revision as of 23:33, 23 December 2021 by Erica (talk | contribs) (Created page with " ---- wip ---- feel free to stick around but plz keep in mind it's still a pure stream of thoughts explorative phase vs production phase: # as a group # as a subgroup # ind...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
---- wip ----

feel free to stick around but plz keep in mind it's still a pure stream of thoughts

explorative phase vs production phase:

  1. as a group
  2. as a subgroup
  3. individual


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, like kimberley said, 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. (very impressed and proud of you guys)elaborate on this

the means we used have not been taken for granted at all, elaborate on this too


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: performative aspect,

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.

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.