AgendaItem > Consultation: Zeigt wirklich jeder Tagesordnungspunkt nur auf eine Beratung?

[marians]

Aktuell ist dies im Dokument noch als Frage gekennzeichnet. Hier brauchen wir Feedback von den RIS-Herstellern.

Ist es richtig, dass ein bestimmter Tagesordnungspunkt (oparl:AgendaItem) auf genau eine Beratung (oparl:Consultation) zeigen kann? Damit könnte je Tagesordnugnspunkt nur maximal eine Drucksache/Vorlage beraten werden.

@bschalitz @BThie @sterni24

[sterni24]

Wir haben immer eine 1:1-Beziehung.

[BThie]

In der Praxis gibt es eine 1:1 Beziehung. Spezialfälle wie gemeinsame Sitzungen von Gremien sollten derzeit nicht weiter verfolgt werden.

[akuckartz]

Ich halte es für problematisch, dass Gremien durch Software gezwungen werden inhaltlich zusammengehörige Drucksachen unter separaten TOPs zu behandeln (und damit die Verwaltung politischen Gremien vorgibt, wie letztere in inhaltlchen Fragen vorgehen dürfen). Noch problematischer fände ich es, wenn dies auch noch in einer Spezifikation fixiert würde - insbesondere wenn dafür kein technischer Grund angegeben wird.

Was ist denn die Meinung der Kommunen dazu?

[akuckartz]

§ 12 Änderung und Erweiterung der Tagesordnung (§ 48 Absatz 1 GO) der Geschäftsordnung des Rates und der Bezirksvertretungen der Stadt Köln vom 14.12.2010 besagt dies:

(1) Der Rat kann vor Eintritt in die Tagesordnung mit der Mehrheit der Stimmen der
Ratsmitglieder beschließen,
...
b) Tagesordnungspunkte zu teilen oder miteinander zu verbinden,
...

Wie werden solche Verbindungen oder Teilungen von Tagesordnungspunkten in der Spezifikation modelliert ?

[BThie]

