Moin,
Christoph Noack schrieb:
Hallo André!
André? Aaaandré? Ah gut, noch nicht weggerannt ;-)
Nee .. bin noch da. Musst nicht so schreien :)
...
Mir ist derzeit absolut unklar, wie - scheinbar - der Eindruck eines
fehlenden Problembewusstseins entstanden ist.
Ich denke nicht, dass bei dir Problembewusstsein fehlt - bei anderen schon.
Es sind halt verschiedene Diskussionen, die da zusammenspielen. Zum
einen das ewige "wir haben nicht genug Entwickler, also können wir nicht
alle Bugs fixen". Dann gab es vor ein paar Monaten hier noch die
Diskussion, ob wir als Projekt nicht ein grundsätzliches Problem haben,
neue Entwickler zu gewinnen. Grundtenor seitens Sun:nein, haben wir
nicht - wir müssen die vorhandenen Ressourcen nur besser einsetzen.
(shcon diese beiden Erkenntnisse sind mir in Kombination nicht
verständlich).
Dann hatte Nino Novak in der Vorbereitung des QA-WE's diverse Ideen
vorgestellt, wie man viele "neue" (und wahrscheinlich auch nur
kurzfristige) Helfer in der QA einspnnen könnte. Ich hatte das hier auf
der Liste kommentiert, warum das wahrscheinlich nicht funktionieren
wird. Stephan hatte diese Ideen begrüßt, und wollte sie sammeln und in
die Diskussion zum QA-We einbinden. Leider lag dort eher (zumindest habe
ich es so verstanden) der Fokus auf langfristiger Verantwortlichkeit.
Ins besonder im Bereich automatisierter QA werden im Moment Helfer
unterstützt, die sich langfristig um ein Thema kümmern und damit anderen
evtl. Arbeit ersparen ("Was einer macht, muss der andere nicht tun").
Was ist nun besser, wenn jemand mit neuen Ideen kommt? Die Idee
diskutieren und darauf hinweisen, dass das evtl. nicht geht oder erstmal
auf die Schulter klopfen, "tolle Idee" rufen und sie dann in der
Schublade verschwinden lassen?
....
Bezogen auf das aktuelle Beispiel "Bugfixing" ist es *vorher* schon
wichtig zu wissen was getan werden soll - und nicht danach zu
argumentieren. Wenn klar wäre, dass wir beispielsweise Studierende (die
im Gegensatz zu anderen MS-Produkten ein MS-Office heute noch nicht
kostenlos erhalten) als eine wichtige Zielgruppe haben, dann fallen mir
dazu zig wichtige Funktionen und Bugs ein. Sogar visuelle Attraktivität
wäre dann ein Thema...
Diese Betrachtung ist für die Entscheidung, in welchem Bereich
gearbeitet wird sicher wichtig. Aber nur begrenzt dafür, welche Bugs
gefixed werden sollen.
Wenn wir uns einmal entschieden haben, dass ein Feature in das Produkt
kommt, muss uns auch klar sein, dass wir diese pflegen müssen - und das
kontinuierlich. Wenn also entschiden wurde, dass OOo einen neuen
Serienbriefassistenten bekommt, sollten auch für das nächste Jahr noch
Ressourcen da sein, um Bugs zu fixen - und nicht geplanterweise eher
"unwichtige" Probleme bestehen lassen, so dass sie igendwann "zu alt" sind.
Das dumme mit Bugs ist, man kann nicht wirklich planen, wann sie
entdeckt werden. Das konzentrierte Fixen von Bugs in einem bestimmten
Bereich ist aus meiner Sicht sinnvoll und kann wahrscheinlich den Sumpf
der vorhandenen Fehlermeldungen massiv reduzieren. Lösen werden wir das
Problem aber nur, wenn uns klar ist, dass wir so einen Sumpf gar nicht
erst entstehen lassen dürfen (eine feuchte Wiese mit ein paar
Schlammlöchern hier und da wäre ok).
Mein Eindruck ist, dass Prioritäten bei Unternehmen manchmal sehr
schnell kippen - Dinge, die zeitweise wenig wichtig waren haben dann
eine sehr hohe Priorität. Als Freiwilliger mit zeitlich begrenzten (wenn
auch kontinuierlichem Zeitbudget) wird man teilweise von den sportlichen
Terminplänen überholt. Committed ja, sinnvoller Beitrag ... naja.
:) - wobei es eigentlich nicht zum lächeln ist.
Wobei es das auch andersrum gibt - was heute ganz wichtig ist, stirbt
dann kurz vor Ende doch noch. Z.B. ewiges Trauerspiel PIM / Kalender
z.B. - wie oft wurde ein Kalender für OOo angekündigt? Und wieviele
stabile (>= 1.0) Kalenderapplikationen haben wir jetzt, die wir
empfehlen können?
Interessant ist, dass ich bei meinem letzten Besuch bei Sun während
einiger Gespräche wahrgenommen habe, dass "neue Features" einen sehr
großen Stellenwert besitzen. Aus meiner Sicht ist das nicht mehr der
Knackpunkt, um sich von Wettbewerbern zu differenzieren bzw.
konkurrenzfähig zu sein.
Da gehe ich mit dir konform. Inzwischen zählt (imho) mehr, wie man mit
den vorhandenen Features umgehen kann. Was zum einen bedeuted, dass man
sie leicht finden und Spaß an der Arbeit hat - zum anderen, dass einem
dieser Spaß nicht durch "ein Bug hier, in Fehlerchen dort" verleidet wird.
Mir persönlich wären stabile und gut durchdachte Features, sowie eine
vollständige abgedeckte API und Dokumentation für die
Extension-Entwicklung viel lieber. Zu Letzterem: statt alles von wenigen
(sehr guten und sehr gut eingearbeiteten) Entwicklern machen zu lassen,
wäre ein vereinfachtes Beitragen außerhalb der Core wünschenswert.
Jepp - wobei dann in Kürze ein Problemeskaliert, was wir auch jetzt
schon haben: wie stellen wir die Qualität der Extensions sicher. Das ist
im Moment noch nichtmal für die Extensions geregelt, die im
OOo-Source-Repository liefern.
Das ist sehr schade zu hören - und das mag ich hier gar nicht
ausdiskutieren. Du bist mit auf dem LinuxTag, oder?
Sagen wir mal - ich bin auf der LinuxNacht .. und da ich das Geld eh
schon ausgegeben habe bin ich auch noch zwei Tage auf dem LinuxTag. ;)
Gruß,
André
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@de.openoffice.org
For additional commands, e-mail: dev-h...@de.openoffice.org
