Add subprojects/studios feature

[saerdnaer]

Aktuelle Property-Vererebungshierarchie:

• Event-Projekt für die Konferenz
  • Meta-Ticket (Fahrplan-ID & -Metadaten)
    • Recording-Ticket (Sprache, etc)
      • Master-Encoding-Ticket (MP4)
      • weitere Encoding-Tickets für die Subformate: WebM MP3, Opus, SD-Formate, etc.

Wunsch-Hierarchie für dezentrale Konferenzen wie rC3:

• Event-Projekt für die Konferenz rC3-2021
  • Studio-Projekte z.B. hamburg, r3s, import, etc.
    • Meta-Ticket (Fahrplan-ID & -Metadaten)
      • Recording-Ticket (Sprache, etc)
        • Master-Encoding-Ticket (MP4)
        • weitere Encoding-Tickets für die Subformate: WebM MP3, Opus, SD-Formate, etc.

Hmm, wobei man könnte eigentlich auch noch ein/zwei Schritte weiter gehen:

• Globale Properties aus Projekt 0
  • Event-Series Properties wie z.B. rC3 oder FOSSGIS
    • Event-Projekt für die Konferenz rC3-2021 oder FOSSGIS 2019
      • Studio-Projekte z.B. hamburg, r3s, import, etc.
        • Meta-Ticket (Fahrplan-ID & -Metadaten)
          • Recording-Ticket (Sprache, etc)
            • Master-Encoding-Ticket (MP4)
            • weitere Encoding-Tickets für die Subformate: WebM MP3, Opus, SD-Formate, etc.

Related: https://github.com/crs-tools/tracker/issues/186

Zu klären:

Würde man dann den Fahrplan Import nur auf Sub/Studio-Projekt Ebene machen, oder auch auf Konferenz-Ebene? Falls letzteres müssen wir irgendwo die Zuordnung zwischen Raum und Subprojekt hinterlegen.

[dbt4u]

Aus Sicht eines Studios, wäre es gummigut ein Projekt zu haben, wo wir keine Angst haben müssen ein Setting für ein anderes Studio zu überschreiben. Was darüber an Abstraktionen sinnvoll wäre, wage ich nicht zu beurteilen, aber gründsätzlich klingt global -> series -> event -> studio imho vielversprechend und komplett.

Und vielleicht könnten man beim Erzeugen eines Projektes einfach ein Art "same as" ergänzen. So könnte z.b. ein neues Studio-Projekt für z.b. ccch oder r3s von einem vorherigem abgeleitet werden. Kenn ich so vom Jenkins.

Vielleicht sogar ergänzend, alternativ mit einer kleinen Liste an abstrakteren Projekt-Typ-Templates, z.b. "Tracker-Assisted Cut", "Video-Download Centric". Vermutlich gerade am Anfang sinnvoll wenn noch keine oder nur wenige Studio-Projekte vorhanden sind.

[jjeising]

Was genau soll das denn abdecken? Nur eine Vererbung von Properties? Nutzerrechte? Profile?

Was würde das lösen, was #186 nicht abdeckt?

Vielleicht sogar ergänzend, alternativ mit einer kleinen Liste an abstrakteren Projekt-Typ-Templates, z.b. "Tracker-Assisted Cut", "Video-Download Centric". Vermutlich gerade am Anfang sinnvoll wenn noch keine oder nur wenige Studio-Projekte vorhanden sind.

Project Templates mit Properties hatten wir tatsächlich schon mal diskutiert (und auch befürwortet), siehe #186.

[dbt4u]

Ja! #186 klingt schon sehr nach der Projekt-Typ Template Idee. Brauchen wir dann hier an dieser Stelle nicht weiter vertiefen.

Eine Unterscheidung zwischen einem Event-Projekt und Studio-Projekt ermöglicht es unterschiedliche Vorgehensweisen wie http-tracker-flow, import-tool, fuse-tracker-flow, scp, etc. pp. vor allem bei verteilten Events unter einen Hut zu bringen.

Im Endeffekt könnte dieses Ticket #243 als ein UseCase für #186 verstanden werden.

[saerdnaer]

Ich dachte jetzt tatsächlich primär an eine Vererbung der Properties. Beim rC3-2020 hatten wir an die 10 Projekte, wenn sich da nen Property während der Veranstaltung bzw. nach dem Initialen kopieren ändert musste man in jedes einzelne Projekt und den Wert dort anpassen. Oder man greift halt direkt via SQL auf die Postgres zu... 🙈

Nutzerrechte wären natürlich auch eine Idee, aber das wäre dann wohl eher nen eigenes Ticket, oder? Wobei man da dann vielleicht eher Richtung Gruppen gehen will die dann durch Anbindungen an einen Identity Provider mitgegeben werden.