Struktur + Verwendung GitLab


#1

Um @yala’s Input Rechnung zu tragen und als Vorbereitung für die Mail an die Solawis um für Mitarbeit in der Web Crew zu werben (letzter Absatz) würde ich gerne unser GitLab etwas mehr befüllen, damit wir eine rudimentäre Dokumentation am Start haben, in die sich Interessierte einlesen können.

Wir hatte uns in einer Telko mal geeinigt erst mal bei Deutsch als Kommunikationssprache zu bleiben, daher würde ich die GitLab-Struktur entsprechend übersetzen.

@digitales bitte gebt mal Bescheid, ob ihr die GitLab-Struktur so i.O. findet, damit wir nicht nachträglich Issues + Wiki-Seiten verschieben müssen. Sonstige Hinweise, Fragen o.ä. können ja nun ebenfalls hier besprochen werden oder in einem separaten Thread Platz finden, falls zu umfangreich.


#2

Du sprichst natürlich von der Struktur in https://lab.allmende.io/solawi, richtig?

Dann schlage ich vor ein paar Gruppen zu streichen und diese Anhand ihrer Verwendung umzubenennen, anstatt ihres Werkzeuges. Mir scheint es wurden sehr viele Issue Tracker erstellt, da die Projekte keinen Code enthalten.

Daher wäre es möglich diese in wenige zu konsolidieren und Kategorisierungen per Label zu realisieren. Dies ist auch der gewöhnliche Rat von @gandhiano: Weniger ist mehr.

Auch wäre es gut, wenn in dieser Begriffshierarchie ähnliche Objekte auf einer ähnlichen Ebene stünden. Demnach bliebe aus meiner Sicht folgende Struktur zurück:

  • Initiativen
    a.k.a. Community, Mitglieder
    Diese Gruppe könnte nicht nur ein Behälter für Mitgliedsinitiativen sein, sondern auch ein Ort an welchem partizipativ die Anforderungen an das Communication package formuliert werden.
  • Verein
    a.k.a. Network, Organisation
    Der Begriff Netzwerk ist tatsächlich etwas irreführend, da “das Netzwerk”, wie der Verein Solidarische Landwirtschaft e.V. gemeinhin genannt wird, in seiner operationalen Form eher einem Rätesystem als einem Netzwerk ähnelt.
  • Infrastruktur
    a.k.a. Technik, Werkzeuge (technische Dokumentation)
    Ich glaube, dass sich alle Infrastrukturthemen (Discourse, Nextcloud, Wordpress, TYPO3, Authentication) zunächst in einem Board bündeln lassen. Die meisten der erwähnten Systeme haben keine tiefreifendere Unterstützung für git, weshalb die Aufteilung der Projekte wenig zusätzlichen Nutzen mit sich führt. Eher geht die Übersicht verloren.
  • Kommunikation + Dokumentation
    a.k.a. Umbenennung Web Crew (Endnutzerdokumentation)
    Eine Arbeitsgruppe des Solidarische Landwirtschaft e.V. welche sich mit den langfristigen Fragen der digitalen Transformation, den mittelfristigen Fragen strategischer Planungen und Kooperationen, sowie den kurzfristigen Fragen der alltäglichen Pflege der Infrastrukturen beschäftigt.

Umbenennung Web Crew
#3

@yala danke, dass du dir Gedanken zur GitLab-Struktur gemacht hast!

Ja. Es gibt zwar noch diese Taiga-Instanz, deren offene Issues ich jedoch ins GitLab umgezogen hätte, damit wir alles an einem Platz haben.

Ok, lass es uns via Label probieren. Wenn das auf Dauer zu umständlich ist können wir zur Not später immer noch separate Repos für einzelne Projekte erstellen.

Hinsichtlich des Namens: “Initiativen” sind im täglichen Sprachgebrauch lediglich “Solidarische Landwirtschaften in Gründung”, daher sollten wir das erweitern zu “Solawis & Initiativen”.
Hinsichtlich des Inhalts: Da sich die Software-Anforderungen von Rat & Co. und den Solawis/Initiativen in vielen Punkten überschneiden (die meisten Solawis wie auch die Arbeitsgruppen im Netzwerk brauchen bspw. Online-Kommunikation wie auch Online-Kollaboration etc.) sollte das Software-Paket nicht nur bei den Mitgliedern zu finden sein. Dieses könnte dann entsprechend ebenfalls ins Repo “Infrastruktur”/“Softwares” o.ä. wandern.
Entsprechend würden dann nur Solawi- bzw. Initiativen-spezifische Issues in im Repo “Solawis & Initiativen” gesammelt.

