Partkeepr: Partkeeper Wiki

Im Moment ist das einzige, was ich geschafft habe, "funktionieren" zu lassen, indem ich Googles zwischengespeicherte Seiten verwende. Sie suchen einfach nach einer relevanten Wiki-Seite, Google zeigt ein Ergebnis an und klicken dann, anstatt auf den Link selbst zu klicken, auf den kleinen Abwärtspfeil daneben und dann auf zwischengespeichert. Es wird nicht gestylt sein, aber der Inhalt ist da. Oder verwenden Sie archive.org: http://web.archive.org/web/20180310044536/http://wiki.partkeepr . org:80/wiki/Main_Page

Ich hoffe, dass das Wiki irgendwann zurückkommt, wenn auch nur als reines HTML in einem Ordner auf github (oder im Wiki-Tab hier).

Anscheinend ist das Wiki wieder online.

Hervorragende Nachrichten! Schließen.

Wie auch immer, weiß jemand, wo das Wiki gehostet wird? Liegt das noch in der Verantwortung von @Drachenkaetzchen? In einer anderen Ausgabe wird das Problem von Partkeepr, das im Moment etwas feststeckt, beschrieben. Es könnte eine gute Möglichkeit sein, @Drachenkaetzchen zu helfen und die Verantwortung dafür auf andere Schultern zu nehmen. Dann wird ein Backup des Wiki/SQL benötigt.

@Gasman2014 Alles in allem würde ich dafür stimmen, wieder zu öffnen, bis dieses Problem langfristig gelöst ist.

Ich bin bei @christianlupus , ich würde es stattdessen im Wiki-Bereich von githubs hosten , das sollte die Server und Schultern von entlasten .

Angesichts der Erwünschtheit einer längerfristigen Lösung und der Vorschläge von @C44Supra und @christianlupus , Felicia @Drachenkaetzchen durch die Archivierung dieser Daten und das eigenständige Hosten über Github zu unterstützen, öffne ich dies erneut. Die Informationen im Wiki sind sehr hilfreich bei der Fehlerbehebung bei Installationen - insbesondere in Nischensituationen, die nicht in der Hauptinstallationsanleitung beschrieben sind. Diese Informationen sollten zusammen mit der Codebasis verfügbar sein, um eine maximale Benutzerfreundlichkeit zu gewährleisten. Ich freue mich sehr, dass das Wiki wiederhergestellt wurde, aber vielleicht könnte es ohne allzu viel Arbeit mit dem Github-Wiki-Bereich kombiniert werden, der auch einige hilfreiche, aber zusätzliche und andere Informationen enthält.

Wenn jemand eine Möglichkeit bieten kann, das gehostete Wiki automatisch auf GitHub zu verschieben, lassen Sie es mich bitte wissen, aber nur, wenn Sie einen solchen Mechanismus tatsächlich getestet haben . Ein einfaches Google liefert viele Ergebnisse für einen solchen Mechanismus, und ich habe weder Zeit noch Energie, sie zu untersuchen.

Wenn Sie einen API-Zugriff für das aktuelle Wiki oder einen DB-Dump benötigen, lassen Sie es mich bitte wissen.

Ich würde gerne versuchen, dies vorzubereiten. Ich werde versuchen, in meinem persönlichen Konto zu einem Wiki zu migrieren. Soweit ich das gesehen habe, kann ich nur die neueste Version des Wikis migrieren und es sind einige manuelle Anpassungen erforderlich.

Ich habe versucht, die Wiki-Dateien auf Github zu migrieren. Das Ergebnis ist in diesem Repo sichtbar. Es sind noch einige kleinere Änderungen erforderlich (wie das Entfernen von Tippfehlern, das Umbenennen von Seiten, das Organisieren von Dateien usw.).

Leider hat der automatische Export nach XML (Standardmethode zum Export aus Mediawiki) einige Nachteile. Auf diese Weise geht der Verlauf der Seiten verloren und es werden keine Mediendateien exportiert. Ich habe sie manuell heruntergeladen, aber die Metadaten (wie der Titel und der Alternativtext) wurden nicht portiert. Außerdem ist das Wiki von github etwas eingeschränkter als das von Mediawiki, so dass zB Listen von Unterseiten unmöglich sind, soweit ich es herausgefunden habe.

