staging.inyokaproject.org

Hallo zusammen, in den letzten Monaten hat die Aktivität im Wiki irgendwie nachgelassen. Gibt es da Gründe für? LG

DJKUhpisse schrieb:

[…] Gibt es da Gründe für?

Es ist einfach zu heiß – besonders im Sommer. Auch die Aktivität im Forum hat sich verringert.

kB schrieb:

DJKUhpisse schrieb:

[…] Gibt es da Gründe für?

Es ist einfach zu heiß – besonders im Sommer. Auch die Aktivität im Forum hat sich verringert.

War das die letzten Jahre auch so? Ich hatte nicht den Eindruck.

Hallo,

alles total ausgereift? Keine Lust auf Community Arbeit? Lieber nehmen als geben?

Das Wikiteam tritt ja auch seit ein paar Wochen eher dadurch in Erscheinung, dass es nicht Erscheinung tritt. Es gibt seit Wochen etliche fertige Baustellen (nicht nur von mir) und es erfolgt null Komma null Rückmeldung, auch nicht bei Nachfrage. Es gibt immer noch einen Haufen ungetesteter Artikel, die noch vom EOL Bionic übrig sind. Mit deren Aufräumen (was systembedingt nur das Wikiteam machen kann) kümmert sich auch niemand mehr.

Vielleicht ist das Wiki auch 2022 ein totes Pferd, das wir nur noch alle versuchen, trotzdem zu reiten.

Gruß, noisefloor

noisefloor schrieb:

Vielleicht

Vielleicht. Vielleicht muss sich auch gerade etwas neu sortieren, weil die über Jahre treibende Kraft des Wiki mehr oder weniger über Nacht die Segel gestrichen hat.

Das soll kein Vorwurf sein, jeder hat mal genug, v.a. wenn man sich über Jahre so intensiv investiert hat. Irgendwann ist die Luft raus.

Aber: Niemand aus dem Wikiteam wird von heute auf morgen die Aufgabe so übernehmen können und wollen, wie du, lieber noisefloor, sie über Jahre ausgefüllt hast.

Also bitte sei und seid so fair und gebt dem Wikiteam eine Chance und etwas Zeit, um sich neu zu finden.

Ob das Wiki stirbt oder nicht, entscheidet sich nicht innerhalb von 4 oder 8 Wochen.

Viele Grüße

BillMaier

Liebe Freunde,

ja, die Situation ist kritisch. Aber nicht hoffnungslos. Mir persönlich tut es vor allem um jene von Euch leid, die so viel Mühe und Zeit ins Schreiben von Artikeln stecken und dann wochenlang auf eine Reaktion warten mussten. Sorry!

Die gute Nachricht: Wir arbeiten gerade intern im Gesamtteam mit Hochdruck daran, die Probleme zu beheben. Unser Brainstorming verspricht da einige optimistisch-stimmende Verbesserungen, Neuerungen und Rekrutierungsoffensiven. Erschwerend kommt jetzt aber noch die Urlaubszeit hinzu. Darf ich alle noch um etwas Geduld bitten, bis wir soweit sind? Ich bin überzeugt, unser großartige Wiki ist weder tot, noch liegt sie im Sterben sondern wird auch in Zukunft das führende Portal im deutschsprachigen Raum rund um Ubuntu bleiben! Sie schwächelt halt gerade ein wenig. Jedes Projekt hat mal seine Krisen.

Inzwischen darf ich allen schon mal folgende Links an Herz legen:

• Teammitglied werden - etwas für Dich?:

• Kontakt zum Wikiteam - für alle die Lust haben, unser Team zu unterstützen.

mubuntuHH fürs Wikiteam

PS: In Kürze folgen noch ein paar weitere, transparente Infos, vermutlich über Ikhaya.

Wie versprochen, hier die Info vom Wikiteam.