@akuckartz Das Beispiel der Stadt Köln taugt hier nicht, da es sich um ein Gremium handelt. TOP`s zu teilen, zu verbinden oder abzusetzen kann ja faktisch jedes Gremium noch vor Eintritt in die TO. Es wird übrigends kein Gremium durch eine Software zu irgendetwas gezwungen. Mit einer 1:1 Beziehung können wir den Punkt schließen.

[akuckartz]

@btie Was passiert denn, wenn der Rat der Stadt Köln beschliesst zwei TOPs zu verbinden und in beiden Ursprungs-TOPs die Behandlung je einer Drucksache vorgesehen war und diese Drucksachen verschieden sind? Was ist in OParl für diesen Fall vorgesehen?

[BThie]

*akuckartz Dieser Sonderfall kann doch jetzt für OParl 1 nicht relevant sein, ansonsten benötigen wir noch Jahre um überhaupt eine Spezifikation zu erhalten. Es ist hier nicht entscheidend etwas in OParl vorzusehen, da der Wille des Gremiums in diesem Fall nicht regelbasiert sein wird.

[akuckartz]

@BThie Wenn 1:n Beziehungen zugelassen werden, dann wäre das Problem aus meiner Sicht auf saubere Weise gelöst.

[akuckartz]

@BThie Eine Antwort auf die Frage

Was ist in OParl für diesen Fall vorgesehen?

würde mich für den Fall, dass 1:1 festgelegt wird interessieren - und Software-Entwickler müssen dies spätestens dann wissen, wenn sie dies implementieren wollen oder müssen. Ich sehe dann nur zwei Möglichkeiten:

• trotz Zusammenlegung von TOPs werden mehrere TOPs ausgegeben
• der Server wählt unter den Drucksachen/Beratungsfolgen des zusammengelegten TOP eine aus und gibt die anderen nicht aus

Übersehe ich eine Alternative?

[akuckartz]

Eine Alternative hatte ich übersehen:

• Schaffung einer neuen Drucksache mit den Inhalten der vereinigten Drucksachen

[sterni24]

@akuckartz Ich weiß nicht, woher diese Thesen stammen.

Ich empfehle Ihnen dringend, sich zu diesem Thema in den Ratsbüros zu informieren und dann die Sitzungen des Ratse und seiner Ausschüsse zu verfolgen. Ich hoffe, dass Sie daraus einige Erkenntnisse ziehen.

[akuckartz]

@sterni24 Der Empfehlung werde ich Folge leisten.

Mir ist allerdings nicht klar, was mit "Thesen" gemeint ist. Ich habe aus der Geschäftsordnung eines Stadtrats zitiert. Meine schlichte Frage war und ist: Was macht ein OParl-Server, wenn dieser Fall eintritt?

Falls bekannte gegenwärtig im Einsatz befindliche RIS-Systeme diesen Fall de facto aussschliessen - anders kann ich die bisherigen Kommentare nicht verstehen -, dann nehme ich das mit Interesse zur Kenntnis.

Ein Grund für eine entsprechende Kardinalitäts-Beschränkung in einer Spezifikation wäre aber auch das nicht. Bereits die allererste GO eines Stadtrats die ich mir dazu angesehen habe sieht diesen Fall ausdrücklich vor. Es ist also anzunehmen, dass dies auch für entsprechende Gremien anderer Kommunen gilt. Gleichzeitig ist es trivial, diesen Fall in der Spezifikation vorzusehen (durch 1:n). Auch für die Implementierer von Servern und Clients sehe ich keinen Unterschied im Implementierungsaufwand. Deshalb kann ich die Opposition gegen 1:n-Beziehungen aufgrund der bisherigen Kommentare nicht nachvollziehen.

[akuckartz]

Zum Thema Zusammenlegung von TOPs ein Extremfall, nämlich eine gerichtliche Entscheidung in der die Frage im Zentrum stand, ob zwei TOPs zusammengelegt waren oder nicht:

VG Freiburg - Beschluss vom 20.02.2006 - 1 K 351/06 -
http://openjur.de/u/607641.html

Einer der Richter hat daraus dann einen Lehrbuchfall gemacht:
http://vgfreiburg.de/pb/site/jum/get/documents/jum1/JuM/import/verwaltungsgericht freiburg/pdf/tr/Treiber2007.pdf

Ja, mir ist bekannt, dass so etwas nicht jeden Tag passiert.

[sterni24]

@akuckartz

Mir ist allerdings nicht klar, was mit "Thesen" gemeint ist.

http://de.wikipedia.org/wiki/These

Ich habe aus der Geschäftsordnung eines Stadtrats zitiert. Meine schlichte Frage war und ist: Was macht ein OParl-Server, wenn dieser Fall eintritt?

Ein OParl-Server kann an diesem Fall überhaupt nichts machen. Tagesordnungen werden durch die Verwaltungen aufgestellt. Vor Eintritt in die Sitzung können Tops (z. B. Tischvorlagen) hinzugefügt, Tops abgesetzt werden usw.. Während der Sitzung können Tops vorgezogen, verschoben, verwiesen, geteilt oder zusammen beraten werden. All diese Vorgänge werden im Sitzungsverlauf (Protokoll) festgehalten. Die Vorlagen selbst bleiben hiervon unberührt.

[akuckartz]

@stern24 Danke! Dann fehlen in der Spezifikation möglicherweise (weitere) klarstellende Aussagen bzw. sie enthält Widersprüche.

• Was repräsentieren die Meeting-Eigenschaft agendaItem und die dort verlinkten AgendaItem-Objekte? Immer den Zustand der Tagesordnung vor Eintritt in die Sitzung oder später den danach? (Ist das vom Server abhängig?)
• Falls immer der Zustand davor repräsentiert wird: was haben dann die Eigenschaften result und resolution in AgendaItem zu suchen?

[sterni24]

Wir lösen das so, dass wir die Tagesordnung vor der Sitzung "einfrieren" und dann zum Zeitpunkt der Protokollfreigabe den Sitzungsverlauf mit identischer bzw. modifizierter Tagesordnung bereitstellen.

Zur Klarstellung wäre für den Client ein weiteres Merkmal hilfreich. Am Sitzungstermin lässt sich das leider nicht festmachen, weil einige Verwaltungen hier Wochen mit der Erstellung und Genehmgung des Protokolls verbringen.

[akuckartz]

Ohne jede Absicht das hier verkomplizieren zu wollen: Ich überlege parallel, ob letztendlich eine eigene Klasse Agenda für Tagesordnungen sinnvoll ist: OpenGovLD#63 Das würde möglicherweise auch bei Versionierungen helfen.

Aktuell bin ich mir nicht sicher.

[sterni24]

Ich würde das nicht machen. Die Tagesordnung ist eine Art Beratungsleitfaden, der nach der Sitzung keine Rolle mehr spielt. Es ist allgemein üblich, die ursprüngliche Tagesordnung dem Sitzungsverlauf im Protokoll voranzustellen.

[lu-j]

Ich denke die Diskussion hat ergeben, dass es bei einer 1:1 Beziehung bleibt und wir Sonderfälle in OParl 1.0 noch nicht abdecken. Die Idee an den Client zu kommunizieren, dass die Dokumentation der Sitzung abgeschlossen ist und die Tagesordnungspunkte final sind, wird in #279 weiter behandelt.