Hallo romy,

Letztes Jahr hat glaube ich Mark das I gekriegt und er hat ewrwähnt es in Darmstadt zu machen, bisher glaube ich allerdings inoffiziell.
Vielleicht kann es ja jemand bestätigen ;)

Jepp, das <I> hab ich (auch, wenn ich mit 'c' geschrieben werde - aber ich habe ja eine gute Fuzzy-Suche eingebaut ;).
Ben wird mir bei der Organisation wohl ein wenig helfen.

Das diesjährige Treffen wird also sehr wahrscheinlich in Darmstadt stattfinden - ich habe erst vor wenigen Tagen mit der Organisation begonnen und bereits bei der Jugendherberge 30 Plätze reservieren lassen. Sobald die meisten Dinge klar sind wird es ein Anmeldeformular geben - ich rechne damit, dass dieses in 2-4 Wochen online gehen kann.

Das Treffen sollte am letzten Wochenende des August stattfinden, also vom 24. bis zum 26. August 2007.

Grüße

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

Hallo Rolf,

Hei Gernot, alter Analfixierer

Das mit "Darm statt" ist ja ein alter Kalauer.

mir gehts ähnlich, da fehlen mir einfach die Ausreden wenn man in 5 min in die Innenstadt läuft ... :)

Ich habe ja damals in der Nähe des Darmbachs in der Darmstraße 12 gewohnt, ebenfalls 5 Minuten von der Innenstadt Darmstadts, leicht zu merken über den Zwölffingerdarm. Mehr Darm geht gar nicht als Aufenthaltsort!

Wann finden die Teile normalerweise statt? irgendwann im Sommer oder?

Die Jugendherberge ist ja auch da in der Nähe, mit angeschlossenem Schwimmbad, das aus dem Darmbach gespeist wird. Passt mir also gut!

http://www.djh-hessen.de/jh/jugendherberge-darmstadt/

Gruß Gernot

Hi

Ohh, sorry. Deine Mail ist angekommen. Ich habe sie schlicht übersehen. Antwort ist unterwegs.

Danke ... erhalten ... reingeschaut ... Kopf geschüttelt..

Ok ich möchte ein kurzes Feedback geben ...

Also meines erachtens ist die Idee sehr gut, allerdings finde ich man hat sich in der Umsetzung verhoben, der Frust war absehbar.

Was mir auffiel:

1. NAVIGATION: Ich hatte massive Probleme mich zurechtzufinden, die navigation ist komplett anders. Wenn jmd die selfhtml-doku verbessern möchte muss er über verschlungene Pfade zur entsprechenden Wikiseite finden.

2.  STRATEGIE: Es wäre besser gewesen Bottom-Up an die Sache ranzugehen und erst mal nur einen Teilbereich der Doku abzubilden. Javascript böte sich beispielsweise an weil sich da der Kapitel-Aufbau stringent aus den ECMA-Script spezifikationen ableiten ließe.

3. GRUNDBESTAND: Ein Grudnprinzip von Wikis ist dass die Leute zu 99% zum nachschlagen hinkommen, und 1% von ihnen zum korrigieren verleitet werden. Dieses Wiki hat aber scheinbar nur ne Kapitelstruktur vorwiegend leerer Seiten. Scheinbar hat man darauf verzichtet die Doku erstmal 1 zu 1 auf das Wiki (automatisch) abzubilden und darauf gehofft alles "mit der Energie des Verstehens" komplett von neu auf Aufbauen zu können. Die Leute können also zum nachschlagen erstmal gar nicht vorbeikommen und auch nicht "verführt" werden. AFAIK hat selbst Wikipedia in seinen Anfängen auf eine bereits bestehende Enzyklopädie aufgebaut die dann evolutionär gewachsen ist.

4. DATAMINING: Was hier komplett verloren geht ist das Selfhtml schon von Anfang an eine kollaboratives Projekt war. Der Wissensgehalt der in den Forumsarchiven schlummert liegt um zig Faktoren höher als was die Doku bietet. Michael Schröpls [*] Suchmaschine ist es die diesen Wissenschatz zu heben versucht. Alleine der bezug zur Doku war nur über Umwege möglich die Leute mussten sdie Suchmaschine finden und benutzen.

Ich habe schon des öfteren vorgeschlagen (2001 ?) das in der Doku suchlinks eingebaut werden sollten die alle Forumsbeiträge raussuchen die auf den jeweiligen Anchor verlinken. Das ginge auch mit dem Bugtracker. Um die Suchmaschine zu schonen könnten diese "Backlinks" in in NAchtläufen aktualisiert werden. Gebe es zu jedem Paragraphenanchor in der Doku noch einen Link um automatisch einen Forumsbeitrag zu erstellen der eben diesen Anchor verlinkt, dann häten wir die Funktion der Wiki-Diskussionseiten schon seit Jahren im Forum abbilden können, und zwar *viel* besser als die chaotischen Diskussionsseiten von Mediawiki es können.

5. PARALLELE STRUKTUREN:  Wo wird das Gemeinschaftswissen der Community bisher alles gebunkert? Bugtracker, Haupt-Forum, Nebenforen, Googlegroups, ... diese Zersplitterung und Zerfaserung schwächt ungemein. Der Wissensschatz sollte durch eine einzige Suchmaschine gegriffen werden können. Die Funktionalität des Bugtrackers sollte am besten auch auf das Forum abgebildet werden. (einen neue Kategorie [BUGTRACKER] und ein open/close Mechanismus würden reichen. ...  und es müsste entweder ne Möglichkeit geben alte Threads wiederzubeleben, oder zumindest mit neuen "Weiterführungsthreads" hart verlinken zu können. (OK ich gebe zu dass der teufel im Detail läge, aber wozu haben wir ein so gutes Forum?)

6. RAD NEU ERFINDEN: bzw. XML, XSLT, SVN: Ich möchte mal darauf verweisen wie oft hier große Softwareprojekte den Bach runtergegangen sind. Man sollte lieber kleine Brötchen backen die in kleinen Wertschöpfungs-Zyklen resultieren. Ich kann nur anraten mal einen Blick auf TWIKI zu werfen, zig Großunternehmen nutzen es mittlerweile zu kollaborativen Arbeit, es gibt eine Unmengen von Perl-Plugins, RCS wird eingebunden, Datenhaltung in Flatfiles (-> Download Doku!), Workflows können AFAIK auch realisiert werden. Zumindest konzeptionell kann man dort vieles lernen bzw. vielleicht Module wiederverwenden. Swen hat in einem Thread in der googlegroup auch mögliche Wiki-Kandidaten auf 3 Ansätze runtergekocht und neben Mediawiki kam auch Twiki raus!
http://groups.google.com/group/selfhtml-wiki/browse_thread/thread/2dc96aa253214014#

Naja ist wieder länger geworden als ich dachte... hoffe ich konnte ein paar fruchtbare Anregungen geben.

Viele Grüße
 LanX

[*] nebenbei bemerkt ist Michael Schröpl meines Erachtens mit seinem weitsichtigem Code die zweitwichtigste Gestalt  in diesem Projekt gewesen. Wer weiss wie gut das Forum ohne diese Suchmaschine liefe.