Meeting 2023-09-04

Tasks for Everyone

To be done until Friday 1.9.2023:

  • Do minimum 10min free writing
  • Buddy talk: Talk about your case study
  • Get current issues, PRs and use cases (UC) done
  • Update sprint plan
  • Do reviews of PRs in main repo and submissions

Individual Tasks

To be done until Friday 1.9.2023:

  • Jannis&Felix: Schnittstellenbeschreibung, refactor framework für Wetterstation+sensors+buttons, issue erstellen setup, (opensesame read from chat)
  • Christoph: fix various small usability issues, copy&paste UC
  • Adi: E2E tests seeds, 3.3 release, finish Makefile, split pre-commit for CI, Lukas Agenda, unify Dockerfiles
  • Chris: scaper fertig, plants hierarchy+relations
  • Moritz: selection, seeds UC done, polygon, page test, UC done (grid)

To be done for Jannis and Christoph N. until Wednesday 30.8.2023:

  • submit/finalize TISS.txt
  • register in keycloak
  • Milestone plan update

Attendees

  • Chris K.
  • Jannis
  • Felix
  • Christoph N. (Protocol done)
  • Adi (Protocol done)
  • Moritz (Protocol done)
  • Markus
  • Yvonne

Buddies

  • Moritz & Chris
  • Jannis & Christoph
  • Adi & Felix

Agenda

  • 09:00 welcome
  • welcome game
  • Protocol: Chris K.
  • buddy talk: case study
  • frontend:
    • discuss usability concepts (copy&paste, multi-selection, tablet, timeline, plant relation, ...)
    • locators
  • report about free writing
  • Clustering/Mindmapping
  • Format: Markdown/LaTeX
  • task issues:
    • should anticipate implementation challenges
    • scope/further work should be clear
    • "definition of done" for UC part of task
    • specify backend tasks for Jannis
  • progress visible only if tasks are also done
    • create enough tasks to have regular progress and
    • enough outlook (but not too much to not overwhelm you)
  • 70/20/10 rule
  • Socrates Questioning, see unterlagen/socratic_questioning.md
  • 3.3 release
  • sprint plan
  • outlook

Outlook: Tasks for Everyone

To be done until Friday 8.9.2023:

  • Submit RQs and do Socrates Questioning on your own and other RQs, see unterlagen/socratic_questioning.md
  • Buddy talk: Talk about your methodolgy
  • Get current issues, PRs and use cases (UC) done
  • Create/update issues as needed for future tasks
  • Update sprint plan
  • Do reviews of PRs in main repo and submissions

Outlook: Individual Tasks

To be done until Friday 8.9.2023:

  • Jannis&Felix: Schnittstellenbeschreibung, Ablauf bei Initialisierung und Fehler, refactor framework für buttons+Wetterstation+sensors, issue erstellen setup, opensesame read from chat
  • Moritz: UC done (grid), seeds UC done, seeds page test, (polygon)
  • Christoph: fix various small usability issues, copy&paste UC
  • Jannis: backend tasks durchschauen
  • Chris: scaper fertig, plants hierarchy+relations
  • Adi: E2E tests seeds, 3.3 release, finish Makefile, Lukas Agenda

Meeting Notes

Wie ist es mit unseren Buddy Talk gegangen? Buddy Talks haben nicht stattgefunden. Wir sollen uns 10 Minuten einplanen für Free Writing zur Übung. Termin ausmachen zwischen Christoph, Markus und Yvonne wegen Usability.

Weitere Methoden statt freewriting: Mindmapping Clustering

Hilfreich um relation in seinem Thema zu finden.

Arbeit in Markdown(oder anderen Tools) schreiben ist auch okay, es muss nur ein pdf für TISS sein. Siehe die Arbeit von Nursultan als Beispiel.

Erstellung von Tasks rennt noch nicht so gut. Immer bevor wir implementierungs Tasks angehen, sollen wir ein Issue erstellen, welches beschreibt wie wir es angehen wollen. Die Hauptimplementation Challenges sollen beschrieben werden. Es sollen keine zusätzlichen Sachen eingefügt werden, die nicht besprochen wurden. In-Scope bleiben, wenn notwendig eigene Issues anlegen. Gäniges Problem, sachen werden nicht ganz zu Ende gemacht, einzelne Sachen von Implementierungen fehlen noch. Man soll ein Issue mit abschließenden Tasks dazu erstellen, falls es dazu kommt. Gegenseitig Issues erstellen kann vorteilhaft sein.

Research Questions, falls wir keine haben, sollen wir uns noch überlegen. Von Sokrates gibt es eine Methode, im Submission repo (/unterlagen) gibt es dazu eine Erklärung. PRs von anderen Leuten kontrollieren und RQ evaluieren.

Bei RQ ist es wichrtig das es nicht nur eine Ja/Nein Antwort darauf gibt (offene Frage), und das es eine Methodik gibt, die diese Frage beantwortet. Mit welcher Software, mit welchen Schritten habe ich meine RQ analysiert und beantwortet. Statt einer RQ kann man auch eine Hypothese aufstellen. RQ haben sich mittlerweile etabliert. Pause für openseasam 9:51-10:05