====== Entwicklerrichtlinien ======

  * Code wird sauber kommentiert
    * guter Code braucht keine Kommentare, aber ...
    * ... trotzdem sollte der Shit natürlich beim Darüberlesen verständlich sein.
  * geforkter und verbesserter Code wird upstream geschickt
    * in regelmäßigen Abständen Pull Requests!

===== Code =====

  * Code-[[http://de.wikipedia.org/wiki/Smell_%28Programmierung%29|Smells]] werden gefälligst vermieden, ihr n00bs.
  * **Einrückung** mit doppelten Leerzeichen
    * Die Tabulator-Taste ist böse!
    * bei bestehenden Projekten von Drittanbietern wird sich natürlich an deren Richtlinien gehalten, falls existent.
  * **Öffnende und schließende Klammern** werden nicht weggelassen!
    * auch nicht, wenn bspw. ein if-Statement aus nur einer Zeile besteht.
  * **Variablen** haben englische Namen, die aus mindestens drei Buchstaben bestehen.
    * der erste Buchstabe ist kleingeschrieben, jeder Wort//anfang// wird mit einem Großbuchstaben versehen
    * der Variablenname entspricht der Verwendung
      * Beispiel: <fc #FF0000><del>iKunde</del></fc> <fc #008000>customerID</fc>
    * Abkürzungen werden vermieden
      * Beispiel: <fc #FF0000><del>tblKd</del></fc> <fc #008000>customerTable</fc>

==== spezielle Dateien im Quellverzeichnis ====

=== DEVELOPMENT.wiki ===

  * Entwicklungs-Roadmap in chronologischer Reihenfolge (0.1, 0.1.2, 0.3, 1.0, ...)
  * Im Wurzelverzeichnis
  * Formatiert in DokuWiki-Syntax
  * beinhaltet Abschnitte //TODO// und //FIXME//
  * Beispiel [[org:development.wiki]]

=== CHANGELOG.wiki ===

  * wie DEVELOPMENT.wiki, nur umgekehrt chronologisch sortiert (..., 1.0, 0.3, 0.1.2, 0.1)
  * Beinhaltet auch einen Upgrade-Abschnitt für inkompatible API-Änderungen und Upgradehinweise
  * Beispiel [[org:changelog.wiki]]

=== README.wiki ===

  * natürlich auch formatiert in DokuWiki-Syntax
  * beinhaltet mehrere Abschnitte:
    - Beschreibung, was der Quellcode tut (evtl. Motivation)
    - Installationsanleitung
    - Adressen, bei denen man Hilfe bekommt (eMail, IRC, Jabber, ...)
    - Richtlinien zur Mitarbeit (wohin kommt mein verbesserter Code? Kann ich bezahlen, um Feature X zu bekommen?)
    - Liste der Leute, die zum Projekt beigetragen haben
    - Links zu Konkurrenzprojekten und Beschreibung, warum diese ein Haufen Scheiße sind
  * sollte nach Möglichkeit //vor// dem Quellcode geschrieben werden
  * Beispiel [[org:readme.wiki]]

=== LICENSE.txt ===

  * Ist wohl selbsterklärend
  * Kann auch nach der jeweiligen Lizenz (GPLv3.TXT, CC-BY-SA_4.TXT) benannt werden

==== Versionierung ====

Versionierung nach [[http://semver.org/|SemVer-Schema]], Zusammenfassung folgt:
  * Bei einer Versionsnummer **MAJOR.MINOR.PATCH** wird erhöht:
    * MAJOR, wenn man inkompatible API-Änderungen vornimmt
    * MINOR, wenn man Funktionalität in einer abwärtskompatiblen Art und Weise hinzufügt
    * PATCH, wenn man abwärtskompatible Bugfixes durchführt
  * Zusätzliche Labels für pre-Release und build-Metadaten sind als Suffix zum MAJOR.MINOR.PATCH-Format zu sehen.
    * Beispiel: 0.1.14-schnitzel

=== FAQ ===

  * Wie gehe ich mit **Revisionen in der 0.y.z-Entwicklungsphase** um?
    * am Einfachsten startet man mit 0.1.0 und erhöht die MINOR-Version für jedes Dev-Release.
  * Woher weiß ich, wann ich die **1.0.0** veröffentliche?
    * Wenn der Code in einer Produktivumgebung eingesetzt wird,
    * eine stabile API vorhanden ist
    * oder man sich über Abwärtskompatibilität Gedanken macht.

===== Präsentation =====

  * Jedes Projekt braucht eine Homepage!
  * Wir haben dev.crunchweb.org für Code, der noch nicht flügge ist.
  * Projekte sollten mit ihrem eindeutigen Namen als Subdomain von crunchweb.org angelegt werden