@Drachenkaetzchen Ich möchte Sie bitten zu überprüfen, ob das Wiki auf diese Weise verwendet werden kann. Dann können Sie einfach die Seiten aus meinem Repo auf der Partkeepr-Seite installieren, wenn dies für Sie in Ordnung war. Kontaktieren Sie mich bei Fragen, ich helfe Ihnen gerne und stolz weiter.
PS: Ich habe Sie als Mitarbeiter zum Repo hinzugefügt, damit Sie damit herumspielen können.

Alle anderen sind herzlich eingeladen, im Wiki nach Fehlern zu suchen, die ich übersehen habe.

@Drachenkaetzchen Ich möchte Sie bitten zu überprüfen, ob das Wiki auf diese Weise verwendet werden kann.

Ich bin verwirrt, was genau soll ich überprüfen?

Ich habe das Wiki auf Github portiert. Bitte prüfen Sie, ob diese Arbeit für Ihre Qualitätsstandards akzeptabel ist und ich nicht völlig vermasselt habe.

Ich denke, Sie sollten die Benutzer fragen ;) Ich benutze das Wiki selten.

Ich schlage vor, um Feedback zur Mailingliste zu bitten

Ich habe eine Nachricht auf der Mailingliste hinterlassen. Querverweise hier nur zur Vervollständigung.

Ich schlage vor, dass wir Github Pages anstelle eines Github-Wiki verwenden. Da hätten wir mehr Möglichkeiten bezüglich der Dateiorganisation und es gibt keinen großen Unterschied zwischen den beiden Lösungen. Gibt es Optionen, für die ein Github-Wiki besser geeignet ist?

@Drachenkaetzchen Ich habe von anderen Benutzern nicht viel Aufmerksamkeit und Reaktion bezüglich der Migration des Wikis erhalten. Haben Sie einen Zeitplan oder wie würden wir hier vorgehen? Ich würde die Migration so vorbereiten, dass die Links funktionieren und die Dateinamen nützlich sind. Da dies Handarbeit ist, würde ich es vorziehen, es nicht zu tun, wenn es später nicht verwendet wird.

Ich kann wirklich kein Feedback geben. Ich bin nur in der Lage, Admin-Zeug für das Projekt zu erledigen.

OK, dann bitte ich @dromer um seine Meinung.

Hallo zusammen, ich habe keine Diskussion über die Migration des Wikis auf Github gesehen.

Ich denke, es ist sinnvoll, alle Informationen, die wir haben, in einer einzigen Ressource zu konzentrieren. Aber auch die Informationen, über die wir migrieren, sollten relevant und auf Altlasten beschnitten sein.

Meine Erfahrung mit Github-Wiki und -Seiten ist so gut wie nicht vorhanden, daher kann ich mich dort nicht wirklich äußern.

[Bearbeiten: ah Seiten wären wie eine Jekyll-Site oder so. Bevorzugen Sie dann einen Autoformatter?]

ah-Seiten wären wie eine Jekyll-Site oder so.

Jo, das ist es so ziemlich. Das Wiki übrigens auch. Der Unterschied besteht darin, dass Seiten für eine Site gedacht sind, während das Wiki für eine grobe Sammlung von mehr oder weniger kurzen Informationsblöcken gedacht ist, die nicht sortiert/organisiert sind. Dies hat mir (bei meinem ersten Test der Migration) einige Probleme bereitet, da Dateinamen automatisch vom zugrunde liegenden Server erraten werden, z.

Was meinst du mit deinem Satz

Bevorzugen Sie dann einen Autoformatter?

Du meinst das Styling/Layout?

Entschuldigung, ich meinte den Site-Generator. Ich glaube, Github-Seiten können andere als Jekyll verwenden?

Ich bin mir jedoch nicht sicher, ob jekyll der einfachste / schönste Weg ist, ein Wiki zu organisieren, was genau wäre der Vorteil gegenüber dem Github-Wiki?

Ich denke, wir sollten noch nicht unbedingt die Haupt-Partkeepr-Website hosten, konzentrieren wir uns auf aktuelle Informationsressourcen wie das Wiki.

