Skip to content

definitions.md

Latest commit

 

History

History
142 lines (116 loc) · 6.35 KB

definitions.md

File metadata and controls

142 lines (116 loc) · 6.35 KB

Coding Conventions     Branches     Issues     Documentation     Links    

Coding Conventions:

  • Favorisierter Einrückungsstil:
    coding_conventions01.jpg
  • Einrücken mit 4 Leerzeichen (nicht mit Tabulator).
  • Keine Leerzeichen am Ende einer Zeile.


Branches:

Unsere Branches unterteilen sich in die drei Stufen User, Collector und Projects / Developer.
(Beispiel)

1. User 2. Collector 3. Projects / Issues
master collector (default) upvote_buttons_for_non_pmo

Anpassungen sollten mit den Resourcen aus der Branch collector erfolgen.
Pull requests sollten in die Branch collector erfolgen.

1. User:

Hier gibt es genau eine Branch master. Sie enthält die aktuelle Version für die User und dient den Usern zum Abrufen neuer Versionen.

2. Collector:

Hier gibt es derzeit genau eine Branch collector. Sie dient als Sammler aller Bestandteile für eine Version vor der Auslieferung an die User, dem Transport in die Branch master.

Die Branch collector ist die standard (default) Branch. Sie wird beim Transportieren automatisch als Empfänger vorgeschlagen. Damit wird unter anderem sichergestellt, dass nicht aus Versehen in die Branch master transportiert wird.

Außerdem kann zeitunkritisch, auch gegebenenfalls aus mehreren Branches, in den collector transportiert werden, die Sammlung nachbearbeitet werden und auch ein Kompletttest durchgeführt werden, bevor die Sammlung als neue Version den Usern zur Verfügung gestellt wird.

3. Projects / Developer:

Diese Stufe soll Raum für unterschiedliche Projekte unterschiedlicher Entwickler bieten. Die Namen der Branches sollten aus einer allgemein verständlichen Bezeichnung für Projekt und Entwickler bestehen, den der Entwickler selbst bestimmen kann.

Issues:

Unter Issues finden wir die Tickets und das Ticketsystem. Ein Issue durchläuft bis zu seiner Schließung in der Regel mehrere Stationen. Die Aufgaben und die Einstellungen der Issues werden im Folgenden kurz erläutert.

Sprache: Englisch wo nötig, ansonsten auch deutsch.

  • Neues Issue:

    • Kategorie (Label) setzen: bug, enhancement, improvement, help wanted, question ...
    • Priorität (Label) setzen, zumindest wenn sie absehbar hoch ist.
      • Die Kategorie bug hat in der Regel mindestens die Priorität middle.
      • help wanted und question haben in der Regel nicht mehr als Priorität middle.
    • Handelt es sich um einen Wunsch der User, dann den Tag (Label) wish setzen.

  • Issue in Arbeit nehmen:

    • Issue einer Person zuordnen/assignen.
    • Status (Label) in progress setzen.

  • Issue zurück an User geben:

    • Aktion (Label) user action setzen.

  • Issue auf erledigt setzen:

    • Grob beschreiben, zu welchem Ergebnis man gekommen ist. (Beschreibung wird für Changelog verwendet.)
    • Entsprechenden Status (Label) setzen: fixed, completed, rejected ...

  • Issue schließen:

    • Sollen Objekte transportiert werden oder soll eine Dokumentation im Changelog erfolgen, dann Issue einem Milestone zuordnen.
    • Issue auf close setzen.


Documentation:

Es sollte eine aussagekräftige Dokumentation im Issue bzw. im Pull request erfolgen. (Dokumentation wird für Changelog verwendet.)

Eine Änderungsdokumentation im Programmcode ist nicht erforderlich. Bei komplexen Zusammenhängen oder wenn besondere Beachtung geboten ist, dann sollte eine Dokumentation an der entsprechenden Programmstelle erfolgen. Ob eine solche Dokumentation sinnvoll ist, entscheidet der jeweilige Entwickler.

Links:

GitHub:


Browser:


Foren:


Sonstiges: