Hallo,

Zitat Zitat von jhr-online Beitrag anzeigen
Deine Vorschläge haben was, wobei ein CMS natürlich auch Layout und Co. für eine Homepage bedeutet. Das ist wieder Arbeit, die auch jemand machen muss...
das stimmt, allerdings habe ich dahingehend gleich noch einen Vorschlag: Meine private Webseite läuft auf einem von mir geschriebenen Mini-CMS, wobei das Design hardcoded (aber relativ leicht anpassbar) ist. Ich setze die Skriptsammlung auch ein für eine Theater-Webseite und habe bisher keinerlei Probleme damit gehabt. Diese Skriptsammlung könnte man (kostenfrei - ich habe zwar noch keine Lizenz festgelegt, aber das wird wenn dann sowieso irgendwie offen sein "müssen" - es ist php ;)) auch gern für den monitor verwenden. Für die Gestaltung der Inhalte brauche ich persönlich (mit sauberem CSS) nur wenige Tags (h2...h4, p, img class="picleft" und ein paar mehr), ein news-Modul wäre schnell geschrieben. Updates pflege ich per FTP-Upload ein, allerdings könnte man das auch noch halbwegs zeitnah auf eine Upload-Funktion mit Username/Passwort-Schutz umdrehen. Wäre halt nicht so umfangreich wie ein echtes CMS aber trotzdem sehr einfach in der Pflege hinterher, zumal sich die Informationen, die ein Anwender braucht, sicherlich auf sagen wir unter 20 Seiten (inklusive Hintergrundinfos über ZVEI-Tonfolgen, POCSAG, FMS und so weiter) darstellen lassen. Es unterstützt einen quasi lediglich darin, die Navigation vom Inhalt zu trennen und diese automatisch aus zwei Textdateien zusammen zu bauen und den Inhalt (rohes HTML oder natürlich auch die Ausgabe von php-Skripten) zu includen.

Inhaltlich schwebt mir zur Zeit vor:
/Kapitel 1: monitord
* Startseite (Begrüßung, was ist monitor, kurz)
* Der monitord (was ist der monitord, Geschichte)
* Anwendung (wie nutzt man den monitord)
* Konfiguration (Erklärung des XML-Configfile)
* Download (vorkompilierte Binaries für div. Systeme, komplette config.xml)
* Ressourcen (Forum, Wiki, SVN, ... Linksammlung halt)
* Impressum
/ Kapitel 2: Frontends
* Frontend 1
* Frontend 2
/ Kapitel 3: Enwicklung/Development
* Aktueller Stand der Entwicklung
* Sourcecode (SVN einschließlich minimaler Nutzungsanleitung -> Checkout-Befehlssequenz, zip-/tgz-File der Sourcen)
* Kompilieren (kurz erklärt, speziell um die Umgebung auf Win32 darzustellen)
* Features in 2.x+1 (Vorschläge für kommende Versionen)
* Links (Wiki, ...)

Dieser Web-Teil bliebe meiner Meinung nach bestehen, auch wenn man zu SF wechseln würde, denn eine ordentliche Projektseite mit eigener Domain macht sich immer sehr positiv, finde ich.

Zitat Zitat von jhr-online Beitrag anzeigen
SourceForge ist auf jeden Fall ein gutes Stichwort, dass wir im Blick behalten sollten. Vielleicht sollten wir bei einer in die Entwicklung einigermaßen passenden Gelegenheit demnächst mal SourceForge anvisieren. Das hätte sicherlich was.
Hm... dann möchte ich hier die vielleicht "dumme" Frage aufwerfen: Was spricht dagegen, den Umzug bzw. Einstieg in SF gleich durchzuführen?

Martin