Moin Thorsten, Thorsten Behrens wrote:
> Martin Hollmichel wrote: >> Thorsten Behrens wrote: >>> >>> [wichtige Entscheidungen werden in Hamburg getroffen] >>> >> von welchen grossen oder wichtigen Entscheidungen sprichst Du? Ich kenne >> diese nicht bzw. bin mir nicht diesen bewusst. Kannst Du Beispiele fuer >> Entscheidungen geben, die besser mit breiterer Beteiligung haetten >> getroffen werden sollen ? >> > Hi Martin, > > nun, es gibt diverse Bereiche, in denen Sun bisher die Community > garnicht konsultiert (immer AFAICT, ich lese auch nicht *alle* > Listen ;)), das ist z.B. alles, was mit Entwicklungsplanung zu tun > hat (welche Features, welche Bugs, Deadlines, Ausnahmen); welche > Platformen supported werden, welche Ports man macht (oder eben > nicht), Fokus der Entwicklung (Features vs. Bugs vs. Performance > vs. API vs. Dokumentation vs. Security). Tut mir leid, aber das stimmt nicht. Deadlines folgen dem Release Plan, der gemeinsam im ESC-Meeting vorgeschlagen, diskutiert und beschlossen wurde (und natürlich nicht in Stein gemeißelt ist). Und Änderungen der konkreten Termine werden im Release Status Meeting disktutiert. Ausnahmen werden im Release Status Meeting bzw. auf der "releases" Liste diskutiert und beschlossen. Welche Bugs in welchem Release gefixt werden, kannst du ganz einfach beeinflussen: fixe sie einfach. Niemand wird dich aufhalten. Oder überzeuge andere Entwickler davon, dass sie es tun, das sollen Leute schon geschafft haben. Aber erwarte nicht, dass andere deine Gedanken lesen und in vorauseilendem Gehorsam deine Lieblingsbug fixen. [Ich weiß, du hast das nicht (nur) auf dich selbst gemünzt, es schreibt sich aber besser in der ersten als in der dritten Person und die Botschaft ist ja die gleiche!] Nun zur Entwicklungsplanung und dem Fokus der Entwicklung, zu den Features, Plattformen etc. Sicherlich entscheiden die Sun-Entwickler (oder deren Management) zunächst einmal darüber, was sie selbst programmieren, welche Schwerpunkte sie dabei setzen etc. Das ist ja wohl bei anderen Entwicklern wie dir bei Novell nicht anders. Aber ich habe noch nie erlebt, dass von unserer Seite aus irgend jemand anderem vorgeschrieben wurde, was er tun oder nicht tun soll. Oder was meinst du hier? Wenn du natürlich meinst, dass deiner Meinung nach die von Sun bezahlten Entwickler nur das tun sollen, was andere wollen, am besten noch ohne dass diese dazu einen signifikanten Beitrag leisten: ja, in der Tat, diese "Beteiligung der Community" lehne ich ab. Ich kann dir aber genügend Beispiele liefern, wo wir auf Anfragen von anderen Entwicklern uns an deren Projekten beteiligt haben (zumindest beratender/helfenderweise, mit QA etc., aber auch mit Code-Beiträgen), wenn diese an uns herangetreten sind und uns um Hilfe gebeten haben. Um mal für mich zu sprechen: das Einzige, was ich verlange, ist Mitarbeit, dann bin ich auch immer dazu bereit, ebendiese von meiner Seite aus anzubieten. Man muss aber entsprechend mit - und mit uns zusammenarbeiten, damit das funktionieren kann. Und wie sieht es mit den aktuellen Zielen aus? Gerade Performance und UI sind Dauerbrenner in der Community, Forderungen, das endlich anzugehen, gibt es seit Jahren. Nun tun wir es, und zwar völlig transparent, unter ausgiebiger Beteiligung der Community - und dann ist das auch wieder falsch? Fazit: da bleibt IMHO nicht viel übrig. Du müsstest also schon etwas konkreter werden, wenn man mit deinen doch recht pauschalen Behauptungen etwas anfangen können soll. Ich will gar nicht bestreiten, dass es anekdotische Beispiele gibt, die diskussionswürdiges Verhalten zeigen, aber wie man daraus ein systematisches, gewolltes Abgrenzen konstruieren kann, ist mir schleierhaft. Noch besser wäre es natürlich, wir lassen die Vergangenheit ruhen und konzentrieren uns auf das, was wir in Zukunft sehen wollen: kannst du konkrete Beispiele nennen, wo du eine stärkere Beteiligung der Community sehen möchtest bzw. wo siehst du sie gefährdet? > Dann Dinge, bei denen AFAIK > mit Leuten aus der Community geredet wurde, Sun dann aber dennoch > gemacht hat, was es f"ur richtig hielt: Hosting des Projekts, SCA/ > Verfasstheit von OOo, Prozesse und deren Ausgestaltung, SCM-System, > Build-System (eigenes Inhouse-System, inkrementelles Bauen)... Bitte vermische hier nicht "SCA/Verfasstheit" mit den anderen Dingen, das gehört nicht zusammen. In der Tat ist Sun in diesem einen Punkt sehr fest - das Thema hatten wir aber schon oft genug und wir sollten das hier nicht wieder aufwärmen. Du thematisierst ja hier Sun's angebliches Fehlverhalten mit dem Hintergedanken, das zu benutzen, um die "Verfasstheit" des Projekts auszuhebeln. Indem du diese Verfasstheit selbst als Problemverhalten beschreibst, erzeugst du einen Beweis durch Behauptung. Hier geht es ja darum, ob Sun in der täglichen Arbeit keine Beteiligung an Entscheidungen zulässt. Und das ist IMHO nicht richtig. Natürlich ist hier nicht immer alles vorbildlich gelaufen, aber die grundsätzliche Bereitschaft, Prozesse etc. in Frage zu stellen, ist vorhanden und wurde auch z.B. auf diversen ESC-Meetings immer wieder deutlich gemacht. Leider war es dann, wenn dazu aufgefordert wurde, an der Umsetzung von entsprechenden Änderungen zu arbeiten oder zumindest einmal Vorschläge zu formulieren, immer recht schnell vorbei mit dem Engagement von anderen. Ich sehe nicht, dass wir an Prozesse etc. festhalten "just because", nur erwarten wir verständlicherweise, dass neue Prozesse auch unsere Requirements berücksichtigen, und dass Änderungen oder komplett neue Prozesse gemeinsam umgesetzt werden. Aber sicher, da gibt es noch viel zu verbessern. Nur liegt das nicht daran, dass es keine Offenheit und Bereitschaft gibt, sondern daran, dass das nicht so einfach ist, viel Arbeit erfordert, die nicht immer nur wir erledigen wollen, und - ja auch! - weil einige sich mit Veränderungen persönlich schwer tun. Das ist aber ein individuelles Problem und kein systematisches. >> Mir faellt zur Zeit gerade eine"groessere" Entscheidung ein: "Unter >> welchen Kriterien sollen/koennen extensions gebundlet werden ?". Das >> steht fuers naechste ESC meeting auf der agenda, >> > Und ich bin froh dar"uber. :) > > Andererseits macht das schon wieder ein "ahnlich gelagertes Problem > offensichtlich: die Extensions-Policy wurde faktisch initial bei Sun > gemacht, und jetzt m"ussen Leute aus der Community Zeit & Nerven > aufbringen, die ggf. im Nachhinein wieder zu "andern - ist nicht so > motivierend. Das ist wohl wahr, und es kostet auch uns/mich Zeit und Nerven. Aber das hat sicherlich vor allem etwas damit zu tun, wie das ESC funktioniert bzw. nicht funktioniert. Absicht ist das jedenfalls nicht. Du bist ja neuerdings im ESC, was mich sehr freut. Da sollten wir ja auch in Zukunft besser in der Lage sein, solche "nicht so motivierenden" Vorkommnisse zu vermeiden. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@de.openoffice.org For additional commands, e-mail: dev-h...@de.openoffice.org
