Herzlichen Glückwunsch - es ist ein Wiki!

[Marc Reichelt]

Hallo Basti_,

Dazu brauchen wir eure Mithilfe:

• Unter welche Lizenz würdet ihr den Inhalt stellen? Wir finden, dass sich die Lizenz Creative Commons BY-SA gut eignen würde, sind aber offen für Neues.

Ja, wie andernorts schon erwähnt BY-NC-SA möglicherweise.

Die Lizenzfrage muss in der Tat noch geklärt werden. Interessant finde ich, dass mehrere hier im Forum zu BY-NC-SA tendieren.

Für Diskussionen zum Inhalt finde ich die Diskussionsseiten am sinnvollsten, Für allgemeine Diskussionen, über Module, Struktur und so weiter, wahlweise hier in das vorhandene CForum integrieren oder als Diskussionsseiten unterhalb einer Infoseite zur technischen Entwicklung des Wikis.

Wird denke ich so gemacht werden.

• Generelle Vorgehensweise: Würdet ihr die Inhalte von SELFHTML 8.1.2 ins Wiki übertragen? Oder z. B. eher in Seiten von SELFHTML 8.1.2 Links zum Wiki einfügen, sobald dort neuere Inhalte vorliegen, und so für eine allmähliche Migration sorgen?

Zu diesem Punkt bin ich unschlüssig. einerseits glaube ich, dass ein kompletter Neustart nicht schaden könnte, andererseits sollten schnell Inhalte generiert, sprich die aktuelle Version übertragen, werden.

Das ist eben die Schwierigkeit. Und man hat so auch keine "Inhalte generiert", sondern nur Inhalte von 8.1.2 ins Wiki kopiert. Aus den bisherigen Threads lese ich eine Tendenz dazu heraus, das Wiki mit neueren Inhalten zu befüllen und diese Stück für Stück von 8.1.2 heraus zu verlinken.

Grundsätzlich sollte man den Wegfall der Versionierung von HTML5 berücksichtigen. Es sollte zwischen HTML4.x und HTML5 unterschieden werden, wenn relevant, sprich: wenn Änderungen an Elementen vorliegen.

Die alten Tutorials zu HTML sollten erhalten bleiben, für HTML5 neue erstellt werden.

Von welchen Tutorials sprichst du? Soweit ich das sehe hatte SELFHTML 8.x keine richtigen Tutorials. Das war auch einer der neuen Punkte bei unserer bisherigen Arbeit an SELFHTML 9.

Es wird wohl nicht ganz einfach die optimale Struktur zu finden, ich denke zunächst sollte man jeden Teilbereich für sich einpflegen und die Art und Häufigkeit dann im Entstehung- und Weiterentwicklungsprozess anpassen.

Klingt gut.

• Bei SELFHTML gab es immer Beispiele ("Anzeigebeispiel: So sieht's aus"). Diese sollten in irgendeiner Form erhalten bleiben. Wenn allerdings jeder HTML-, CSS- und JavaScript-Dateien und mehr (man denke auch an Java, Flash und eventuell sogar PHP) hochladen kann sind Sicherheitslücken und Missbrauch vorprogrammiert. Lösungsansätze? Die Beispiele müssen zwar nicht ab sofort verfügbar sein, sind aber für später ziemlich wichtig.

Die Sandbox-Lösung die schon genannt wurde klingt interessant, andererseits könnten die sicherheitskritischen Codebeispiele bei der Redaktion eingereicht und geprüft werden.

Meiner Meinung nach sind alle Codebeispiele sicherheitskritisch. Ich verstehe da den Vorteil einer Sandbox nicht. Wenn mit "Sandbox" ein Bereich gemeint ist, in den neue Beispiele hochgeladen werden können und die erst nach Sichtung freigeschaltet werden: Das fände ich gut.

• Last but not least: Habt ihr sonst noch Anregungen oder Ideen?

Ich denke zum Schutz gegen Spammer/Trolle etc. könnte eine Registrierpflicht und ein Schutzmechanismus (ähnlich einem IDS, bzw. ail2Ban) helfen.

Eine Registrierungspflicht ist per se sinnvoll. Ich glaube das ist im Wiki bereits umgesetzt.

Im weiteren Verlauf könnte man verschiedene Benutzergruppen für die Helfer einrichten z.B.:

1 (default) - darf schreiben, Redaktion muss prüfen/freigeben
2 (vertrauenswürdig) - darf schreiben, wird sofort veröffentlicht, wird der Redaktion zur Prüfung angeboten.
3 (minderwertige Arbeit/Spamt/Trollt) - Darf Artikel nicht bearbeiten, sich nur an der Diskussionsseite beteiligen
4 (Spammer/Trolle) - nur lesen
5 (unerwünscht) - Verbannen, Zugriff nach allen Möglichkeiten verweigern.

Diese Liste ist als unvollständiger Vorschlag zu werten.

Bei 3, 4 und 5 bleibt natürlich das Problem, dass sich jeder mit einer neuen E-Mail-Adresse einen neuen Account holen kann und so wieder den default-Status bekommt. Eine Registrierungspflicht hat aber schon mal den großen Vorteil, dass wir die Änderungen eines Benutzers sichten und diese zurücknehmen können - falls nötig.
Bei 1 (default) gibt es noch ein weiteres Problem: Genau dieses Konzept schreckt neue Leute ab. Und das wollen wir dieses Mal ja vermeiden.

Grüße

Marc Reichelt || http://www.marcreichelt.de/