Ich habe ja schon auch im Wiki hier mitgewirkt ☺ Vllt. ist es einfach schon komplett, so wie ein "kompletter Fußballspieler Lewandowski" ?

Ich könnte wieder alles auf das aktuelle Ubuntu (LTS) testen, da fehlen bestimmt Einträge.

Da würde ich zum Beispiel die Liste empfehlen.

(Bloß das die Aktualisierung nicht für das aktuelle LTS zu funktionieren scheint)

Ich knüpfe mir auch erstmal nur die Major-Programme vor, wenn nicht schon geschehen 😉

Hej,

kB schrieb:

...Auch die Aktivität im Forum hat sich verringert.

und zwar geschätzt 1/10! (max: Der Rekord liegt bei 4943 am 27. September 2016 16:26.)

karzer schrieb:

Da würde ich zum Beispiel die Liste empfehlen.

dazu auch noch weiter unten

(Bloß das die Aktualisierung nicht für das aktuelle LTS zu funktionieren scheint)

das verstehe ich nicht, der Beaver ist doch diejenige Version, die (nur noch) bis April 23 'aktuell' ist, womit dann alle Artikel, die 'nur' diesen Tag haben, automatisch ins Archiv verschoben werden.

Steev1 schrieb:

Ich knüpfe mir auch erstmal nur die Major-Programme vor, wenn nicht schon geschehen 😉

sehr schön, für mich kann ich nur sagen, daß ich mich auf "meine eigenen" Artikel konzentriere, resp. um das Thema, welches mich interessiert (grub).

