4.5 TestmethodikTop4.3 Technische Rahmenbedingungen4.4 Entwicklungsrichtlinien von OpenLayersInhaltsverzeichnisEnglish

4.4 Entwicklungsrichtlinien von OpenLayers

Das OpenLayers-Projekt definiert klare Enwicklungsrichtlinien:

Jede Person hat die Möglichkeit, einen gefundenen Fehler (Bug) oder einen neuen Erweiterungswunsch in das Ticket-System37 von OpenLayers einzutragen. Dabei sollen spezielle Regeln38 befolgt werden. Eine fertige Patchdatei39, die den Bug behebt oder das Feature implementiert, wird an das erstellte Ticket angefügt; der Ticketstatus wird auf review gesetzt. Über die Entwickler-Mailingliste sollte anschließend eine Zusammenfassung der implementierten Änderungen verschickt werden, die bei Bedarf diskutiert und ggf. noch einmal modifiziert werden können. Sind keine Änderungswünsche vorhanden, wird der Patch von einem oder mehreren autorisierten project committers geprüft, ggf. geändert und in die aktuelle SVN-Entwicklungsversion, den Trunk, integriert [OpenLayers c].

Registrierte Entwickler haben die Möglichkeit, sich ihre eigene SVN Sandbox für Test- und Demonstrationszwecke einzurichten. Jede Sandbox ist unabhängig vom Trunk. Entwickler haben innerhalb ihrer eigenen Sandbox alle Freiheiten und müssen keine Richtlinien befolgen.

Das Project Steering Committee (PSC) von OpenLayers besteht aktuell aus sieben Mitgliedern40. Sie überwachen den Projektablauf und versuchen, im Sinne der Community Entscheidungsprozesse voranzubringen. Bei wichtigen Entscheidungen - wenn z. B. substantielle Quellcodeänderungen vollzogen, die Rückwärtskompatibilität verändert, neue Veröffentlichungstermine entschieden oder Verfahrensfragen geklärt werden sollen - stimmen die PSC-Mitglieder darüber ab. Jede Person aus der OpenLayers-Community kann (über die Entwickler-Mailingliste) einen Antrag stellen oder diesen kommentieren; aber nur die Komitee-Mitglieder sind berechtigt zu votieren. Dabei gelten klare Abstimmungsregeln, die wie folgt zählen [OpenLayers e]:

+1
volle Unterstützung des Antrags; Bereitschaft zur aktiven Mitarbeit
+0
Unterstützung des Antrags; jedoch keine Bereitschaft zur Mitarbeit
 0
keine Meinung
-0
geringe Nichtübereinstimmung mit dem Antrag; jedoch keine Blockadehaltung
-1
Veto; Blockierung des Antrags

Ein Antrag ist angenommen, wenn die Gesamtsumme der Abstimmungsergebnisse mindestens +2 beträgt und keiner mit -1 stimmt. Bei einem Veto muss der Votierende eine klare Begründung geben und eine Alternative zum Lösen des Problems innerhalb von zwei Tagen vorschlagen. Bei Streitfragen entscheidet der Komitee-Vorsitzende [OpenLayers e].

Die Realisierung des animated zooming Features wird auf Grundlage der o. g. Entwicklungsrichtlinien durchgeführt. Regelmäßiges Kommunizieren bereitgestellter aktueller Zwischenversionen über die Developer-Mailingliste soll die OpenLayers-Community in den Entwicklungsprozess mit einbeziehen. Dadurch können frühzeitig vorgeschlagene Änderungen oder Ideen der Entwickler berücksichtigt werden. Diese Transparenz ermöglicht eine bestmögliche Akzeptanz des Features. An dieser Stelle sei betont, dass das animated zooming Feature die bestehende API erweitern wird und keine fundamentalen Änderungen an den Kernkomponenten von OpenLayers nötig sind. Ferner stellt die Begutachtung des Quellcodes durch andere Entwickler eine Qualitätssicherung dar.


© 1. Juni 2007, Emanuel Schütze, some rights reserved.
Diese Arbeit ist unter der Creative Commons Lizenz Namensnennung-Weitergabe unter gleichen Bedingungen 2.0 Deutschland lizensiert.

4.5 TestmethodikTop4.3 Technische Rahmenbedingungen4.4 Entwicklungsrichtlinien von OpenLayersInhaltsverzeichnisEnglish