Aufbau des Forums

1 „Gefällt mir“

Die Bilder verweisen noch auf discourse-mksp.4830.org
Das rake posts:rebake_match["www.old-name.com"] hat nicht funktioniert :frowning:

Habe einen Fehler gefunden:
root@discourse-mksp-app:/var/www/discourse# nginx -s reload
nginx: [emerg] no "ssl_certificate" is defined for the "listen ... ssl" directive in /etc/nginx/conf.d/discourse.conf:33

1 „Gefällt mir“

Ich verstehe es nicht. In der /root/.acme.sh/forum.makerspace-gt.de/forum.makerspace-gt.de.conf steht folgendes:

Le_Domain='forum.makerspace-gt.de'
Le_Alt='discourse-mksp.4830.org'
Le_Webroot='.'
Le_PreHook=''
Le_PostHook=''
Le_RenewHook=''
Le_API='https://acme-v01.api.letsencrypt.org/directory'
Le_Keylength=''
forum.makerspace-gt.de.conf (END)
1 „Gefällt mir“

und?

1 „Gefällt mir“

Ich lasse es nun so wie es ist :man_shrugging:

2 „Gefällt mir“

Vielleicht mal einen Samstag ausgucken, um das anzugehen. Auch alte Links laufen a) in einen Zertifikatsfehler und b) nach abnicken desselben in eine leere Seite. (Bei Deiner Wunschliste habe ich die URL editiert, nun tut’s; dürfte ja aber noch mehr geben, nachdem aus dem „Test-Forum“ das „Live-Forum“ wurde ;))

1 „Gefällt mir“

Also an sich ist Discourse per Web-UI updatebar: Hamburger-Menü -> Administration (Rechte vorausgesetzt), da wird dann ggf. ein Update angeboten. Und meistens läuft das auch durch — und der Prozeß erzeugt bei altgedienten Serverschaben massig Gänsehaut :wink:

Notfalls:

root@discourse-vm:~# cd /var/discourse/
root@discourse-vm:/var/discourse# ./launcher rebuild app

Toi, toi, toi, für ein Docker-Konstrukt ist Discourse angenehm pflegeleicht :wink:

2 „Gefällt mir“

Ein kritisches Update ist verfügbar. Bitte Upgrade durchführen!

Ich mag das Update ungerne über die Adminseite anschubsen. Wenn es nicht durchlaufen sollte müsste sonst jemand anders drauf schauen. Also kann bitte jemand mit Zugriff auf den Server das Update anschubsen?

Wir brauchen 2 GB mehr Festplattenspeicher, sonst meckert der Updater

Vorgehen für ein update:
ssh forum.makerspace-gt.de
cd /var/discourse
./launcher rebuild app
./launcher enter app
nano /etc/ssl/openssl.cnf
# remove the CipherString = DEFAULT@SECLEVEL=2 at the end of the file
exit
./launcher restart app

:woozy_face: Das meinte ich

@CommanderRiker drehst du den Festplattenspeicher um 5 GB hoch?

Es ist wieder ein Update verfügbar.
Ein kritisches Update ist verfügbar. Bitte Upgrade durchführen!

1 „Gefällt mir“

Erledigt

1 „Gefällt mir“

Schon wieder ein Update.
Diesen Monat soll noch die Version 2.5.0 veröffentlicht werden.

Ich werde die Gelegenheit nutzen und uns von dem Beta Kanal runter nehmen.

1 „Gefällt mir“

Ich würde gerne die Kategorie Werkstätten und Ausrüstung umbenennen, da

  • dort nun auch der Minecraft Server drunter fällt
  • der Name recht lang ist.

Was wäre eine passende Benennung? Einfach „Bereich“ oder doch „Orbit“? :smiley:

Weiterhin möchte ich einen Bereich für „Methoden“ einführen. Ich will demnächst Pair Programming ausprobieren und vermute, dass die Methode gut passt um zusammen zu arbeiten. In dem Bereich können wir dann Best Practices sammeln.

Passt „Werkstätten und Ausstattung“ statt Ausrüstung besser? Für mich geht Eindeutigkeit/Verständlichkeit vor Kürze der Worte, und den aktuellen Titel finde ich schon sehr unmissverständlich.
Oder noch ein Vorschlag: „Arbeitsbereiche“ oder „Arbeitsbereiche und Ausstattung“

Was hat es mit dem Pair Programming auf sich? Das klingt super interessant!

Wie wäre es dann mit „Möglichkeiten“?

Es gibt beim Pair Programming zwei Personen die zeitgleich an einer Datei arbeiten. Eine Person navigiert und beschreibt grob was getan werden soll, die andere Person führt diese Anweisung aus und hinterfragt dabei die Anweisungen. Die beiden Personen wechseln sich dabei ständig ab.

Vor und Nachteile aus dem Wikipedia Artikel