Andererseits gibt es Artikel (auch in meinem favorisierten Bereich), die aus verschiedenen Gründen 'unüberschaubar' geworden sind (nur ein Beispiel GRUB 2/Konfiguration, daß einem die Lust vergeht, das alles durchzutesten.

Und selbst hier, wo ich konsequent darauf achte, daß der Artikel kompakt bleibt, ist mir der mit 11 DIN A4 Seiten eigentlich™ schon zu groß, an solchen wie diesen (man vergleiche zwischen dem aktuellen Stand und dem bereits 2015 von MannMitHut gründlich überarbeiteten) beißt man sich da eher die Zähne aus.

Evt. sollte man mal über eine max Größe von Seiten nachdenken.

Gruß black tencate

black_tencate schrieb:

Andererseits gibt es Artikel (auch in meinem favorisierten Bereich), die aus verschiedenen Gründen 'unüberschaubar' geworden sind (nur ein Beispiel GRUB 2/Konfiguration, daß einem die Lust vergeht, das alles durchzutesten.

Verstehe ich absolut. Was wäre dein Vorschlag? Aufteilen? War und bin ich persönlich immer dafür und habe das mit vielen Artikeln auch schon gemacht.

Und selbst hier, wo ich konsequent darauf achte, daß der Artikel kompakt bleibt, ist mir der mit 11 DIN A4 Seiten eigentlich™ schon zu groß

Hmm, okay, was wäre hier dein Vorschlag 😉 ?

solchen wie diesen (man vergleiche zwischen dem aktuellen Stand und dem bereits 2015 von MannMitHut gründlich überarbeiteten) beißt man sich da eher die Zähne aus.

Bin ich komplett bei dir. Mindestens die H1-Überschriften könnte man hier ebenfalls zu einem eigenen Artikel machen. Wobei man sich fragen muss, ob es da überhaupt so einen ausführlichen Artikel braucht. Mal ehrlich: Wer lesen kann ist klar im Vorteil - das gilt nicht nur für die Wikiartikel, sondern auch für die Texte des Installers. Ich meine, die Leute machen das ja nicht umsonst, dass sie auch dort Texte hinschreiben.

Evt. sollte man mal über eine max Größe von Seiten nachdenken.

Technisch? Oder organisatorisch? Von ersterem halte ich gar nichts. Zweiteres kann und sollte das Wikiteam bei der Abnahme aus der Baustelle tun - da gab es auch (wenn auch selten) schon den einen oder anderen Kandidaten, der dann erst nach einer weitern Überarbeitung (und deutlichen Reduktion bzw. Aufteilung) ins Wiki durfte.

Gruß BillMaier

Hallo,

Zweiteres kann und sollte das Wikiteam bei der Abnahme aus der Baustelle tun

IMHO sind viele superlange Seiten wie SSH organisch gewachsen, d.h. bei der Abnahme der Baustelle bzw. der Veröffentlichung waren die sicher (viel) kürzer und vieles ist dann nach und nach dazu gekommen.

Grundsätzlich sehe ich es auch genau so, dass die Testbereitsschaft mit der Länge des Artikels sinkt. Gerade dann, wann ein Artikel diverse Szenarien beschriebt, die man selber vielleicht gar nicht nutzt (wie z.B. im SSH oder Qemu Artikel beschrieben).

Was sicherlich _kein_ Grund ist, Wissen wegzuwerfen oder nicht aufzuschreiben - aber halt besser stärker modularisiert. Wie auch immer das idealerweise umgesetzt wird, ohne das die Hürde für das Schreiben von Artikeln höher bzw. komplexer wird.

Gruß, noisefloor

SSH wäre für mich auch so ein Kandidat, der sich easy aufteilen lässt.

Vermutlich sinnvoll wären auch …

1. Textbausteine für Snap und Flatpak; beides wird immer wichtiger und sie scheinen zumindest teilweise PPAs zu verdrängen;

2. etwas klarere Richtlinien, welche Installationsarten in welcher Reihenfolge erwähnt werden sollen (das hier ist sehr allgemein;

3. recht klare Antworten darauf, was geschehen soll, wenn sich Programmversionen (und damit Wiki-Artikel) für verschiedene Ubuntu-Version stark unterscheiden;

4. Hinweise, wie mit – für die gegenwärtige Ubuntu-Version – nicht mehr aktuellen Informationen (die für eine alte getestete Version stimmen) umgegangen werden soll;

5. eine klarere Klärung des Umgangs mit (Third-Party-) Plugins? Gerade, wenn diese (so beispielsweise für Vim, Thunderbird, Firefox, Zotero, ...) essentiellen Zusatznutzen bieten. Unterartikel?

(Ich bin nicht alle Referenzen-Seiten durchgegangen; vielleicht wird auf die Fragen dort teils schon eingegangen.)

Beispiel: Zotero. Das ist ein Programm, das ich täglich nutze und sehr gut kenne. Ich wollte den Artikel also für 22.04 testen. Probleme:

1. PPA: Das ist nicht mehr relevant – es muss also gestrichen werden. Es gibt tar-Archive über Github, Snaps und Flatpaks. Frage: Was hat Priorität? Wie kann man Snaps einfach mit einem Textbaustein in den Artikel einbinden? (Im Augenblick muss man, wenn ich das richtig sehe, Befehlszeile und Fremdquellenwarnung manuell einfügen?)

2. Abschnitt "Deinstallation": Dieser würde nicht für Snaps gelten, also müsste er ergänzt oder gestrichen werden.

3. Abschnitt "Lytero": Ich schätze das als eher irrelevant und vielleicht auch tot ein, bin mir aber nicht sicher. Ich weiß daher nicht, ob es entfernt werden kann/sollte oder nicht.

Ergänzung: Eine zu lange Seite, die IMO um Unterartikel ergänzt werden sollte, ist Vim. Das wollte ich neulich für 22.04 testen, der Artikel war mir dafür aber (vorerst) zu lang. Hier könnte es beispielsweise Unterartikel zur Benutzung, zu Erweiterungen, zur Personalisierung und zu Tipps geben. Außerdem ist im konkreten Fall auch die Frage, wie mit Neovim umgegangen werden soll. (Unterartikel zu Vim oder eigenständiger Artikel?)