Überlegungen zur Wiki-Zukunft

Wird denn das Wiki effektiv für was anderes benutzt, als Programm und Protokolle? Die Wiki-Profilseiten sind manchmal sehr nützlich, weil da mehr Informationen über Leute drinstehen, als woanders. Aber ich vermute, dass das Konzept an sich zu oldschool ist und kaum mehr benutzt wird.

Kann man das gesamte alte Wiki nicht auf einen anderen Server übertragen und dort als Read-Only weiterlaufen lassen? Das wär doch sicher der geringste Aufwand, alle Inhalte bleiben dauerhaft verfügbar und können trotzdem nicht mehr geändert werden.

Wegen Archivierung würde ich mir da nicht erst groß Konzepte ausdenken wollen. Keep it small and simple.

Was die “Zukunftslösung” angeht, bitte unbedingt dran denken, dass nicht alle in der Partei IT-Spezialisten sind. Ich komm mit der Media Wiki Syntax ganz gut klar, aber selbst da dürfte es bei einigen schon scheitern. Wenn ihr hier jetzt also von Git und so Zeug sprecht, gehe ich davon aus, dass der Anteil der Ausgegrenzten sich signifikant erhöht.

Was escap sagt ist erstmal richtig. Offizielle Dokumente sollten nicht in einem Wiki liegen. Die jeweils aktuelle Version des Programms und der Anhänge usw. sollte schön aufbereitet irgendwo stehen, wo nur die AKO Zugriff hat. ABER: Wenn das so ist, dann muss auch dafür gesorgt werden, dass die Personen mit Zugriff das Zeug tagesaktuell halten. Spätestens 1 Woche nach Beschlussfassung muss der Volltext an der richtigen Stelle veröffentlicht sein. Es kann nicht angehen, dass Beschlusslage untergeht und 1 Jahr lang gar nicht eingetragen ist. Das muss absolut sichergestellt sein, denn Satzung, Programm und PP ist die Arbeitsgrundlage für alle in der Partei. Und Entscheidungsgrundlage unserer Wähler.