“Verein” als Name finde ich erst mal gut – in diese Richtung gingen in letzter Zeit auch meine Überlegungen, um eine Unterscheidung zw. Netzwerk – welches meiner Auffassung nach die AGs + Rat etc. aber u.a. auch Kooperationspartner und Solawis umfasst – von den AGs, Entscheidungsgremien und der Geschäftsführung zu unterscheiden.
Das Vereins-Repo würde also spezifische Issues von Rat, Geschäftsführung etc. sammeln. Ggf. kann dieses irgendwann mit dem “Solawis & Initiativen” zusammengeführt werden.

“Infrastruktur” klingt für mich nach einem alles und nichts-Begriff. Wie wär’s etwas genauer mit “Softwares”? Ansonsten können wir das mit der Bündelung gerne probieren.

Kannst du ein Beispiel geben, welche Issues und Dokumentationen du hier siehst? Unter einer Endnutzerdokumentation verstehe ich eher eine Dokumentation für … naja die Endnutzer halt :slight_smile: also eher Tutorials und weniger AG-spezifische Themen.

Die Frage ist nun noch, was wir mit in sich geschlossenen Projekten wie z.B. nun dem Kommunikationspaket machen, welche sich inhaltlich mit bestehenden Repos überschneiden. Im Falle des Kommunikationspakets: ich sehe dieses tatsächlich als Teil des Software-Pakets daher können wir das von mir aus ins Repo “Infrastruktur” bzw. “Softwares” packen. Was meinste?


#4

@yala noch kurz eine weitere Frage zur Absicherung: das Gitlab wird von dir administrativ betreut inkl. Backups, richtig?

@kristina.gruber in der letzten TK meintest du, du wolltest noch etwas zum Gitlab-Thema anmerken. Kannst du das noch machen, damit wir die Struktur dann umbauen können?


#6

Ich finde die Struktur so nachvollziehbar und bin gespannt, wie sie sich in der Praxis erweist. Teilweise sehe ich v.a. die Inhalte von Infrastruktur jeweils als Teil von Initiativen und Verein und finde hier eine Abgrenzung auch gut. Ich schlage vor, so zu starten und nach einiger Praxiszeit zu evaluieren und ggf. anzupassen (insofern dies dann noch möglich ist)


#7

Hallo Michael, das GitLab wird von Ecobytes im Rahmen der komputationalen Allmende allmende.io in eigener Infrastruktur betrieben und ist die Kernarbeitsumgebung. Sie ist damit in die üblichen Update- und Backupzyklen einbezogen, welche auch den Rest von Allmende und Ecobytes betreffen. Die hat den Vorteil, dass wir den Gesamtadministrationsaufwand von den Schultern einzelner Personen auf eine breitere, gemeinschaftliche Basis stellen. In letzter Zeit war es aber öfter mir überlassen die Instanz zu pflegen, ja.


#8

Hier fehlt das möchten. Wie du im letzten Satz selbst zugibst, geht das Konzept der komputationalen Allmende (was ist das eigentlich? Wo ist das definiert?) nur unzureichend auf, und vor allem die Update Zyklen können nicht in allen Bereichen der Infrastruktur in einer akzeptablen Frequenz gehalten werden. Das liegt natürlich in erster Linie daran das wir es nicht schaffen genug Freiwillige einzubinden, bzw. genügend Mittel für bezahlte Arbeit einzuwerben.
Natürlich sind gruppenbasierte Prozesse tendenziell sicherer als von Einzelpersonen gestartete. So kann ich ein kontrolliertes Backup der gitlab Instanz leider nicht bestätigen, siehe: https://lab.allmende.io/ecobytes/infrastructure/issues/138


#9

Lieber @yova,

vielen Dank für die belehrenden Worte. Mir war nicht entgangen, dass die Service Level Objectives (SLOs) von allmende.io wenig klar ausformuliert sind und der gemeinschaftliche Prozess darum im Entstehen begriffen ist.

