Moin Thorsten, Thorsten Behrens wrote:
> Moin Mathias, > > ich antworte mal selektiv auf $subject, mein erster Versuch auf > alles einzugehen wurde echt zu lang (und sollte vielleicht auch im > vorvorletzten Posting weiterdiskutiert werden). ;) > > Du schriebst: >> Thorsten Behrens wrote: >> > 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). >> >> 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. >> > Ok. > >> Ausnahmen werden im Release Status Meeting bzw. auf der "releases" Liste >> diskutiert und beschlossen. >> > Da gibt es kurze Dienstwege f"ur die einen & keine Reaktion f"ur die > anderen. Nein, dann hast du den Prozess nicht verstanden. "Keine Reaktion" bedeutet automatisch "accepted". *Das* ist der kurze Dienstweg, und der steht jedem offen. >> 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. >> > und >> Sicherlich entscheiden die Sun-Entwickler (oder deren Management) >> zunächst einmal darüber, was sie selbst programmieren, welche >> Schwerpunkte sie dabei setzen etc. >> > Qed, "ubrigens auch bzgl. der Bugauswahl oben. Die Frage war, welche > Entscheidungen allein in Hamburg getroffen werden. Erstmal ohne > Wertung. Nein, das beweist nur, dass Sun-Entwickler das tun, was Sun-Entwickler tun wollen, Novell-Entwickler das, was Novell-Entwickler wollen etc. Das klassische "scratch your own itch" eben. Mir ist nicht bekannt, dass das mit dem Gedanken eines freien Projekts unvereinbar wäre. Den Vorwurf, bei seiner Planung nicht vorher andere zu konsultieren, müsstest du dann auch dir und deinen Kollegen machen. Das würde ihn aus meiner Sicht nicht sinnvoller machen, aber wenigstens wäre das dann fair play. >> 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? >> > Und wer hat entschieden, dass jetzt endlich anzugehen? s.o.: "scratch your own itch"! *Wir* haben entschieden, dass *wir* das jetzt angehen, unter anderem auch gerade weil Leute uns aus verschiedenen Ecken der Community (Entwickler und Nicht-Entwickler) das als wichtige Themen ans Herz gelegt haben. Natürlich *auch*, weil wir selbst das wichtig finden. Das ist ja wohl nicht sehr überraschend. Auch mit dir und deinen Kollegen sind wir ja immer bzgl. Performance in Kontakt gewesen und sind es meines Wissens immer noch, solange von dieser Seite noch ein für uns erkennbares Interesse an Zusammenarbeit erkennbar ist. An Performance ist also schon seit Jahren was getan worden (auch von Michael z.B.), und "Neues UI" ist auch schon länger ein Thema, spätestens seitdem es das ux-Projekt gibt, das übrigens einen extrem hohen Anteil an Community-Beteiligung hat. Wo bitte siehst du hier fehlende "Konsultation der Community"? Neu ist eigentlich nur, dass wir statt wie in den vergangenen Jahren nicht mehr kleckern wollen, sondern klotzen. Wenn du uns das vorwerfen willst, sei's drum. Ich bin mir aber sicher, dass der überwiegende Teil der Community die Arbeit an Performance und neuem UI eher schätzen wird als einen docx-Export, den ja z.B. deine Kollegen implementieren (natürlich nach ausführlicher vorheriger Konsultation der Community, nehme ich an). Gut, aber lassen wir das mal dahin gestellt. Wo siehst du denn nun die Projekte, die die Community haben will, die aber aufgrund fehlender Konsultation nicht zustande kommen? >> 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. >> > Klar geh"ort das zusammen, wenn jemand nach "welche wichtigen > Entscheidungen trifft Sun allein" fragt. Und nein, bloss weil Dir > das Thema nicht passt, werde ich nicht aufh"oren, es anzusprechen. > :) Oh, du missverstehst mich! Du kannst es natürlich ansprechen, so oft du willst (hast du ja schon :-)). Aber eine "Anwärmung", sprich: eine Diskussion werde ich nicht mitmachen, weil das nicht meine Baustelle ist. Neue Argumente dazu sind ja auch eher nicht zu erwarten. >> Hier geht es ja darum, ob Sun in der täglichen Arbeit keine Beteiligung >> an Entscheidungen zulässt. Und das ist IMHO nicht richtig. >> > Wieder so eine die eigentliche Argumentation umschiffende Formulierung. > Die Frage war nicht, ob "uberhaupt, sondern *wo* keine Beteiligung > stattfindet. Gut, dann benenne es doch endlich einmal exakt. Und lege auch dar, dass das in den Fällen nicht einfach auf die Gründe zurückzuführen ist, die ich aufgezählt habe, sondern auf "böse Absicht" oder systematisches Defizit oder meinetwegen auch fehlende Sensibilität. > Ich kann mir bei mindestens zwei Mitgliedern des ESC nicht > vorstellen, dass sie der jetzigen Extension-Policy zugestimmt > h"atten, wenn sie gefragt worden w"aren. Also w"urde ich auch hier > qed sagen. Diese Policy ist aber schon im ESC vor über einem Jahr angesprochen worden. Wenn es den betreffenden zwei Mitgliedern so wichtig gewesen wäre, hätte man das schon längst diskutiert haben können. Es war nur leider so, dass zumindest eine der beiden vermutlich gemeinten Personen damals kein Interesse daran hatte. Ich vermute, dass du mit der zweiten Person dich selbst meinst. Du warst natürlich damals noch nicht dabei. > Wie schaffe ich es, dass Du (und andere) konstruktive Fragen, > Kritik, Vorschl"age etc. nicht als pers"onlichen Vorwurf oder als > Sun-Bashing verstehen? Es kann doch niemand ersthaft mit dem Verlauf > der Entwicklerbeteiligung zufrieden sein, verdammt nochmal! Und nach > "uber acht Jahren ist es f"ur mich offensichtlich, dass es mit > KleinKlein und Kommitee-hier-Kommitee da nicht weitergehen kann, > sondern es systemischer "Anderungen bedarf. Ich fasse deine *pauschalen* Vorwürfe als das auf, was sie sind: Pauschalitäten. Und damit kann ich nichts anfangen. Ich fühle mich auch nicht persönlich angegriffen, dazu müsste mich die Kritik ja treffen. Aber ich sehe sie als schädlich für das Projekt an, wenn sie so pauschal geäußert wird. Sie wird dann zur "self fulfilling prophecy", weil sie genau das erreichen wird, was sie vorgibt, verhindern zu wollen. Ich habe doch hoffentlich das Recht, Kritik zu entkräften, wenn ich der Meinung bin, dass sie (wie in vielen der von dir vorgebrachten Punkte) nicht zutrifft. Wenn ich mich dabei irre, können wir ja gerne weiterdiskutieren. Aber du solltest mein Insistieren auf das Aufzeigen von konkreten, unstrittigen Problemen nicht als Abwehrhaltung verstehen, sondern als Versuch der Klärung von IMHO zu pauschalen Vorwürfen. Konkrete, sachliche Kritik werde ich mir natürlich gerne anhören, und ich bin immer bereit, in den Bereichen, in denen ich etwas bewirken kann, auch Veränderungen mitzutragen oder zu initiieren. 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