Positive Effekte

  • Weniger Fehler
    Paarprogrammierung führt zu weniger Fehlern und somit zu weniger Fehlerbehebungsaufwänden. Üblicherweise rechnet man bei Paarprogrammierung mit 15 % weniger Fehlern als bei herkömmlicher Programmierung.[2]
  • Kleinere Programme
    Paarprogrammierung führt im Schnitt zu um 20 % kleineren Programmen.[2]
  • Höhere Disziplin
    Paare entwickeln viel eher an der richtigen Stelle und machen kürzere Pausen.
  • Besserer Code
    Bei der Paarprogrammierung entwickelt man sich weniger leicht in Sackgassen und erreicht so eine höhere Qualität.
  • Belastbarerer Flow
    Paarprogrammierung führt zwar zu einer anderen Art von Flow, ermöglicht diesen aber eher als der konventionelle Ansatz: Ein Programmierer kann seinen Partner jederzeit nach dem aktuellen Stand fragen und dort anknüpfen. Unterbrechungen werden auf diese Art besser abgewehrt.
  • Freude an der Arbeit
    Paarprogrammierung ist oft spannender und interessanter, als allein zu arbeiten. 90 % der Entwickler, die Paarprogrammierung betreiben, sprechen von einer erfreulicheren Arbeit.[2]
  • Geringeres Risiko
    Wenn das gesamte Projektteam mit der Methode Paarprogrammierung arbeitet und die jeweiligen Partner oft wechseln, erlangen alle Wissen über die gesamte Codebasis. Dies wiederum führt zu einem geringeren Projektrisiko hinsichtlich Mitarbeiterfluktuation und Mitarbeiterabwesenheiten, welche zu den größten Projektrisiken zählen[3]. Es erhöht somit die Truck Number.
  • Wissensvermittlung
    Jeder hat Wissen, das andere nicht haben. Paarprogrammierung ist eine Möglichkeit, dieses Wissen zu verteilen oder auch zu transferieren.[4]
  • Teambildung
    Die Leute lernen sich gegenseitig schneller kennen, wodurch die Zusammenarbeit verbessert werden kann.
  • Weniger Unterbrechungen
    Paare werden seltener unterbrochen als jemand, der allein arbeitet.

Nachteile

  • Teamfindung
    Teamfindung kann aufwendig sein, wenn nicht alle Personen miteinander produktiv arbeiten können. Eingewöhnung der Teammitglieder kann Zeit erfordern.
  • Urheberrecht
    Es kann wie bei allen nicht von Einzelpersonen entwickelten Werken das Urheberrecht nicht für einzelne Personen angewandt werden.
  • Haftung
    Es kann wie bei allen nicht von Einzelpersonen entwickelten Werken zu Konflikten kommen, da später nicht unbedingt klar ist, wer für fehlerhaften oder urheberrechtsverletzenden Code haftet.

Das ist ein super Konzept und könnte auf jeden Fall einen eigenen Bereich gebrauchen! Finde ich sehr spannend

Ein Beitrag wurde in ein existierendes Thema verschoben: E-Mail Probleme

Ich strukturiere nachher noch das Forum um.

Bisher haben wir folgende Kategorien:

  • Infrastruktur
    • Förderanträge
    • Nextcloud
    • SWI
    • Forum
    • git
    • Website
    • Ordnungssysteme
    • Zugangskontrolle
  • Off Topic
  • Intern
  • Veranstaltungen
    • Workshops
    • Exkurionen
    • Termine
    • Repair Café
  • Sonstiges
  • Projekte
    • Privatprojekte
    • Vereinsprojekte
    • Projekte von Dritten
  • Werkstätten und Ausrüstung
    • Laser
    • Textil
    • CNC-Fräsen
    • Computer
    • 3D-Druck
    • Holz und Kuststoff
    • Wunschliste
    • Elektronik
    • Minecraft
  • Netzwerk
    • Externe Links
  • Makerspace Gütersloh e.V.
    • Öffentlichkeit
    • Mitglieder
    • Cooperative Identity
  • Vorstand

Das finde ich teilweise etwas unübersichtlich, bzw. werden die auch gar nicht komplett genutzt und es sind nur vereinzelt Beträge vorhanden.

Die neue Struktur sieht so aus:

  • Infrastruktur
    • Förderanträge
    • IT
    • Räume
  • Sonstiges
  • Intern
  • Termine
    • Workshops
    • Exkurionen
    • Repair Café
    • Sonstiges
  • Projekte
  • Möglichkeiten
    • Laser
    • Textil
    • CNC-Fräse
    • Computer
    • 3D-Druck
    • Holz
    • Mechanik
    • Wunschliste
    • Elektronik
    • Minecraft
  • Verein
    • Öffentlichkeit
    • Cooperative Identity
    • Netzwerk
    • mitmachen
  • Vorstand
  • Wiki

  • Infrastruktur bekommt weniger Unterkategorien. Alle IT Dienste werden zusammengefasst, damit nicht für jeden neuen Dienst eine neue angelegt werden muss oder inkonsequent gehandelt wird. Ordnugssysteme und Zugangskontrolle werden in Räume zusammengefasst. Damit sind alle physischen Räume gemeint.
  • Off Topic wird mit Sonstiges zusammengelegt, da es keine klare Unterscheidung gibt
  • Intern bleibt bestehen
  • Veranstaltungen wird zu Termine, da kürzer im E-Mail Betreff. Unterkategorie Termine wird zu Sonstiges
  • Unterkategorien bei Projekte werden aufgelöst
  • Werkstätten und Ausrüstung wird zu Möglichkeiten, Holz und Kuststoff wird zu Holz, Mechanik kommt neu hinzu und ist für allgemeine Werkzeuge wie den Werkzeugkoffer, die Standborhmaschine und ggf. die neun anzuschaffende „Flex“ @Echo :wink: ?
  • **Makerspace Gütersloh e.V. ** wird zu Verein, Netzwerkt wird eine Unterkategorie davon, Mitglieder entfällt, dafür kommt mitmachen hinzu, das soll einfach nur eine Information sein wie wir zu erreichen sind. z.B. die Absprache der Basteltreffen, die Coronaregeln, Link zu Telegramgruppe, etc.
  • Vorstand bleibt bestehen
  • Wiki kommt hinzu Der Name gefällt mir noch nicht ganz, aber etwas besseres ist mir nicht eingefallen. Hier können best practices und Methodenwissen dokumentiert werden.
1 „Gefällt mir“