Inputs aus der Romandie

[carlobeltrame]

Ich entnehme den Mails von Koala folgende Inputs / Vorschläge:

• [x] In der Romandie sind Beobachtung und Evaluation zwei separate Phasen. Während dem Beobachten wird alles subjektive (Interpretation, Eindruck, Wichtigkeit) bewusst ausgeschlossen. :arrow_right: Vorschlag: #154 umsetzen, dann können die Kurse auch erst auf die Evaluations-Phase diese Felder einschalten
• [ ] Der Begriff "exigences minimales" für Anforderungen passt nicht zur Verwendung in der Romandie. Soweit ich es verstehe arbeiten die romand Kurse weniger mit "Mindestanforderungen" die alle zu 100% erfüllt werden müssen, und eher mit gruppierten Soft-Kriterien ("indicateurs"), und in jeder Kriterien-Gruppe ("objectif") müssen zB 66% oder 75% der enthaltenen indicateurs erfüllt werden. Aus dem Topkurs kommend hatte ich das für eine eher schwierige Vorgehensweise gehalten, aber es kann in diesen Kursen trotzdem noch "KO-Kriterien" geben. Beobachtungen können dann entweder frei oder direkt zu einem Indikator zugehörig gemacht werden. :arrow_right: Option 1: Mindestanforderungen "indicateurs" nennen und in "objectifs" gruppieren können. Mit #124 planen wir bereits gruppierte Anforderungen, aber ohne Funktionen für das "Bestehen" einer ganzen Kriterien-Gruppe basierend auf einem Prozentsatz. :arrow_right: Option 2: Mindestanforderungen "indicateurs" nennen und in Qualis gruppieren. Vorteil: Die existierende Fortschrittsanzeige der Qualis gäbe bereits einen Hinweis auf den Prozentsatz der positiven Indicateurs. Nachteil: Eher aufwändig zum bearbeiten da die indicateurs nur im Fliesstexteditor als bestanden markiert werden können; das Quali-Feature könnte ausserdem nicht mehr so einfach für mehrere Rückmeldegespräche und fürs finale Rückmeldeformular im Kurs genutzt werden. :arrow_right: Option 3: Mindestanforderungen "objectifs" nennen und Sub-Anforderungen ("indicateurs") erfassen können. Hätte Auswirkungen aufs Rendering / Management von bestandenen Anforderungen in Qualis. Ginge wieder in die Richtung von ma_detail das wir mal entfernt hatten und uns auf #72 geeinigt hatten. Dieser Ansatz wurde im Fork https://github.com/diegosteiner/qualix/commits/zli-blj für die dort ebenfalls eingeführten "Indikatoren" gewählt. :arrow_right: Option 4: Mindestanforderungen "objectifs" nennen und innerhalb der objectifs vorgegebene Beobachtungen ("indicateurs") zu fixen Themen definieren können. Eine solche "Indikator-Beobachtung" könnte entweder ein Template für eine Beobachtung oder eine speziell verknüpfte Beobachtung sein. Auf jeden Fall müsste der schon vor dem Kurs bestimmte Text des Indikators in der Beobachtung enthalten sein, am besten könnte der Indikator auch noch von jedem TN erfüllt oder nicht erfüllt werden. Also quasi eine Art Beobachtungsauftrag für eine Anforderung statt für einen Block. Diese Indikatoren müssten aber trotzdem auf dem Spick in den Blöcken sichtbar sein, da man dann nicht mehr ganze objectifs, sondern nur einzelne Indikatoren in einem Block beobachten soll.
• [ ] Da die Kurse auch oft in drei Wochenenden durchgeführt werden, gibt es viele Abgaben die die TN einreichen müssen. Beobachtungen über die Qualität dieser Dokumente sind nicht immer mit Blöcken verbunden. :arrow_right: Vorschlag: Für solche Abgaben eigene "Blöcke" erstellen. Vielleicht müssten wir dabei den Begriff "Block" auf "Zeitpunkt" der Beobachtung oder "Wann" o.ä. generalisieren? :bulb: In https://github.com/diegosteiner/qualix/commits/zli-blj wird Qualix für Lehrlingsbeobachtung verwendet, und da dort die Beobachtungen eher zu Tagen gehören wurde die forcierte Beziehung Beobachtung :left_right_arrow: Block auch schon "weggehackt". Das wird dort aber immer wieder zu Problemen mit unseren neuen Features führen, daher würde ich lieber eine gute generelle Lösung bei uns einbauen.
• [ ] Im Spick sollte, falls wir Anforderungen neu "indicateurs" nennen sollten, der Hinweis auf "Vois-tu encore des points de cours sans indicateur?". Also konkret sollte der Hinweis den User ansprechen, solange noch nicht alle Blöcke mit Anforderungen verbunden sind, statt nur dann wenn kein einziger Block mit einer Anforderung verbunden ist.