[Eisfair] Diskussionen wo führen: öffentlich vs. nichtöffentlich

[Christoph Schulz]

Hallo!

Alexander Dahl schrieb:

> Die Frage ist, warum man Dinge, die tatsächlich diskutiert werden,
> hinter verschlossenen Türen diskutiert werden, obwohl man sie genauso
> gut öffentlich diskutieren könnte.

Eigentlich kann ich mich gar nicht zu dem Thema äußern, da ich kein eisfair-
Entwickler bin. Aus dem, was ich aber bislang zu dem Thema gehört und 
gelesen habe, ziehe ich jedoch den Schluss, dass im eisfair-Projekt einer 
bestimmten Eigenschaft keine besonders hohe Priorität zugewiesen wird: der 
Nachvollziehbarkeit. Dieser Aspekt bildet zwar nur einen Teil der 
Argumentation von Alex, mir als Entwickler ist er in diesem Zusammenhang 
jedoch der bedeutendste.

Ich bin ein großer Freund von Nachvollziehbarkeit. Seit Jahren arbeite ich 
beim fli4l-Projekt mehr oder weniger unermüdlich daran, dass alles 
nachvollziehbar wird. Sei es, dass die Binärprogramme alle von *jedem* 
Entwickler "da draußen" gebaut werden können und exakt denen in den 
offiziellen Paketen gleichen (Reproduzierbarkeit; ein Ziel, das aus 
technischen Gründen nur zu 95% erreicht wurde). Sei es, dass jeder Commit 
bei fli4l nachvollziehbar einem oder mehreren Tickets zugeordnet ist und 
somit hinter jedem Commit nachvollziehbar ein Anwendungsfall, eine 
Fehlerkorrektur, ein Update oder ein technisch motivierter Umbau steht. Sei 
es, dass wir jeden NG/IRC-Nutzer dazu bewegen, für erkannte Probleme ein 
Ticket zu eröffnen (was nicht heißt, dass Layer-8-Probleme nicht regelmäßig 
auf kurzem Dienstweg per Chat aus dem Weg geräumt werden).

Dies hat unglaublich viele Vorteile. Wenn ein Fehler auftaucht, kann man 
genau nachvollziehen, wie dieser entstanden ist und was der motivierende 
Anwendungsfall für die (potentiell fehlerhafte) Änderung war. Mit Hilfe 
einer detaillierten Commit-Meldung kann auch die einzelne Änderung an sich 
nachvollzogen werden. Durch die Selbstverpflichtung, keine Commits ohne 
Tickets zu erlauben, gibt es auch keine "unmotivierten" Commits, bei denen 
man sich fragen muss, wieso weshalb warum das Ganze. Changelogs werden bei 
fli4l automatisiert aus den Tickets generiert, die einer bestimmten Version 
zugeordnet werden, da alle benötigten Informationen in den Tickets stecken.

Gerade das fehlende bzw. kaum genutzte Bug-Tracking-System unter eisfair hat 
Auswirkungen auf die Kommunikation, besonders zwischen Nutzer und 
Entwickler, aber auch zwischen den Entwicklern untereinander, denn es führt 
zwangsläufig dazu, dass Diskussionen zu einem Problem dem finalen Bugfix 
oder Feature auf der ML oder in der NG geführt und damit den Code-Änderungen 
nicht vernünftig zugeordnet werden können. Einzig durch den zeitlichen 
Zusammenhang ist es evtl. möglich, nach mehreren Jahren noch nachvollziehen 
zu können, warum eine Code-Änderung vorgenommen wurde -- wenn die Diskussion 
noch in irgendeinem Archiv steht und öffentlich ist. (Das fli4l-dev-Archiv 
ist beispielsweise nur intern, und geht auch nur bis Februar 2005.) Wenn die 
Diskussion dann auch noch auf einer nicht öffentlichen ML stattfindet, kann 
man die Nachvollziehbarkeit vergessen.

Hinzu kommen noch Besonderheiten wie das teilweise intransparente und nicht 
reproduzierbare Bauen von Programmen und/oder Kernel, was die 
Nachvollziehbarkeit erschwert bzw. unmöglich macht (das war zumindest so, 
als ich das letzte Mal davon hörte, und das ist schon ein, zwei Jahre her -- 
eventuell/hoffentlich ist dies inzwischen anders geworden).

Klar, wenn die Paket-Maintainer sich nie ändern, jahrelang die Pakete 
weiterentwickeln und über alles auch ohne Werkzeugunterstützung ins letzte 
Detail Bescheid wissen, dann braucht man das alles nicht unbedingt. Das mag 
bei eisfair so sein, bei anderen Projekten ist dies jedenfalls nicht so -- 
und auch bei eisfair wird es nicht auf ewig so weitergehen können, denn wir 
leben alle nicht ewig ;-) Und deshalb ist es in meinen Augen von Vorteil, 
Diskussionen so zu führen, dass man verstehen kann, warum sich ein Projekt 
wann wie weiterentwickelt hat. Und das kann man auch öffentlich machen, da 
bin ich mit Alex einer Meinung.

Ach ja, bevor jemand darauf hinweist: Natürlich ist mir bewusst, dass auch 
beim fli4l-Projekt nicht alles öffentlich diskutiert wird. Die dev-ML ist 
auch hier nicht öffentlich. Und das hat (natürlich) hauptsächlich 
historische Gründe. Ob und wenn ja, wann man die MLs öffentlich macht, 
sollte auch bei fli4l mal diskutiert werden. Das nächste Entwicklertreffen 
wäre ein geeignetes Forum hierfür, scheint mir.


Viele Grüße,
-- 
Christoph Schulz
[fli4l-Team]