[RFC] Warum wir zwei (oder drei) Discourse nutzen sollten ūüėČ


#1

@toka: Hier gehts darum, wie die machBar bzw. der Wissenschaftsladen seine Discourse-Anstrengungen öffnen könnte und sollte …

(Bearbeiten im Pad: hier)

Anspr√ľche an den Entscheidungsprozess

Es geht mir prim√§r darum, mit euch zusammen unsere gemeinsem Interessen zu ergr√ľnden und erst einmal zu verstehen, welche Bed√ľrfnisse und √Ąngste die einzelnen haben. Wenn wir daf√ľr eine gemeinsame Sprache finden, wird die Entscheidung sp√§ter relativ einfach sein. Mit dem Einrichten von Discourse-Instanzen m√∂chte ich auch keine vollendeten Tatsachen schaffen, sondern erst einmal ‚ÄúSpielwiesen‚ÄĚ er√∂ffnen, auf denen das gemeinsam gedachte ausprobiert werden kann. Erst nach einiger Zeit der Erkundung k√∂nnte dann eine Plenums-Entscheidung getroffen werden, was wir als gemeinsame Strategie umsetzen sollen.

Wozu √ľberhaupt ein offenes Discourse ?

  • Das Freiland-Discourse ist mut gutem Grund geschlossen. Daran l√§sst sich nichts √§ndern. Wir k√∂nnen dort keinen √∂ffentlichen Bereich einrichten.
  • Aufbau einer Nutzungsgemeinschaft
    • Nutzer sollen sich selbst registrieren k√∂nnen
  • Nutzer sollen ihren Bereich weitgehend selbsst√§ndig strukturieren k√∂nnen
    • => Die H√ľrde um Moderator zu werden , soll gering sein
  • Sichtbarkeit von Unfertigem erm√∂glichen
  • Zur√ľckgeben an die OpenSource-Gemeinschaft
    • Nutzen, Probleme und L√∂sungen dokumentieren unterst√ľtzt die Projekte, die wir nutzen
  • Zur√ľckgeben an die RepairCafe-Bewegung
  • Nutzergruppen der machBar sollen einen einfachen Ort der Selbstorganisation gestalten k√∂nnen
  • Jugendgruppe #tec
  • kitchen
  • repairCafe
    • Nutzer sollten Selbsthilfe auch ohne uns untereinander vermitteln k√∂nnen. ‚ÄúReparieren‚ÄĚ kann dann auch an anderen Orten gemeinsam unternommen werden. Die monatlichen repairCafes w√§ren dann Orte, an denen so etwas initiiert wird. Die Nutzer k√∂nnten langfristig durch Einbindung in den √∂ffentlichen Bereich eine stadtweite ‚ÄúRepairgemeinschaft‚ÄĚ bilden.
  • chaostreff
    • hat das schonmal besprochen, aber keine Lust, eine eigene Instanz zu warten.
  • Netzwerk Brandenburger Maker
    (@toka: f√ľr diesen Verband w√§re es sinnvoll, ein eigenes Discourse zu nutzen)

All diese Gruppen sollten nach M√∂glichkeit Moderationsrechte bekommen. Innerhalb unseres machBar-Kontextes kennen sich die meisten √ľber wenige Ecken. Wir k√∂nnen da eher davon ausgehen, dass eine Einigung rasch m√∂glich ist, als in einer Gruppe, die sich erst kennenlernen muss (Brandenburger Maker).

Flaschenhals vermeiden.

Jeder, der sich das zutraut, sollte Admin sein können.
Dazu muss ein Backupsystem zuverl√§ssig laufen. Dann k√∂nnen Fehler wieder r√ľckg√§ngig gemacht werden.
Wenn nur zwischen den Nutzern öffentliche Inhalte im offenen Discourse verhandelt werden, dann gibt es keinen Grund, mit der Anzahl von Administratoren und Moderatoren zu geizen.

Discourse implementiert nur ein sehr flaches Rechtesystem, ist f√ľr hierarchische Strukturen nicht geeinget

Es gibt in Discourse nur zwei Rollen, mit denen sich weitgehende Moderationsaufgaben erledigen lassen: Admins und Moderatoren. Beide Rollen können nur global vergeben werden, d.h. es gibt keine Möglichkeit, die Bearbeitbarkeit von Themen auf einzelne Kategorien einzugrenzen.

Auch das Nutzerverzeichnis und die Tags sind global.
Bei intensiver Nutzung von Discourse w√ľrdet ihr bei Erw√§hnungen mit ‚Äú@‚ÄĚ eine Menge Nutzer sehen, die ihr √ľberhaupt nicht kennt und auch nicht im Kontext der Machbar kennenlernen werdet.
Genau so verhält es sich mit Kategorien und Unterkategorien. Jetzt sehen wir ja schon beim Einrichten von Themen eine Menge von Kategorien, die uns im Kontext der Machbar nicht direkt interessieren.

Geheimhaltung

Wenn wir sensible Daten (Finanzierungen, Absprachen, die nicht öffentlich sein sollen, Knatsch etc) besprechen wollen, dann sind wir auf das wohlwollende nicht-mitlesen aller Admins angewiesen.
F√ľr das Brandenburger Maker-Netzwerk w√ľrde ich egalit√§re Strukturen vorschlagen. Dies hie√üe f√ľr mich: aus jedem Projekt ist jemand Administrator f√ľr discourse.
Damit sind aber alle Daten f√ľr alle Admins √∂ffentlich.
Schutz gegen Fehler ist dann √ľber f√ľr alle zug√§ngliche Backups m√∂glich.

