Arktur:Teamrichtlinien 2

Archiv: Dieser Artikel beschreibt nicht die Funktionalität des derzeit aktuellen delixs-Servers. Er beschreibt ältere Schulserver-Funktionen und dient dem Zweck der Archivierung.

 Ursprünglicher Text: Erwin Flohr, 09dez03/08feb07

Arktur-Entwicklungsrichtlinien

(Fassung 8. Feb. 07)

1) Wir arbeiten im Team.

2) Es soll ein(e) Entwicklungsleiter(in) (Maintainer) für die jeweilige Server-Version aus dem Kreise der Beteiligten gewählt werden. Er/sie kümmert sich um die Zusammenarbeit im Gesamtüberblick, sowie um eine Darstellung der Arbeit und um eine Kooperation nach außen, sofern nicht einzelne Team-Mitglieder(innen) dies für Ihren Arbeitsbereich tun können.

3) Sobald der Fortgang der Entwicklungsergebnisse es erfordert, soll ein(e) unabhängige Qualitätsprüfer(in) mehrheitlich nominiert werden. Nach Möglichkeit gehört sie nicht zum Kreise der aktiven Versionsentwickler(innen). Ihre/seine Aufgabe ist es, neben allgemeinen Bemühungen um Qualitätssicherung, den Entwicklungs- und Beta-Test zu koordinieren und in Rücksprache mit der/dem Entwicklungsleiter(in) die Versionsfreigaben zu kontrollieren.

4) Die Entwicklungsarbeit erfolgt paketweise in einzelne Teilprojekte aufgeteilt. An jedem Teilprojekt kann eine Person oder eine kleine Gruppe selbstbestimmt arbeiten. In jedem Fall übernimmt genau eine Person gegenüber dem gesamten Arktur-Team die Verantwortung für das Teilprojekt. Alle Entwickler in Teilprojekten erhalten eine Zulassung für die gemeinsame Entwicklungsdatenbank (SVN).

5) Wir berücksichtigen die Rückwirkung unserer Arbeit auf die Arbeit anderer und versuchen daraus möglicherweise entstehende Probleme zu minimieren. Wir dokumentieren dazu unsere eigene Entwicklung und beobachten die Vorhaben und Produktionen der anderen.

6) Wir benachrichtigen alle Team-Kolleginnen und Kollegen möglichst frühzeitig von unseren Entwicklungsschritten, soweit wir davon ausgehen müssen, dass ihre eigenen Arbeiten von unseren Änderungen betroffen sein werden.

7) Sollten mehrere Entwickler(innen) am gleichen software-Teil arbeiten oder sollten sie dies beabsichtigen, so versuchen sie, ihre Arbeit als Teilprojekt zusammenzufassen. Ist das nur schlecht möglich, so versuchen sie die Arbeit in mehrere abgegrenzte Teile aufzuteilen. Ist das im Konsens nicht möglich, so bitten sie den/die Entwicklungsleiter(in) um Vorschläge zur Arbeitsorganisation.

8) Falls Arbeitsbereiche nicht einvernehmlich geregelt werden können, so soll der/die Entwicklungsleiter(in) über die Verkleinerung bzw. Aufteilung einer Teil-Arbeitsgruppe entscheiden. Dabei ist Rücksicht zu nehmen auf die Qualifikation und auf die Bereitschaft der einzelnen Personen, auch in anderen Bereichen mitzuarbeiten. Nach Möglichkeit geschieht die Veränderung also einvernehmlich.

9) Der Tätigkeit des/der Entwicklungsleiter(in) darf förmlich widersprochen werden. In diesem Fall gilt dessen/deren Entscheidung solange, bis die gesamte Gruppe sich beraten hat und eine mehrheitliche Entscheidung gefällt hat. Die Gruppe ist definiert durch die für die Entwicklungsdatenbank akkreditierten Personen. Ein Widerspruch soll allen Mitgliedern über die Entwicklungs-mailing-Liste, oder in anderer geeigneter Weise bekannt gemacht werden.

10) Es werden Regeln für die Nutzung des CVS-Entwicklungssystems und Konventionen zum Erstellen von Software code entwickelt, die dann allseitig beachtet werden müssen. Wenn die Arbeit es erfordert. sind sie, ebenso wie diese Entwicklungsrichtlinie, jederzeit veränderbar, Veränderung bedarf eines konkreten schriftlichen Vorschlages und des Konsens. Allgemeine Akzeptanz wird angenommen, wenn in angemessener Frist auf die Bekanntmachung keine Widersprüche erfolgten. Bei Problemen ist das Vorgehen entsprechend den Punkten sieben und Punkt neuen.

---

zurück