Git-Repos bei codeberg als Teil der Bits&Bäume-Infrastruktur?

Vorbemerkung:

Dieser Beitrag ist ein Diskussionsvorschlag für eine :warning:Tooldiskussion​:warning:. Erfahrungsgemäß können solche Diskussionen aus dem Ruder laufen. Ich habe mich bemüht, möglichst objektiv zu formulieren und Vor- und Nachteile deutlich zu machen. Ich freue mich auf konstruktive Beiträge :grinning:.

Ausgangspunkt:

Als Teil der Aktivität von Bits&Bäume-Gruppen und Individuen entstehen Dateien (Bilder, Präsentationen, Texte usw.). Aktuell liegen diese Dateien verstreut auf diversen Plattformen bzw. privaten Rechnern. Das erschwert das Finden, Nutzen, Wertschätzen und Weiterentwickeln von Material.

Nextcloud als Lösung?

Das Aufsetzen und Betreiben einer B&B-spezifischen Nextcloud-Instanz ist in Vorbereitung.

Vorteile von Nextcloud:

  • Benutzerfreundlichkeit (Webclient, Desktopclient)
  • Vielzahl an Plugins verfügbar (Kalender, Kanban, …)
  • Login mit Forumszugangsdaten denkbar (?)

Nachteile von (eigener) Nextcloud:

  • Keine Versionskontrolle (wer darf was ändern/löschen?)
  • Kein Issue-Tracker
  • Langfristige Verfügbarkeit?

Git-Repos als Lösung?

Was ist ein Git-Repo?

In der Softwareentwicklung werden seit Jahrzehnten sogenannte Repositorien (Repos) eingesetzt um in Gruppen an sich kontinuierlich verändernden Projekten mit vielen Dateien zu arbeiten. Das Programm git ist zur Verwaltung solcher Repos sehr weit verbreitet. Damit lassen sich Änderungen nachvollziehen (Wer, Wann, Warum) sowie parallele Entwicklungszweige erstellen und ggf. wieder vereinen („mergen“). Git selber ist ein Kommandozeilenprogramm, aber es gibt leistungsstarke Webfrontends z.B. das gemeinnützige Projekt codeberg.

Konkreter Vorschlag

Menschen aus der B&B-Bewegung nutzen codeberg gehostete Repos um B&B-relevante Dateien öffentlich zugänglich zu machen.

Vorteile:

  • Versionskontrolle → einfaches Teilen und Weiterentwickeln von Material
  • Kollaborationswerkzeuge (Issues und Pullrequests)
  • Nutzung bestehender und erprobter Infrastruktur
  • Sichtbarkeit (Codeberg hat immerhin über 10K Nutzer:innen und wächst aktuell monatlich mit 10%)

mögliche Nachteile (+ Relativierungen):

  • Infrastruktur nicht von uns kontrolliert
    • Codeberg ist gemeinnütziger eingetragener Verein aus Berlin
    • Verfügbarkeit unserer eigenen Infastruktur (Mastodon, discourse) war bisher nicht 100% überzeugend
    • Falls Probleme auftreten: Git-Repos lassen sich relativ leicht migrieren
  • Ggf. zu komplexer Workfolow, abschreckend für Nicht-Techis
    • Nutzen/Runterladen von Material ist sehr einfach
    • Hochladen und Ändern geht auch über Webfrontend
    • Möglichkeit von Support sollte gegeben sein
  • Nutzerinnen brauchen Account bei weiterer Plattform (für Schreibzugriff)

Zusammenhang zur (in Vorbereitung befindlichen) B&B-Nextcloud

Beide Infrastrukturen schließen sich nicht aus. NC ist vor allem für größere Binärdateien (Bildersammlungen, Videos, externe PDFs) sinnvoll. Repos sind sinnvoll für innerhalb der B&B-Bewegung entwickeltes Material (Grafiken, Vorträge, Flyer, Sticker)

Aktueller Stand

Es gibt bereits seit Sommer 2020 eine ‚Organisation‘ namens „Bits und Bäume“ auf codeberg. Bisher wurde sie hauptsächlich vom Regionalzweig Dresden benutzt. Eine Nutzung durch die überregionale AG Wissensdatenbank ist im Anfangsstadium.

Verfahrensvorlschlag

Wir sammeln ein paar Wochen Meinungen zu dem Thema. Für den Fall, dass es genügend Zustimmung und keine harten Vetos gibt, sollte eine kurzer „offizieller“ Text erstellt werden, der dazu einlädt, B&B-relevante Dateien in bestehenden oder neuen Repositorien zu teilen. Dieser Text sollte gleichzeitig deutlich machen wo und wann man Unterstützung dabei bekommen kann. Z.B. als Workshop.

1 Like

Ergänzend der Hinweis, dass die Berliner aus der B&B Community die Git-Repo Lösung hier bisher verwendet haben: https://gitlab.com/bub-berlin - auch für binäre Dateien, insb. weil es bisher keine andere Lösung gibt.

Herzlichen Dank für deine Initiative für diese Diskussion @CarK und die tolle Diskussionsgrundlage!

2 Like

Git ist eine Barriere.
Wer git nutzen will soll das meinetwegen tun, aber Kollaboration ist ohne Einarbeitung unmöglich. Solch eine Hürde zur Mitarbeit sollten wir uns nicht leisten.

(Dieser Beitrag hatte ich schon wesentlich länger getippt – ich halte git als Standardwerkzeug in unserer gemeinsamen Arbeit für einen großen Fehler – aber alle Argumente lassen sich auf das Obige eindampfen.)