Teilhabe einfach und effektiv gestalten

OpenCoDE ist eine fantastische Idee und hat Potential mit internationalem „Vorbildharakter“, wenn wir diese Chance richtig nutzen. :slight_smile:

Folgende Optimierungsvorschläge als konstruktives Feedback:

  • Bislang fehlt es an einigen Stellen noch an einem einfachen Zugang um die Teilhabe einfach und effektiv zu gestalten.

  • Von Seiten BMI ist die „Landingpage“ ww personalausweisportal.d e/SharedDocs/kurzmeldungen/Webs/PA/DE/2023/06_republica_letzter_Tag der Ausgangspunkt

Wer dann hier gitlab.opencode.d e /OC000016444549/eidas2 landet ist nicht wirklich gut abgeholt.

Meine konstruktiven Vorschläge zur Optimierung:

  • Ein kurzes HowTo zu Partizipation sowie Informationen zum Ablauf die von allen Zugangsstellen leicht auffindbar sind, dies lässt sich schnell ergänzen

Konkrete Fragen, die sich (vermutlich nicht nur) mir stellen:

  • Wie funktioniert der Feedback Prozess? (Mit Issues bei GitHub und einem Diskussionsforum bin ich vertraut)
  • Welche Informationen gehören wohin?
  • Wie wird wann von wem in welcher Rolle moderiert und koordiniert?
  • „Wer Anmerkungen, Kommentare oder eigene Vorschläge zu den auf Open CoDE diskutierten Punkten hat, kann sich gerne dort zu Wort melden.“ => Wie und wo soll das Feedback einfliessen?

Auf der Seite https://gitlab.opencode.d e/OC000016444549/eidas2 gehen die obigen Links von OpenCoDE von der Navigationsleiste der Seite schnell verloren, die Startseite im GitLab sollte idealerweise direkt eine Welcome Message mit weiteren Instruktionen beeinhalten.

Wenn ich den initiierten Prozess richtige deute (Seite 17) des PDF Papers im Git, dann zielt die interne Bemühung darauf auf, gebunden an Fristen gebündelt Feedback zu sammeln und dann in einem nachgelagerten Schritt zu 100 Prozent öffentlich und transparent zu kommunizieren.

Warum? Ich würde an dieser Stelle Liquid Democracy, also einen Prozess in Echtzeit, Git-basiert erwarten. Zumindest in der nächsten Ausbaustufe eines solches Kommentierungssystems.

Ferner würde es helfen, wenn Qualitätsrichtlinien steuernd unterstützen in welcher Form Feedback erwartet wird.

Klingt banal, aber Open CoDE e/mitmachen diese Seite und den bereits genutzen Call2Action direkt auf der BMI Seite und direkt auf verlinkten der Seite des GitLab in dem Repo einbinden. Sonst steht da im Grunde schon alles, aber die Verbindungen fehlen und können leicht ergänzt werden um genau das klar zu kommunizieren.

Nach meiner persönlichen Einschätzung wird es unnötig lange dauern bis Vertreter öffentlicher Träger hier aktiv als Teilnehmende partizipieren. Der Weg und die Umsetzung in dieser Form sind genau richtig und können an dieser Stelle gar nicht klar und deutlich genug kommuniziert werden.

Wenn es bei den zwei Feedback-Kanälen Git + Diskussions-Forum bleibt sollte klar differenziert werden, welche Informationen wohin gehören und wie das koordiniert wird. Übergreifende und cross-funktionale Informationen sollten koordiniert moderiert sein.
Mit jedem weiteren Kanal erhöht sich die Komplexität.

Mehr Orientierung und eine klare Struktur im Prozess zu bieten wird die Akzeptanz auf allen Seiten deutlich heben.

PS: Die obigen Links musste ich aufgrund der Foren-Restriktion cuten

5 „Gefällt mir“

Meiner Erfahrung nach (und die basiert zum Teil auf Aussagen von Mitarbeitenden der Firma Komm.ONE, die OpenCoDE im Auftrag des BMI aufgesetzt haben) ist hier niemand als Community-Management unterwegs (weil es anscheinend nicht beauftragt und damit auch nicht bezahlt wurde/wird).

Selbst administrative Kontaktversuche wegen Deaktivierungen eines Benutzers auf Grund irgendwelcher nicht dokumentierter automatischer Content-Sperren (angeblich zu oft gepostet - WTF!?) blieben bisher erfolglos.

Wenn Feedback zu OpenCoDE dann wohl besser im entsprechenden GitLab-Projekt, dort kommt ab und zu mal eine Reaktion - aber nicht oft.

Die GitLab Strukturen bieten derzeit noch keine Struktur für solche übergeordnete Themen und wenn Feedback hier nicht gelesen und ausgewertet wird, dann beeinträchtigt dies das Projekt mit seiner guten Intention erheblich.

Community Management und aktive Teilhabe sind genauso wichtig wie eine positive Fehlerkultur. Auch die Restriktion mit dem Screenshot posten ist problematisch, wenn ich meine nicht per Photoshop klein für die webbasierte Nutzung klein gerechnet hätte, dann bleibt der Upload erfolglos. Aber wieviele hier haben schon Zugriff auf solche Tools oder den Nerv dazu?

Um Frustration zu vermeiden: Der offizielle Kontakt und Support befindet sich unten auf der Landingpage unter Kontakt.

Hier der Link

Dieser meldet sich immer und wenn eine Antwort nicht sofort kommt heißt das nur dass diese aktuell intern besprochen wird.

Für diesen Fall kann ein Ticketsystem helfen. Damit können Anfragende, den Status ihres Anliegens nachvollziehen.
Erfahrungsgemäß möchten Anfragende ein Problem gar nicht sofort gelöst bekommen, sondern nur sicher sein, dass etwas „unter den Tisch fällt“.

Eine bewährte Open-Source Lösung für IT- Support ist z.B. zammad, vor allem auch, weil es sich z.B. mit gitlab Issues kombinieren lässt.

Hinter den Emails befindet sich ein Ticketsystem.

Moin, als erstes schlage ich vor, den Zugang zu Kontakt zu vereinfachen. Hier auf dieser Seite, finde ich es nicht. aber vielleicht bin ich blind…

Weder unten im Footer noch im Menu:

Wiki ist doch was anderes als das Forum / Community. Und innerhalb des Kontakt zu technischen Problemen wäre es von Vorteil wenn klar aus einem angeleiteten Supportprozess hervorgeht was wann wo anfällt. Aber das wichtigste und einfachste in der Umsetzung ist der einfache Zugang…

Super. Sehr positiv unter Kontakt sind die vielen Kontaktwege die angeboten werden. Der Fall Support ist nicht aufgeführt, würde also unter allgemein fallen, könnte hier noch ergänzt werden Allgemein & Support zum Beispiel um nicht noch eine weitere Kategorie zu eröffnen.

Bildschirmfoto 2023-06-23 um 08.33.26

Technisch kommt dort wiki.js und Vue.js mit vuetifyjs und Bootstrap zum Einsatz?

Das ist doch schon mal ganz cool :slight_smile: