Anzeige von Resolutionen in der App

[behrmann]

Ein schönes Feature für die ZaPF-App wäre, wenn man nach einem AK eine Reso anmelden könnte, so dass neben AKs mit einer Reso ein Button mit Link zur aktuellen Fassung der Reso auftauchen würde. Dafür muss ein Veröffentlichungsmechanismus für die Resos gefunden werden.
Dadurch könnte man allerdings aus der ZaPF-App heraus alle Resos erreichen, was nicht nur das Arbeiten im Plenum vereinfachen würde ("Kann mal jemand die Reso auf einem USB-Stick bringen?"), sondern könnte auch das Vorbereitetsein aller ZaPFika verbessern, da die Resos einfacher und zentral erreichbar wären.

[scattenlaeufer]

Ich habe es mal als enhancement gelabelt.

Eine Möglichkeit, eine dafür geeignete Veröffentlichung von Resos zu realisieren, wäre ein Reso-Repository, in das das die Resos gepusht werden. So bekommen die Entwickler mit, wenn es was neues gibt, was in die App eingebunden werden muss und vor allem hätten wir mal alle Anträge schön gesammelt an einem Ort. Die Reso, die wir dazu hatten, hat die Redeleitung ja unter den Tisch fallen lassen.

[behrmann]

Ich denke wir koennen ein Reso-Repo mal mit Bremen abstimmen, dann
koennte man ein zu schreibendes Git-Tutorial auch darauf abstimmen.

Vielleicht koennte man das Reso-Repo dann als submodule in die App
einbinden, so dass man im Reso-Repo seine Reso per Pull Request
einreichen und updaten kann und die ZaPF-App dann daraus die Resos
einbinden kann.
Ein submodule fuer die eigentlichen Inhalt der ZaPF waere vielleicht
zusaetlich auch eine saubere Loesung um Content von der App zu trennen.

On 06/02/2014 03:50 PM, Björn Guth wrote:

Ich habe es mal als enhancement gelabelt.

Eine Möglichkeit, eine dafür geeignete Veröffentlichung von Resos zu
realisieren, wäre ein Reso-Repository, in das das die Resos gepusht
werden. So bekommen die Entwickler mit, wenn es was neues gibt, was in
die App eingebunden werden muss und vor allem hätten wir mal alle
Anträge schön gesammelt an einem Ort. Die Reso, die wir dazu hatten, hat
die Redeleitung ja unter den Tisch fallen lassen.

—
Reply to this email directly or view it on GitHub
#4 (comment).

[scattenlaeufer]

Submodule wären eine mögliche Lösung, würden dem ganzen aber nochmal ein
nicht zu verachtendes zusätzliches Level an Komplexität geben.
Andererseits würde das Trennen von Inhalten und der eigentlichen App es
auch anderen BuFaTas wesentlich einfacher machen, unsere App zu
übernehmen. Mindestens die PsyFaKo hat das ja getan.

Ich werde mir da mal Gedanken drüber machen und auch mal mit Bremen
reden, in wie weit die sich in der Lage sähen, ein Reso-Repository zu
managen, denn wird werden da dann auch immer noch wahrscheinlich den
Großteil der Resos per USB-Stick im Tagungsbüro erhalten und dann müsste
wer auch immer da gerade sitzt in der Lage sein, die Reso ins Repository
einzupflegen.

Es stellt sich dann auch die Frage, ob man ein Repository für jede ZaPF
haben will, oder eher ein generelles Reso-Repository, in dem dann immer
Unterordner für die verschiedenen ZaPFen liegen. Das könnten theoretisch
ja auch wieder Submodule sein.

On 02.06.2014 15:56, Jörg Behrmann wrote:

Ich denke wir koennen ein Reso-Repo mal mit Bremen abstimmen, dann
koennte man ein zu schreibendes Git-Tutorial auch darauf abstimmen.

Vielleicht koennte man das Reso-Repo dann als submodule in die App
einbinden, so dass man im Reso-Repo seine Reso per Pull Request
einreichen und updaten kann und die ZaPF-App dann daraus die Resos
einbinden kann.
Ein submodule fuer die eigentlichen Inhalt der ZaPF waere vielleicht
zusaetlich auch eine saubere Loesung um Content von der App zu trennen.

On 06/02/2014 03:50 PM, Björn Guth wrote:

Ich habe es mal als enhancement gelabelt.

Eine Möglichkeit, eine dafür geeignete Veröffentlichung von Resos zu
realisieren, wäre ein Reso-Repository, in das das die Resos gepusht
werden. So bekommen die Entwickler mit, wenn es was neues gibt, was in
die App eingebunden werden muss und vor allem hätten wir mal alle
Anträge schön gesammelt an einem Ort. Die Reso, die wir dazu hatten, hat
die Redeleitung ja unter den Tisch fallen lassen.

—
Reply to this email directly or view it on GitHub
#4 (comment).

—
Reply to this email directly or view it on GitHub
#4 (comment).