Von einem Wiki als Arbeitsplattform sollten wir uns aber trotzdem nicht verabschieden. Allerdings darf es nicht mehr zu so einem Wildwuchs kommen, wie er derzeit vorhanden ist. Daher sollte in klar abgegrenzten Namensräumen gearbeitet werden. Gliederungen in den Ebenen Bund - Land - BzV - KV (oder das landesüblcihe Äquivalent, AG/SG in jeweils einem eigenen Namensraum, Themenseiten wie Schatzmeisterei in eigenen Räumen und jeder angelegte Benutzer kann eigene Seiten unterhalt des Benutzerlevels erstellen.

Schreibzugriffe der einzelnen Namensräume verwalten jeweils die Bereichsverantwortlichen unter sich. Damit sollten wir die Sache etwas besser unter Kontrolle bekommen und alles bleibt thematisch halbwegs übersichtlich.

Das Antragsportal finde ich aktuell ebenfalls keine schlechte Lösung. Alternativ könnten wir auch sowas ähnliches wie die frühere Liquid Feedback Instanz aufbauen, allerdings ohne das ganze Abstimmgedöns, bzw. maximal mit Like/Dislike-Button. Damit umgeht man die endlos Debatte, ob da jetzt namentlich abgestimmt werden sollte oder nicht. Zur Entwicklung von Antragstexten war LF damals aber halbwegs brauchbar. Hier ist leider der Manko am Antragsportal, dass es zwar gut ist, Anträge zu sammeln, aber eben nicht gedacht ist, eine Rohfassung erstmal weiter zu entwickeln. Hätten wir dafür eine Lösung, wären auch die BPTs einfacher. Gutes Beispiel ist PP001 für BPT19.2. Antrag wurde im Antragsportal eingestellt, danach hat die AKO hier im Forum einen Thread eröffnet, es wurde auf Probleme hingewiesen, der Text wurde überarbeitet, der Antrag war aber auf der Plattform erstmal gesperrt (inzwischen behoben und der Text geändert). Wenn wir eine Plattform haben, in der Anträge öffentlich diskutiert aber nur vom Ersteller überarbeitet werden können, wär das echt eine feine Sache.

Auf Grund von Softwareversionen, damit zusammenhängenden Abhängigkeiten und dem Nichtvorhandensein von Update-Möglichkeiten können wir das nicht machen.

1 Like

Genau das meinte ich mit:

Das vermeidet einen großen Migrationsaufwand und Probleme mit Dingen, die mit einer neuen mediawiki-Version nicht oder anders funktionieren.

Auch ein readonly-System muss man mal updaten, wenn es im Netz hängt. Statisches HTML erzeugt außerdem weniger Last, geht nicht kaputt, lässt sich beliebig verteilen und braucht keine Datenbank.

Von Leuten, die für Programm und Satzung zuständig sind, würde ich erwarten, dass man sich auch mal in neue Dinge einarbeitet (ggf. mit Anleitung durch andere) aber man wird sicher kein git können müssen, um einen Antrag zu stellen :wink:

Das klingt nach viel Verwaltungsaufwand. In Redmine und Discourse müssen wir den Kram sowieso schon pflegen, da muss sich schon genau überlegen, ob man das alles nochmal bauen will mit leichten Variationen.

Was ist denn konkret eine Arbeitsplattform? Wenn ich mir die letzten neuen Seiten so ansehe, ist das Wiki vor allem dazu da, fertige Protokolle abzuladen. Das geht genauso in Discourse oder Redmine. Texte erarbeiten geht mit den Pads. Wie passt das Wiki dazwischen? Wäre sehr wichtig, nach Anwendungsfällen zu suchen, die noch nicht abgedeckt sind und zu schauen, ob wir die mit den anderen Tools abbilden können.

Als AKO halte ich das Ding für eine Katastrophe. Da wäre es mir lieber, die Leute würden alle Anträge per Mail schicken und ich könnte das in Redmine verwalten… Ich arbeite ja an einem eigenen Antragsportal, welches das Wiki-Antragsportal ersetzen wird.

Vor der Einreichung: Discourse, nach der Einreichung: mein Antragsportal

Mich würde mal interessieren, woran es genau scheitert. Irgendwie finde ich es oberpeinlich, wenn das Wiki seit Jahren nicht aktualisiert wird. https://wikimirror.piraten-tools.de/ läuft z.B. auch auf einer halbwegs aktuellen Mediawiki-Version.

Ich administriere das Ding nicht, aber ich weiß, dass das Updaten schonmal versucht wurde und gescheitert ist.
Davon abgesehen kannst du gerne mal die Versionsseiten vom Mirror und vom normalen Wiki ansehen und vergleichen.
Dann ist es einfacher ein Wiki komplett neu zu machen und immer nur die letzte Revision vorzuhalten etc.

Es gibt Gründe und ich kann dir sagen, dass die nicht vorgeschoben sind und wir auch am liebsten aktuelle Softwareversionen hätten

Wenn das OS so alt ist, wie die PHP-Version vermuten lässt, habe ich keine Fragen mehr.

Kann man sich die Redmine-Wiki Variante irgendwo in life anschauen? Finde das ein interessantes Konzept.

Grundsätzlich halte ich ein Redmine-Wiki für Programme, AGs, etc. ganz praktisch, dann ist alles an einem Ort. Dann das Forum um an $Dingen zu arbeiten. Ein Wiki ist dann nicht mehr nötig.

1 Like

Wenn Interesse besteht erzähle ich Donnerstag über ein alternatives Konzept mit rumprobieren in der Konzeptstudie.

Denkt mal bitte daran, dass nicht alle Leute Spaß daran haben ständig neue Tools zu lernen und viele auch genau null Bock und Zeit dazu haben.

Wir haben auch eine Menge Leute mit dabei, die nicht so besonders flüssig sind bei der Benutzung von Computern, viele davon haben wir mühsam an Wiki gewöhnt.

Man kann die Bude auch zum stehen bringen, indem man ständig umbaut.

5 Likes

War vielleicht falsch mit “Arbeits”-Plattform falsch ausgedrückt. Eine Plattform eben, auf der z. B. von AGs erstellte Dokumente, die kein Pad sind, gesammelt werden können. Oder sowas wie Plakatdesignvorschläge usw. Da ist ein Wiki vermutlich einfacher zu nutzen. Oder kann Redmine auch Bilder, Videos, Graphikmaterial etc. darstellen? Wenn eine AG für sich ein Logo entwirft, kommt das sicher nicht auf eine hochoffizielle Plattform. Sonst musst du dort wieder die Strukturen einrichten.

Es gibt immer mal wieder Zeug, dass zumindest für innerparteilichen Zugriff irgendwo öffentlich geparkt werden sollte, von Dateien über Bilder zu Hinweistexten und Linklisten. Dazu eigenet sich das Wiki mMn einfach am Besten. Nicht zuletzt wegen dem, was The_Bug geschrieben hat. Wiki-Bedienung ist inzwischen zumindest halbwegs bekannt.

Siehe Entwicklung PP001. Da ist das Forum hier mMn derzeit falsch konfiguriert. Anträge diskutieren wär die Rubrik “Antragsdiskussion” ja perfekt. Da kann man aber keine eigenen Threads erstellen, sondern die AKO stellt die bereits eingereichten Anträge ein. Und die Schlagworte können nicht vom Autor vergeben werden, sondern sind von der Grundkonfiguration vorgegeben. Also müsste über Anträge irgendwo unter “Partei” oder “Politik” debattiert werden, wo es - nicht zuletzt wegen der fehlenden Schlagworte - kein Mensch mehr wiederfindet. Ich würd ja Anträge gerne im Vorfeld zur Debatte stellen, geht aber halt nicht auf sinnvolle Weise.

Ok, dann eben als HTML, falls sich das so umsetzen lässt. Da sollte man sich aber vor der Umsetzung Gedanken dazu machen, ob man aus Datenschutzgründen alles unterhalb der Benutzer nicht besser weglässt. Da geht dann zwar einiges verloren, aber wir sollten keine persönlichen Inhalte von Ex-Piraten archivieren.

Was Redmine und Co angeht… kann man das auch in optisch hübsch machen? Also mit farbigen Boxen, schönen Menüs usw? Zumindest der Ort, an dem das hochoffizielle Zeug wie Satzung, -beiordnungen, GO, Programm, Positionspapiere usw. veröffentlicht wird, sollte auch hübsch sein, dass Außenstehende nicht gleich wieder wegklicken, sondern sich das Zeug auch mal ansehen.

Und damit ist der bestehende Inhalt nicht mehr inklusive Formatierung übernehmbar.
Viel Spaß mit Tabellen usw.

Was heißt denn das? Als Pawel und ich vor dem BPT Nürnberg anfingen über das Programm drüberzugehen, hatten wir das ja schon begonnen, ich hatte jeden einzelnen Antrag zu Satzung, Grundsatzprogramm und den Wahlprogrammen als PR eingepflegt. Daraufhin wolltest du das skriptbasiert machen.
Schade, dass wir da Doppelarbeit machen.

Habe nicht vergessen, dass du auch was gemacht hast, gab keine Doppelarbeit :slight_smile:

Ich habe mich auf die Revisionen konzentriert. Die will ich in Git abbilden. Das soll dann auch einfach auf andere Satzungen und offizielle Texte übertragbar sein.

Gibts eigentlich einen besonderen Grund, warum das Grundsatzprogramm aufgeteilt ist, aber die anderen nicht? Bin mir nicht sicher, was besser ist, ich hätte es eher im Ganzen gelassen, weil es im Wiki auch so ist.

Die klar fehlenden Anträge haben wir nach meiner Analyse nachgetragen, es gab nur einmal eine Situation, bei der nicht mehr klar gesagt werden kann, ob der Antrag im Grundsatzprogramm sein müsste oder nicht.

1 Like

Wem’s nicht gefällt, der kann dann ja ein Issue senden :grimacing:

Blockquote 90% ist Müll und/oder überholt.

Dem kann ich mich anschliessen und freue mich das wir das nun angehen.
Die Frage ob wir überhaupt ein Wiki weiter wollen oder nicht und was wir aus dem " Alle machen mit und jeder macht was er will" etwas gelernt haben wird hier kaum Platz finden, da es eher um technische Frage geht.
Statisches HTML und die Suchmaschinen draussen halten klingt gut. Ags und Landesverbände hätte ich lieber in einem Wordpress als einem Wiki.
Sieht deutlich besser aus und die Zahl der Leute die eine Wordpress Seite betreuen können ist heute schon deutlich höher als die die wissen wie die Media-wiki Syntax funktioniert.
Aus Sicht eines in einem LV arbeitenden : ich würde mich freuen wenn wir Protokolle und Abstimmungen im Wordpress haben, nicht noch neben unserer Seite die Wiki seiten pflegen und anlegen müssen. Es ist zwar toll das wir mit Mediawiki sogar so etwas wie Abstimmungen abzubilden hinbekommen, es ist aber auch wahr das wir da Dinosaurier Technik benutzen. Das mag für 2010 cool gewesen sein, die Masse der tools die nun aber da sind für genau diese Aufgaben ( Abstimmungen, to-dos usw ) sind aber für andere Plattformen geschrieben und entwickelt worden.
Je länger wir an den alten Systemen festhalten und so mehr haben alle anderen einen deutlichen technischen Vorteil bei den Tools. Ich warte auf den Tag wo selbst die CDU IT uns zu recht belächelt.
Ein Wiki ist für Anwendungen jenseits von AG s und Vorständen möglicherweise noch immer super - bei allem was Bewegung und " mach mit " Charakter hat.
Also danke an escup für die Frage " brauchen wir das Wiki noch " und gerne dazu mal eine Diskussion auch innerhalb der LVs und KVs .

Da hast du wohl recht…

Im Bundesredmine sind die Wikis nur für bestimmte User sichtbar, auch bei öffentlichen Projekten, daher kann ich dort nichts zeigen.

Demo-Redmine, in dem jeder rumspielen kann gibts hier:

Für viele Fälle sind Tickets sinnvoller. Die unterstützen genauso eine Formatierung wie Wiki-Einträge und zeigen die Änderungen an. Protokolle haben wir im BzV Oberpfalz erst von Pads ins Redmine-Wiki gepackt, später in Tickets:

https://redmine.piratenpartei-bayern.de/projects/opf_bzvo/wiki/Protokolle

Bei AG bin ich mir nicht so sicher, solange sie nicht offiziell sind; für Vorstände, SG und Beauftragte wäre das aber genau das richtige. Zur besseren Auffindbarkeit kann man die Inhalte im Redmine auch gut verlinken oder zur ansprechenderen Darstellung woanders hinkopieren.

Das Ziel könnte ein “pirateninfo”-Nachfolger als Partei-Infoportal sein. Für so etwas schaue ich mir gerade statische Webseiten-Generatoren an. Jekyll wird z.B. von den tschechischen Piraten auch für die Hauptseite https://pirati.cz benutzt.

Damit könnte man interessante Lösungen bauen, die allen Leuten die Möglichkeit geben, Änderungen vorzuschlagen, ohne dass sie es direkt auf der Seite ändern können. Im Prinzip läuft das wie bei einem Open Source-Softwareprodukt, z.B. auf github mit Issues und Pull Requests.

Aktuell haben wir Wordpress (nur ein paar Leute mit Rechten können ändern) und Wiki (grundsätzlich kann jeder ändern oder nur ein paar Leute mit bestimmten Rechten bei gesperrten Seiten).

Wenn ich meine tägliche Arbeit an Open Source Software mit der Arbeit in der Partei vergleiche, was bei mir z.B. die Antrags-Arbeit in der AKO BPT ist, dann fühlt sich die Parteiarbeit öfter wie IT-Steinzeit an, was oft auch am Wiki liegt… Das führt hier aber zu weit; dazu muss ich mal noch ein eigenes Thema aufmachen.

Bis heute ist die letzte Umstellung nicht vollständig im Wiki umgesetzt.

Warum der Temrin Juli?
Warum der Temrin September?
Was ist mit den Servern? Wo ist bei denen das Problem?

Wieder so ein Beitrag, in dem man irgendetwas für die Füße geworfne bekommt.

Die Zeiten mit “informier Dich selbst” funktioniert SO nicht.
Auch das mit “Entscheidungen auf Fakten treffen” funktioniert so nicht.

Ist irgendeiner der hier Schreibenden eigentlich im Wiki aktiv?
Ein Wiki ist eben so gut, wie MEnschen darin davon gebrauch machen, die Seitne aktiv mit zu pflegen.

1 Like

Grob gesagt…
Juli interne Deadline für die Planung der Migration und Kündigungsfrist beim Hoster.
September Ende Vertrag beim Hoster.

Probleme mit den Servern sind z.B. Betriebskosten, Wartungsaufwand und alte/z.T. sterbende Hardware.

Das ist nicht falsch, aber …

Eine Organisationssoftware sollte die Strukturen und Abläufe der Organisation abbilden und solche Aufräumvorgänge automatisieren.

Ein Wiki ist sicher nicht die erste Wahl als CMS für Binärdateien, wie Druckvorlagen und Plakatentwürfe. Zahlreiche zum Teil nicht mehr funktionierende Wiki-Skripte zeigen, dass die Funktionalität nicht gereicht hat. Und das einige Seiten eine kaputte Versionsverwaltung haben ist sicher auch eine Folge der mangelnden Stabilität.

Die Tatsachen, dass wichtige Daten in Pads verbleiben und das man schon seit mindestens 8 Jahren vom im Wiki verstecken spricht, zeigen, dass ein Wiki letztlich nicht die richtige Wahl ist.

Was nicht heißen soll, dass ein Wiki für Teilaufgaben nicht doch sinvoll sein kann. Aber als einziges zentrales Medium eben nicht.

1 Like