Mithilfe am Classic Forum

Wie beinahe jedes OpenSource-Projekt sucht auch das Classic Forum immer Mitstreiter. Aktuell suche ich:

• Betatester. Es werden immer Tester gesucht, die das Forum auf Bugs untersuchen. Testen, wenn man die Software selber geschrieben hat, ist extrem schwer, deshalb ist es immer besser, wenn das fremde Leute machen. Wenn Sie also testen möchten, fühlen Sie sich wie zuhaus und melden sie etwaige Fehler im Bugtracker. Benötigen Fehler der Diskussion, schreiben sie an die Mailing-Liste.
• Dokumenteure. Es werden immer Leute gesucht, die das Forum dokumentieren. Programmierer eignen sich häufig schlecht zum Dokumentieren, da ihre Sicht auf die Dinge häufig beschränkt ist auf die rein technische. Dokumentiert wird hier mit LaTeX oder HTML, wobei das HTML dann per Script umgewandelt werden wird in LaTeX, so dass problemlos ein PDF daraus erstellt werden kann.

Zugriff auf das Repository bekommen Sie, wenn Sie eine gewisse Zeit aktiv am Projekt mitgearbeitet haben. Ich bitte um Verständnis, dass ich nicht jedem sofort vollen Zugriff erteilen kann.

Richtlinien des Classic Forums

Coding-Style

Beim Code des Classic Forums ist folgendes zu beachten:

• Die Einrückung passiert mit Leerzeichen. Pro Einrückungsstufe werden zwei Leerzeichen verwandt.
• Es werden keine Leerzeichen zwischen Schlüsselwort und Klammern gemacht. Es wird also statt if () besser if() geschrieben.
• Lange Zeilen werden nicht umgebrochen. Heutige Editoren bekommen es problemlos hin, lange Zeilen "virtuell" zu brechen, so dass es keinen Sinn macht, derartige Zeilen umzubrechen.
• Funktionen sollten möglichst performant realisiert werden. Performance ist ein wichtiges Ziel des Classic Forums.

Einspielen ins Repository

Es ist nicht wichtig, dass der Code, der ins Repository eingespielt wird, sauber funktioniert. Wichtiger ist, dass die Commits regelmäßig sind. Eine Zusammenarbeit mit einem Mitarbeiter, der nur sehr sporadisch seine Änderungen ins Repository einspielt, gestaltet sich als sehr schwierig, da es dabei zwangsläufig regelmäßig zu Konflikten beim commit kommen muss.

Tiefergehende Änderungen

Tiefergehende Änderungen müssen zuerst in der Mailing-Liste besprochen werden, um etwaige Nebenwirkungen abzuschätzen. Auf eigene Faust dürfen solche Änderungen nicht gemacht werden!