Es gibt auch einige fragmentierte Seiten im Github-Wiki, denke ich. All dies sollte nur mit relevanten und korrekten Informationen für den aktuellen Status des Projekts zusammengeführt werden.

Entschuldigung, ich meinte den Site-Generator. Ich glaube, Github-Seiten können andere als Jekyll verwenden?

Kein Problem. Könnte sein, ich habe es noch nicht ganz durchgearbeitet.

Ich bin mir jedoch nicht sicher, ob jekyll der einfachste / schönste Weg ist, ein Wiki zu organisieren, was genau wäre der Vorteil gegenüber dem Github-Wiki?

Nun, der Unterschied ist, um ehrlich zu sein, gering, soweit ich das sehe. Beide nehmen Markdown (oder ein beliebiges Format, das Pandoc lesen kann) und formatieren es auf eine schöne Art und Weise.
Ich habe das Problem gefunden, dass das Wiki keine Namensräume zulässt und die Zuordnung zwischen Links und dem entsprechenden Dateinamen eine Art Heuristik ist:

• Das Wiki enthält zwei Seiten, die sich nur im Titel unterscheiden ( 1 , 2 ). Ich musste eines davon manuell entfernen, damit die Heuristik das richtige auswählt.
• Unterordner (die als eine Art Namespace verwendet werden) können nur erstellt werden, wenn Sie mit git manuell auschecken. Die Links respektieren diese Namensteilung nicht, daher können Sie jeden Dateinamen nur einmal haben, was die Ordnerstruktur unpraktisch macht. Ich weiß nicht, wie github die zu benennende Seite auswählt, wenn zwei Dateien den gleichen Namen haben.

Ein zusätzlicher Vorteil der github Pages-Lösung besteht darin, dass Sie jekyll lokal ausführen können, um das Erscheinungsbild und alle Links zu überprüfen, ohne es noch zu veröffentlichen. Außerdem denke ich, dass Sie mehr Styling machen könnten (aber das müsste ich überprüfen).

Ich denke, wir sollten noch nicht unbedingt die Haupt-Partkeepr-Website hosten, konzentrieren wir uns auf aktuelle Informationsressourcen wie das Wiki.

Nein, ich denke, das befindet sich im Moment an einem guten Standort.
Obwohl ich vielleicht darauf hinweisen möchte, dass es (?) die Idee gab, github für die Hauptseite zu verwenden. Im Bedarfsfall könnte man auf github migrieren (wenn sich die finanzielle Situation von Drachenkätzchen verschlechtert und sie Probleme hat, den Server zu bezahlen).

Der Sinn dieses Problems besteht darin, das aktuelle Wiki für den Fall zu erhalten, dass die Server ausfallen.

Es gibt auch einige fragmentierte Seiten im Github-Wiki, denke ich. All dies sollte nur mit relevanten und korrekten Informationen für den aktuellen Status des Projekts zusammengeführt werden.

Ja und nein. Es sollte sich auf die neueste Version der Software beziehen. Allerdings finde ich die Dokumentation im Projekt vergleichsweise gering. Ich weiß, dass uns das Personal fehlt, aber ohne Dokumentation haben die Benutzer mehr Probleme zu sehen, wie die Funktionalität der Software funktioniert.
Daher verpflichte ich mich, die Dokumentation auf die neueste Version zu aktualisieren, aber zB Migrationsleitfäden aus älteren Staaten aufzubewahren, jedoch für stark veraltete Versionen, die seit einiger Zeit stark veraltet sind (evtl. einige Seiten aufteilen, um sie besser lesbar zu machen).

Ich hoffe, dass wir in der Community etwas Anklang finden (Sie werden vielleicht über meinen optimistischen Gedanken lachen), der durch das Hinzufügen von Tipps und Tricks zum Einrichten von Dingen hilft. In den letzten Tagen, als ich die alten Themen durchgearbeitet habe, habe ich einige gute Ideen von Community-Mitgliedern gesehen, die es wert sein könnten, auf einer Wiki-ähnlichen Seite erwähnt zu werden.

