OParl Governance

[akuckartz]

Aus gegebenem Anlass halte ich es für notwendig, dass in dem Dokument zumindest knapp ausgeführt wird, wie im Falle von fehlendem Konsens zu wichtigen Aspekten der Spezifikation Entscheidungen getroffen werden. Dazu gehören insbesondere Antworten auf die Frage wann und wie welche Stakeholder involviert werden.

[akuckartz]

Zwei Anregungen, die jedoch nicht 1-zu-1 übernommen werden können:
http://www.w3.org/2005/10/Process-20051014/policies.html#Consensus
http://tools.ietf.org/html/rfc2026#section-6.5

[eFrane]

Dieses Problem sollte meiner Ansicht nach im Zusammenhang mit #208 geklärt werden, d.h. es sollte einen Abschnitt über den gesamten Bearbeitungsprozess geben.

[the-infinity]

Lösungsvorschlag in 5bd4f88 .

[konstin]

Meiner Meinung nach können wir das issues schließen.

[akuckartz]

Siehe 5bd4f88#commitcomment-13694591

Als ich dieses Issue angelegt hatte gab es den Anspruch, dass OParl 1.0 ein "Standard" sei oder sein solle. Da dieser Anspruch nicht mehr besteht - was sich auf oparl.org bisher allerdings nicht widerspiegelt - ist auch die Bedeutung dieses Issues reduziert.

[konstin]

Aus 5bd4f88#commitcomment-13694591

Haben sich diese beiden Organisationen dazu verpflichtet?

Meines Wissen nicht, aber ich kann gerne beide anschreiben und um eine offizielle Stellungnahme bitten.

Da dieser Anspruch nicht mehr besteht

Wieso sollte denn OParl kein Standard mehr sein? Es werden doch immernoch möglichst eindeutige Regeln definiert, an die sich alle, die OParl implementieren wollen, halten sollen, und das ist doch das Hauptmerkmal eines Standards, oder?

[akuckartz]

@konstin Das sind Merkmale einer Spezifikation. Nicht jede Spezifikation ist auch ein Standard.

[konstin]

Wenn die großen RIS-Hersteller die Spezifikation umgesetzt haben, wird OParl zum Standard werden, weshalb das Thema der Weiterentwicklung und Konfliktlösung bereits vorher geklärt werden sollte.

[akuckartz]

@konstin Zu der Zukunfts-Prognose möchte ich mich hier nicht äußern. Ich bin durchaus für möglichst klare Regelungen - nicht zuletzt deshalb, weil Intranparenz im letzten Jahr bereits zu einer Spaltung geführt hat.

Ich halte den Vorschlag 5bd4f88 aber für wenig durchdacht. Abgesehen davon, dass die genannten Organisationen erst einmal zustimmen müssten (dazu müssten sie sich für willig und fähig halten zu fundierten eigenen Entscheidungen bei möglicherweise kniffligen technischen Fragen zu kommen), so würde selbst das kaum helfen. U.a. aus diesen Gründen:

• Die OKF DE kann über JSON-LD Unterstützung #237 nicht entscheiden ohne sich dabei im Ergebnis entweder in Widerspruch mit sich selbst zu setzen oder gegen die gegenwärtige Ausrichtung von OParl Position zu beziehen. Aus ähnlichen Gründen kann die OKF DE auch andere technische Entscheidungen kaum fällen.
• Dass sich zwei verschiedene Oganisationen selbst zu einem Konsens bei beliebigen Fragen verpflichten mag ja bei Bundestagsparteien funktionieren die beliebig opportunistisch sind. Dass OKF DE und Vitako diese Eigenschaften in ausreichendem Umfang haben wage ich zu bezweifeln. Was würde denn passieren, wenn OKF DE und Vitako entgegengesetzte Positionen zu einem technischen Aspekt von OParl beziehen? Würde dann eine der beiden Organisationen ihren Standpunkt um 180 Grad ändern, um zu einem Konsens zu kommen? Ich halte das für wenig realistisch.

[akuckartz]

Ich halte das von mir vor zwei Jahren eröffnete Issue nicht für wirklich für erledigt, kann und möchte mich aber nicht weiter darum kümmern.

[konstin]

Die in Kapitel 1.7 beschriebene Lösung ist mehr als ausreichend, daher ist dieses Issue erledigt. Zwar müssen die Details der Besetzung noch geklärt werden, das ist aber eine Aufgabe unabhängig von der Spezifikation.