ūüėč ūüėč ūüėč

Die ‚ÄúEinrichtung‚ÄĚ eines Discourse ist prim√§r Communitybuilding, keine technische Angelegenheit

Viel Pflege und Absprachen sind n√∂tig, um ein Discourse zum Laufen zu bringen. Diese Absprachen sind ja unter uns schon nicht einfach. In einem Netzwerk, dass sich gerade bildet, ist da noch mehr Vorsicht angebracht. Die Prozesse sollten langsam gehen. Wenn wir zusammen mit dem Netzwerk eine Seite aufbauen, dann wird dieser Prozess durch unsere (hoffentlich intensive Nutzung) des Discourse quasi zugesch√ľttet.
Es ist meiner Ansicht nach sinnvoller, jeden Bereich eigene Nutzungskulturen entwickeln zu lassen.

Das Argument ‚ÄúEs ist ja jetzt schon mit einem Discourse kompliziert genug. Mit mehreren wird es noch komplizierter!‚ÄĚ

Durch Nutzung mehrerer Discourse wird es imho einfacher, denn die einzelnen Orte werden √ľbersichtlicher werden.
Stellt euch mal vor, es gibt nur ein Discourse, und das wird intensiv von >10 Brandenburger Makergruppen genutzt.
Da ja alle dann √∂ffentliche Kategorien haben werden, werdet ihr bei jedem Lesen und bei jedem Schreiben einen Haufen Kategorien angezeigt bekommen, die euch im Rahmen der Machbar nicht direkt interessieren. Das gleiche gilt f√ľr Nutzer. Wenn es mehrere Discourse gibt, dann werden im jeweiligen Kontext nur die dort relevanten Infos angezeigt.

Entwicklungsmodell: Kleine reversible Schritte implementieren

‚ÄúNever touch a running system‚ÄĚ. Und wenn, dann nur ein wenig, und so, dass m√∂glichst alle Schritte zur√ľckgenommen werden k√∂nnen.
Ich vermute beim Freiland einen Bedarf, mitzubekommen, was bei uns abläuft. So weit ich verstanden habe, sind wir als quasi öffentliche Einrichtung des Freiland vom Freiland subventioniert. (Sehe ich das richtig ?)
Deshalb sollten Strukturen nur langsam verändert werden.
Die Einrichtung eines √∂ffentlichen Discourse w√ľrde ein parallelangebot schaffen, das eingegrenzt ausdr√ľcklich nur f√ľr den √∂ffentlich zu behandelten Teil unserer Konversationen genutz wird. Langsam k√∂nnen dann alle ‚Äúnerdigen Themen‚ÄĚ, bei denen die √Ėffentlichkeit teilhaben soll in konsumierender(=lesen) und unterst√ľtzender Weise sich einbringen.

Wir haben ja ein Wiki f√ľr den √∂ffentlichen Bereich!

Wie geschrieben, sehe ich die Hauptaufgabe des Discourse, eine Gemeinschaft von Nutzern aufzubauen. Dazu ist ein Wiki nicht so gut geeignet. Andersherum liefert (solange wir nicht ein semantisches Wiki nutzen) Discourse grunds√§tzlich alle M√∂glichkeiten, die das Wiki liefert (ok, Strukturierungsm√∂glichkeiten gibt es im Wiki mehr), nutzt daf√ľr aber eine viel einfachere Oberfl√§che. Gleichzeitig ist discourse ein gutes Cross-Over zwischen

Das machBar-Wiki wird kaum benutzt.
Es gibt keinen Link zum Wiki, weder auf der Machbar-Seite noch auf der Seite des Wissenschaftsladens.

Diskussion

Falls Inhalte vom Wiki in das Discourse umziehen sollten, sollte im Wiki immer eine Referenz zur neuen Seite eingebaut werden.

Komentare:

@nicco:


#2

Hey @toka,
Mich w√ľrde interessieren wie du das ‚ÄėWiki‚Äô hier im discourse f√ľhren w√ľrdest. Also auch zwecks √úbersichtlichkeit. Das kann ich mir mit Tags nicht ganz so gut vorstellen. K√∂nntest du da Mal ein Beispiel zeigen. Aus‚Äôm Netzt oder nen kleinen Prototypen hier im discourse?
LG


#3

Hey @toka,
der Erfindergarten hat sein forum auch mit einem Wiki verbunden. Schaue Mal,…
Ich meine, vielleicht reicht das doch.
Du hast schon recht, es ist recht leichtgewichtig!
Vielleicht können wir das nochmal diskutieren,… oder besser ausprobieren,…


Lege doch Mal eine WIKI Kategorie an,‚Ķ bitte auch mit passendem Bild oder Logo,‚Ķ Das halte ich noch f√ľr eine Schw√§che beim Erfindergarten Forum‚Ķ (p.s.:Kannst du auch das .kitchen Logo noch hochladen)
LG
Björn


#4

hm, ich verstehe noch nicht.

Reicht es nicht, einzelne Beiträge als Wiki-Post zu erstellen und denen dann Tags zuzuweisen ?

Lass uns das mal konkret ausprobieren.
Was möchtest Du denn dokumentieren ?