Ich bin so oder so glücklich.. aber einen Betreuer zu haben wäre eine gute Idee... meine Erfahrung ist, dass diese Dinger schnell altern

Das ist wahr. Sie meinen eine Person, die sich ausschließlich um die Aktualität der Dokumentation kümmert?

Ich wäre in Ordnung, das Projekt auch auf diese Weise zu unterstützen. Versteh mich nicht falsch: Ich dränge nicht in diese Position. Es sollte einvernehmlich entschieden werden.
Im Moment gibt es nicht viel Neues zu dokumentieren. Hauptsächlich Aktualisierung des bestehenden. Dies kann sich ändern, wenn das Projekt wieder an Fahrt gewinnt und neuer Code geschrieben/geändert wird. Dann ist der Betreuer der Dokumentation auf die Unterstützung der Entwickler in dem Sinne angewiesen, dass der Manager nicht in der Lage ist, alle technischen Details zu verstehen.

Ich habe heute etwas mehr Energie, deshalb hier ein paar Gedanken:

• Das aktuelle Wiki erschwert es den Leuten, Dokumentationen beizutragen, da ich die Registrierung deaktivieren musste, wodurch ich manuell Benutzer erstellen musste
• Das in GitHub integrierte Wiki erschwert die Navigation, insbesondere wenn viele Seiten nicht richtig von der Hauptseite verlinkt sind.
• Es muss einfach sein, eine Dokumentation beizusteuern. Am besten dort, wo Benutzer einfach auf eine Schaltfläche "Seite bearbeiten" klicken können, um vorhandene Inhalte zu bearbeiten, und auf eine Schaltfläche, um neue Inhalte zu erstellen. Ein Beispiel, das mir gefällt, finden Sie hier: http://marlinfw.org/docs/configuration/configuration.html - Änderungen führen zu einem Pull-Request, damit es von einem Dokumentationspfleger überprüft und richtig verlinkt werden kann
• Im vorherigen Beispiel gibt es jedoch keine Schaltfläche "Neue Seite", ich bin mir nicht sicher, wie dies gemacht werden könnte

• Das aktuelle Wiki erschwert es den Leuten, Dokumentationen beizutragen, da ich die Registrierung deaktivieren musste, wodurch ich manuell Benutzer erstellen musste

Das ist irgendwie ein Widerspruch zu einem Wiki, aber ich verstehe die Bedürfnisse.

• Das in GitHub integrierte Wiki erschwert die Navigation, insbesondere wenn viele Seiten nicht richtig von der Hauptseite verlinkt sind.

Das ist vollkommen richtig. Ich finde es nicht sehr ästhetisch, wie das Wiki aufgebaut ist. Es muss sichergestellt werden, dass im gesamten Wiki ein feines Linknetz vorhanden ist, um die Navigation zu vereinfachen.

• Es muss einfach sein, eine Dokumentation beizusteuern. Am besten dort, wo Benutzer einfach auf eine Schaltfläche "Seite bearbeiten" klicken können, um vorhandene Inhalte zu bearbeiten, und auf eine Schaltfläche, um neue Inhalte zu erstellen. Ein Beispiel, das mir gefällt, finden Sie hier: http://marlinfw.org/docs/configuration/configuration.html - Änderungen führen zu einem Pull-Request, damit es von einem Dokumentationspfleger überprüft und richtig verlinkt werden kann
• Im vorherigen Beispiel gibt es jedoch keine Schaltfläche "Neue Seite", ich bin mir nicht sicher, wie dies gemacht werden könnte

Sie verwenden die Github-Seiten-Funktion, jedoch in einem aufwändigeren Setup als das grundlegende. Ich habe noch nicht alles durchgestanden, aber ich kann in die Dinge schauen...

Ein Benutzer sammelt aktiv Informationen in einem lokalen WIKI, das unter https://readthedocs.web.cern.ch/display/PARTK geteilt wird
Er hat angeboten, diese Informationen an einen anderen Ort zu übertragen, aber um Anleitung durch das Projektteam wird gebeten. Den Thread dazu finden Sie in den PartKeepr Google Groups https://groups.google.com/g/partkeepr-users/c/ehqapXqyY0o/m/1VWkA00dDAAJ