Wie du auf allmende.io lesen kannst, werden diese Dienste ohne Gewährleistung angeboten:

provides web services for mutual self-organization

it is provided “as is”, without warranty of any kind.

Wir können diese ehrenamtliche Initiative gerne weiter beleben und ausformulieren. Dann können wir euch zudem gerne als Nutzerinnen dazu befragen, welche Anforderungen ihr mitbrächtet. A priori von den Anforderungen auszugehen, welche du stellst, erscheint mir ein Fehlschluss und eine Umkehr der Kausalitätskette.

Helft gerne mit das gemeinschaftliche Gespräch mit Leben zu erwecken, wenn euch daran liegt:

Mich hier nur öffentlich und vor allen anderen mit deinem Insiderwissen aus der Vereinsarbeit bei Ecobytes zu brüskieren empfinde ich als verwirrend.

Danke für eine baldige Klärung dieser Haltung,

Jon


#10

Lieber @yala , was empfandest du an dem Beitrag brüskierend?
Es macht keinen Sinn nur die Oberfläche der Allmende glitzern zu lassen. Wenn wir Stabilität erreichen wollen dürfen wir Transparenz nicht scheuen. Die Organisation der grundlegenden Infrastruktur von ecobytes ist weitestgehend öffentlich, was eine super Voraussetzung für Transparenz ist. Wieso scheust du dich über Schwierigkeiten bei der Umsetzung der digitalen Allmende offen zu sprechen?


#11

Hallo @yova,

was mich stets trifft, ist wenn im Vorhinein von Gegebenheiten ausgegangen wird, an denen meine Haltung oder mein Verhalten gemessen wird, ohne zuvor in geeigneter Umgebung darüber gesprochen und die Möglichkeit erhalten zu haben, Einigkeit zu erzielen. Bis dies nicht geschieht, treibst du mich auf unangenehme Weise vor dir her. Vielleicht gelingt es dir ja einmal nachzuvollziehen, was @tantebootsy und mich bisweilen auf die Palme bringt.

Zwecks Backups wurde ich informiert, dass die Rootsysteme von Ecobytes für 30 Tage wöchentlich komplett und täglich inkrementell gesichert werden. Über die Updates weiß ich, dass sie wie bei anderen Diensten ab und zu wenn es sich anbietet auftreten. Auf diese Aussagen baue ich.

Für mich gibt es in diesem Ganzen kein zugeben irgendwelcher Tatsachen oder leider fehlende Bestätigung für etwaige Ansprüche, noch glitzernde Oberflächen oder Scheu vor der Ansprache schwieriger Themen. Ich sage nur, dass dies hier nicht der geeignete Ort und Rahmen ist, um dieses Gespräch zu führen.

Ich bin nur generell abgeneigt die persönliche Fremdzuschreibung (Scheu … über Schwierigkeiten … zu sprechen) annehmen zu müssen, bevor deine Frage beantwortet werden kann, wenn es tatsächlich um ein sachliches Gespräch über die Allmende gehen soll. Eigentlich müsste ich auf deine Frage mit “Mu” antworten: “Diese Frage basiert auf falschen Voraussetzungen und kann so nicht beantwortet werden.”

Was erlaubt es dir im Umkehrschluss mein Verhalten als scheu zu bewerten, dies hier in aller Öffentlichkeit vor einer ganz anderen Gruppe vorzutragen und letztlich davon auszugehen, dass ich mich nicht persönlich brüskiert fühlte?


#12

Lieber @yala,
wir diskutieren hier die Verantwortlichkeiten in der Allmende, oder? Struktur + Verwendung GitLab

Wenn das hier nun eine ganz andere Gruppe sei wie du schreibst:

Weshalb sollte sie dann die Allmende nutzen? Die Gruppe kann doch nur auf der Allmende entstehen, durch das intensive diskutieren von Verantwortlichkeiten. Das Zurückschrecken vor der Diskussion der Allmende Interna in der Öffentlichkeit ist es was ich als “scheuen” bezeichne und einem Öffnen der Allmende entgegen wirkt.


#13

Anyway, ich halte die Allmende ja auch für ein starkes Konzept und da ich das gitlab auch ausgiebig nutze habe ich mich mal den DB dumps angenommen: https://lab.allmende.io/ecobytes/infrastructure/issues/138#note_10824