Re: [de-dev] Re: Welche Entscheidungen in HH getroffen werden
Mathias Bauer wrote: Und die Aussage, Community habe in den Köpfen der Entwickler nur am Rande Platz empfinde ich sogar fast als dreist, wenn ich sehe, wie gerade die Kollegen direkt um mich herum arbeiten. Moin Mathias, zunachst einmal zitierst Du mich falsch, ich habe Entscheider und nicht Entwickler geschrieben. Und Du kannst sicher sein, dass ich das auch genau so gemeint habe, wir Entwickler sind namlich in der Regel sehr daran interessiert, dass unsere User (und die rekrutieren sich nunmal aus der Community) zufrieden sind. Den Rest, auch was Verstandnis und relative Wichtigkeit von Community angeht, wurde ich gerne anhand der Ausgangsmail diskutieren; ich versuche mich nachher mal an einer Zusammenfassung. Und insbesondere besteht für dich die Community in erster Linie aus Entwicklern, und weniger aus Anwendern. Sehe ich das richtig? Nein. Wie kommst Du darauf? Gruss, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@de.openoffice.org For additional commands, e-mail: dev-h...@de.openoffice.org
Re: [de-dev] Re: Welche Entscheidungen in HH getroffen werden
Mac/PPC ist eigentlich ein gutes Beispiel dafür, was die Community - auch in internationaler Zusammenarbeit - bewirken kann. Mechtilde (deutschsprachiger QA-AP) entschied auch die deutschsprachige Version dieses Ports zur 3.0 zu releasen. Sie rekrutierte entsprechende Tester, da sie selbst keinen Mac hat. Maho baute (auch) eine deutschsprachige Version dieses Ports. Nachdem die Tests zufriedenstellend verlaufen waren, wurde dieser Port seitens der deutschsprachigen Community (durch die QA-AP) freigegeben. Der zuständige SUN-Mitarbeiter hat dann ohne Zögern dafür gesorgt, dass die Mirrors entsprechend bestückt wurden. Offenbar war ein Bedarf für diesem Port auch woanders vorhanden, denn nach und nach wurde er auch für andere Sprachen veröffentlicht. Gruß Michael - To unsubscribe, e-mail: dev-unsubscr...@de.openoffice.org For additional commands, e-mail: dev-h...@de.openoffice.org
Re: [de-dev] Re: Welche Entscheidungen in HH getroffen werden
Thorsten Behrens wrote: Mathias Bauer wrote: Und die Aussage, Community habe in den Köpfen der Entwickler nur am Rande Platz empfinde ich sogar fast als dreist, wenn ich sehe, wie gerade die Kollegen direkt um mich herum arbeiten. Moin Mathias, zunachst einmal zitierst Du mich falsch, ich habe Entscheider und nicht Entwickler geschrieben. Und Du kannst sicher sein, dass ich das auch genau so gemeint habe, wir Entwickler sind namlich in der Regel sehr daran interessiert, dass unsere User (und die rekrutieren sich nunmal aus der Community) zufrieden sind. Den Rest, auch was Verstandnis und relative Wichtigkeit von Community angeht, wurde ich gerne anhand der Ausgangsmail diskutieren; ich versuche mich nachher mal an einer Zusammenfassung. Wenn in dieser das Gleiche steht wie in deiner Antwort an Martin, sehe ich nicht, wo uns das hinführen wird. Wenn du konkrete Punkte benennen kannst und Verbesserungsvorschläge dafür hast, bin ich gerne dabei. Gerade im Bereich Tooling und Prozesse gibt es ja auch noch eine Menge zu tun. Ich bin aber nicht dabei, wenn du zweifellos vorhandene Probleme mit den grundsätzlichen Diskussionen zusammenbringst, weil ich diesen Zusammenhang nicht sehe und IMHO das Aufladen der Diskussion mit politischen Inhalten einer Lösung der Probleme im Wege steht. Und insbesondere besteht für dich die Community in erster Linie aus Entwicklern, und weniger aus Anwendern. Sehe ich das richtig? Nein. Wie kommst Du darauf? War nur eine Frage. Ich versuche zu verstehen, was du meinen könntest. Irgendeinen Grund muss es ja dafür geben, dass wir identische Sachverhalte unterschiedlich bewerten. Aber gut, dass wir diesen Punkt geklärt haben. Ich frage mich dann nur, warum meine vielen Beispiele dafür, wo wir aktiv an der Einbeziehung der Community arbeiten, von dir komplett ignoriert werden, du selbst aber bisher außer deiner Maximalforderung (Sun-Entwickler sollen offensichtlich nicht entscheiden dürfen, was Sun-Entwickler machen) keine wirklich unstrittigen Beispiele lieferst. Also solche Dinge, wie Andre Schnabel sie benannt hat. Gut, dann frage ich eben explizit: - sind die von mir genannten Tätigkeiten (Entwickler-Support, Diskussionen auf MLs, in Issues, UX-Projekt etc.) keine aktive Einbeziehung der Community? - findest du es inakzeptabel, wenn Sun-Entwickler (oder Sun-Entscheider) nur einen Teil ihrer Arbeitszeit Aufgaben widmen, die sie nicht selbst bestimmen? Und warum macht ihr das dann nicht anders? Wo ist eure Community-Konsultation? - kannst du außer dem offensichtlich intransparenten Prozess der Showstopper-Behandlung noch andere Dinge, wo wir Verbesserungen vornehmen können? 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
Re: [de-dev] Re: Welche Entscheidungen in HH getroffen werden
Da ich nicht Mitglied des ESC bin (hierfür bin ich auch nicht hinreichend kompetent), hier meine Gedanken zu Sinn von Extentions: 1. Sie ermöglichen es jedermann, OOo an seine Bedürfnisse anzupassen (mit gewissen Beschränkungen natürlich), ohne in den Code von OOo selbst eingreifen zu müssen. Auf diese Weise können beispielsweise Business-Applikations und andere Anwendungen auf der Basis von OOo entwickelt werden. 2. Sie ermöglichen, eine Entwicklung außerhalb von OOo voranzutreiben. Beispiele sind für mich insoweit der Sun Report Builder und der pdf-Import. Diese Tools können als Extentions mit eigenem Entwicklungstempo vorangetrieben werden, bis sie reif für eine Integration in OOo selbst sind. 3. Sie ermöglichen es einzelnen Entwicklern aus der Community alternative Lösungen und Ergänzungen zu OOo aufzuzeigen. Wenn diese Lösungen als besser oder im Falle von Ergänzungen als sinnvoll empfunden werden (und die SCA-Frage geklärt ist), können sie in OOo integriert werden. Sie sind also eine Möglichkeit für Entwickler, OOo zu verbessern, ohne sich sich zunächst mit dem Code von OOo und den Entwicklungsprozessen auseinander setzen zu müssen. 4. Durch Extentions können OOo Funktionen hinzugefügt werden, die von vielen gewünscht, aber von den meisten nicht gebraucht werden. Gruß Michael - To unsubscribe, e-mail: dev-unsubscr...@de.openoffice.org For additional commands, e-mail: dev-h...@de.openoffice.org
Re: [de-dev] Re: Welche Entscheidungen in HH getroffen werden
Thorsten Behrens wrote: Mathias Bauer wrote: Und die Aussage, Community habe in den Köpfen der Entwickler nur am Rande Platz empfinde ich sogar fast als dreist, wenn ich sehe, wie gerade die Kollegen direkt um mich herum arbeiten. Moin Mathias, zunachst einmal zitierst Du mich falsch, ich habe Entscheider und nicht Entwickler geschrieben. Oops, sorry, man kommt nach so vielen Mails schon leicht durcheinander. :-) Du setzt dann aber voraus, dass Entscheider und Entwickler grundsätzlich unterschiedliche Personen sind. Das sehe ich nicht so. Wie ich schon schrieb, natürlich tun wir auch Dinge, die unsere Entscheider von uns fordern (das ist doch bei euch nicht anders, wie vor allem ein aktuelles Beispiel zeigt). Die Entscheider sind aber schlau genug, uns auch Spielraum zu lassen, wo Entwickler auch die Entscheider sind. Ich habe ja beschrieben, wie wir den ausfüllen, nicht zuletzt in Zusammenarbeit mit unterschiedlichen Teilen der Community. Es mag sein, dass so mancher Sun-Entscheider kein Bad in der Menge nimmt und alles demokratisch ausdiskutieren lässt. Aber gerade den aktuellen Entscheidungen (Performance/UI) kannst du nicht absprechen, dass sie aufgrund von Community Feedback und damit in derem Sinn getroffen wurden, das positive Echo, das wir erhalten, zeigt das ja auch. Für mich ist wichtig, ob am Ende von irgendjemanden die richtigen Themen besetzt werden. Ich habe diesbezüglich im Augenblick ein gutes Gewissen. Die Defizite der Vergangenheit (zum Beispiel bei OOo2.0, in dem IMHO z.B. der Punkt MSOffice-Migration doch etwas zu exzessiv ausgelegt wurde) sind mir wohlbekannt. Ich reklamiere aber für uns auch, dass wir gelernt haben. Was weitere Verbesserungen ja nicht ausschließt. 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
Re: [de-dev] Re: Welche Entscheidungen in HH getroffen werden
Hi Andre, *, On Tue, Jan 20, 2009 at 07:43:08PM +0100, André Schnabel wrote: ihr macht ja hier wieder einen Monster-Thread ... ;) Ich glaub', ich muss mal - wenn ich irgendwann mal Zeit dafuer habe - die verschiedenen Mailarchive der von mir nicht abonnierten MLs durchforsten ... Da tun sich ja Abgruende auf ... ;) Nur mal kurz: Mathias Bauer schrieb: schnipp der Begründung Sund baut das nicht ignoriert werden. Auch in Werkzeugen, die von Sun zur Verfügung gestellt werden fehlen einfach entsprechende Bereiche (ich beziehe mich hier auf QA, wo weder in Quaste noch in TCM entsprechende Plattformen verfügbar sin. QUASTe ist dabei noch nicht das wirkliche Problem, denn es ist open source, im gegensatz zu TCM). Ist denn (beim TCM zumindest, da ich ja hoechstens manuell teste ... ;) ) da was seitens SUN geplant, dass die Tests fuer die verschiedenen Architekturen angegangen werden koennen? schnipp Ich fasse deine *pauschalen* Vorwürfe als das auf, was sie sind: Pauschalitäten. Dann mal von mir ein paar Beispiele - keine großen Sachen (bis auf die letzte), die es aber manchmal schwer machen, die Fahne für Sun hochzuhalten. Wir hatten arge Startprobleme mit dem Lokalisierungsprozess, zu dem wir mehr oder weniger gezwungen wurden, weil Sun ihn so für Deutsch aufgesetzt hat, obwohl wir vorher explizit erklärt hatten wir wollen nicht mit Pootle arbeiten. Das hat insbesondere in den ersten Übersetzungsrunden dazu geführt, dass diejenigen, die bei uns die Übersetzer betreuen selbst mit massiven Probleme zu kämpfen hatten, wodurch extreme Verzögerungen entstanden. Nachdem wir im direkten Gespräch nochmal darauf hingewiesen haben und auch darauf, dass einige Zeitfenster im Prozess einfach zu eng sind bekommt man dann die Antwort würden wir das an einen externen Vendor geben, hätte der sogar noch weniger Zeit zur Verfügung. So eine Antwort motiviert extrem - insbesondere dazu, in der nächsten Rund die Übersetzer wieder anzuspornen, dass die Arbeit trotz knappen Zeitrahmens machbar ist (Gruß an Thomas ;) ). Besonders, weil wir ja unentgeltlich in unserer Freizeit uebersetzen, wohingegen die Externen ja - so weit ich das gehoert hatte - recht gut bezahlt fuer werden. Und wir muessen ja fuer unseren Lebensunterhalt neben der Uebersetzung dann ja noch arbeiten gehen ... :( Ach ja: Gruss zurueck ... ;) Was mich persönlich in dem Bereich besonders stört, ist dass unsere direkte Ansprechpartnerin für die deutsche Lokalisierung bei Sun sich nie wirklich am Community-Prozess beteiligt hat. Mal angenommen, die zwei Community-Mitglieder, die regelmäßig die Lokalisierung hier betreuen fallen weg - Sun wäre nicht in der Lage, diesen wieder zum Laufen zu bekommen (und müsste wieder ein Übersetzungsbüro beauftragen). +1 ... Das fand ich auch ziemlich stoerend, dass von der Seite eher nie, selten oder verspaetet Feedback kam ... :( Bis dann Thomas. schnipp -- Espy_on_crack I installed 'Linux 6.1', doesn't that make me a unix guru? BenC Espy_on_crack: no, you have to install it twice before you are a guru...once to prove you can do it, the second to fix the things your broke the first time Espy_on_crack oh right, how silly of me - To unsubscribe, e-mail: dev-unsubscr...@de.openoffice.org For additional commands, e-mail: dev-h...@de.openoffice.org
Re: [de-dev] Re: Welche Entscheidungen in HH getroffen werden
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 fur die einen keine Reaktion fur 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 gehort das zusammen, wenn jemand nach welche wichtigen Entscheidungen trifft Sun allein fragt. Und nein, bloss weil Dir das Thema nicht passt, werde ich nicht aufhoren, 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
Re: [de-dev] Re: Welche Entscheidungen in HH getroffen werden
Mathias Bauer wrote: Ausnahmen werden im Release Status Meeting bzw. auf der releases Liste diskutiert und beschlossen. Da gibt es kurze Dienstwege fur die einen keine Reaktion fur 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. Moin Mathias, hm, und was ist der Timeout? ;) Abgesehen davon ist in dem Licht der Thread unterhalb dieses Postings dann eher unerklarlich: http://www.openoffice.org/servlets/ReadMsg?list=releasesmsgNo=12910 [Grunde, warum Sun in den genannten Bereichen selbst entscheidet] Mathias, das einzige was ich hier mache, ist Beispiele aufzahlen, wo HH entscheidet. Und bis auf Release-Planung und evtl. Extension-Policy hast Du noch kein einziges Beispiel davon entkraftet. Den Vorwurf, bei seiner Planung nicht vorher andere zu konsultieren, muesstest du dann auch dir und deinen Kollegen machen. Das wuerde ihn aus meiner Sicht nicht sinnvoller machen, aber wenigstens waere das dann fair play. Woher weisst Du, dass ich das nicht mache? Und uber die Sinnhaftigkeit wurde ich wirklich gerne anhand meiner Ausgangsmail diskutieren, wenn wir uns mal endlich einig sind, *dass* es einen ganzen Haufen Dinge gibt, die Sun alleine entscheidet. 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. *Seufz* - verstehst Du nicht meinen Ausgangspunkt? Irgendjemand hat jetzt entschieden, dass Performance wichtig ist, und alle klotzen ran. Das ist toll! Aber das ist eine interne Entscheidung, vielleicht hatte die Community, so sie denn gefragt worden ware, das schon nach der 2.0 gemacht? Ich bewerte das hier ja garnicht, sondern ich stelle nur fest. Alles andere bitte anhand der Ausgangsmail. 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 Faellen nicht einfach auf die Gruende zurueckzufuehren ist, die ich aufgezaehlt habe, sondern auf boese Absicht oder systematisches Defizit oder meinetwegen auch fehlende Sensibilitaet. Warum sollte ich das (hier) tun? Es ging aussschliesslich um das wo. Wenn wir uns da einig sind, werde ich versuchen, konstruktiv zu erklaren, warum das eine oder andere vielleicht Mitglieder der Community demotiviert hat. [Extension-Policy im ESC besprochen oder nicht] Diese Policy ist aber schon im ESC vor ueber einem Jahr angesprochen worden Ok, war ich nicht dabei. Hatte nur gedacht, das Michael Rene sich da vorher schon quergestellt hatten. [wie kann ich Kritik uben, die als konstruktiv angenommen wird] Ich fasse deine *pauschalen* Vorwürfe als das auf, was sie sind: Pauschalitaeten. Ich kann Dir nicht folgen. Ich habe doch diverse Beispiele genannt, wie konkret willst Du es denn noch haben? Es geht in diesem Teilthread um Beispiele, wo HH entscheidet, was wann wie gemacht wird. Ich habe dazu hier keine Folgerung gezogen, noch irgendwas bewertet. Aber du solltest mein Insistieren auf das Aufzeigen von konkreten, unstrittigen Problemen nicht als Abwehrhaltung verstehen, sondern als Versuch der Klaerung von IMHO zu pauschalen Vorwuerfen. Ok, dann bin ich beruhigt. :) Viele Grusse, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@de.openoffice.org For additional commands, e-mail: dev-h...@de.openoffice.org
Re: [de-dev] Re: Welche Entscheidungen in HH getroffen werden
Hi, Mathias Bauer schrieb: ... 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. Mit dem Konzept eines freien Projektes nicht. Allerdings mit dem Konstrukt, welche OOo im Moment ist, bzw. sein will: ... eine internationale Gemeinschaft von Freiwilligen und Sponsoren, allen voran Gründungsmitglied und Hauptsponsor Sun Microsystems. (So der Abbinder jeder offiziellen Meldung des OOo-Projektes). An ein derart exponiertes Mitglied, welches allen voran steht habe ich durchaus den Anspruch, dass es mehr tut, als ein Sun-Entwickler will. Nur das zu tun, was man will hat wenig mit Zusammenarbeit im Sinne einer Community zu tun und sollte auf ein führendes Mitglied nicht zutreffen. Je größer die Beiträge zum Projekt sind, desto größer auch der Einfluss im Projekt - das ist nur natürlich. Gleichzeitig wächst aber auch die Verantwortung für das Gelingen des Projektes und die Entwicklung der Community. Letzteres ist aber nur selten spürbar. Zur Verantwortung für das Gesamtprojekt gehört auch, Prozesse so zu leben, dass sie für alle passen. Da geht es halt nicht an, dass build-Fehler auf Mac PPC oder Linux 64bit (gar nicht zu erwähnen die diversen Ports, die existieren und durchaus funktionieren, sich aber nicht wirklich für eine enge Zusammenarbeit mit OOo interessieren) mit der Begründung Sund baut das nicht ignoriert werden. Auch in Werkzeugen, die von Sun zur Verfügung gestellt werden fehlen einfach entsprechende Bereiche (ich beziehe mich hier auf QA, wo weder in Quaste noch in TCM entsprechende Plattformen verfügbar sin. QUASTe ist dabei noch nicht das wirkliche Problem, denn es ist open source, im gegensatz zu TCM). 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. Das ist allerdings vollkommen korrekt. 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. Allerdings ist es auch praktisch unmöglich, mit denjenigen direkt zu diskutieren, deren Baustelle das ist. Nochmal zum Spruch von oben: Sun-Entwickler machen was Sun-Entwickler wollen passt nicht mit dem Anspruch zusammen und Sun bekommt die Rechte an allem. Aber ok - nicht deine Baustelle. Ich fasse deine *pauschalen* Vorwürfe als das auf, was sie sind: Pauschalitäten. Dann mal von mir ein paar Beispiele - keine großen Sachen (bis auf die letzte), die es aber manchmal schwer machen, die Fahne für Sun hochzuhalten. Wir hatten arge Startprobleme mit dem Lokalisierungsprozess, zu dem wir mehr oder weniger gezwungen wurden, weil Sun ihn so für Deutsch aufgesetzt hat, obwohl wir vorher explizit erklärt hatten wir wollen nicht mit Pootle arbeiten. Das hat insbesondere in den ersten Übersetzungsrunden dazu geführt, dass diejenigen, die bei uns die Übersetzer betreuen selbst mit massiven Probleme zu kämpfen hatten, wodurch extreme Verzögerungen entstanden. Nachdem wir im direkten Gespräch nochmal darauf hingewiesen haben und auch darauf, dass einige Zeitfenster im Prozess einfach zu eng sind bekommt man dann die Antwort würden wir das an einen externen Vendor geben, hätte der sogar noch weniger Zeit zur Verfügung. So eine Antwort motiviert extrem - insbesondere dazu, in der nächsten Rund die Übersetzer wieder anzuspornen, dass die Arbeit trotz knappen Zeitrahmens machbar ist (Gruß an Thomas ;) ). Was mich persönlich in dem Bereich besonders stört, ist dass unsere direkte Ansprechpartnerin für die deutsche Lokalisierung bei Sun sich nie wirklich am Community-Prozess beteiligt hat. Mal angenommen, die zwei Community-Mitglieder, die regelmäßig die Lokalisierung hier betreuen fallen weg - Sun wäre nicht in der Lage, diesen wieder zum Laufen zu bekommen (und müsste wieder ein Übersetzungsbüro beauftragen). Die Entscheidung über Bugs und Features, die integriert werden, ist leider nicht ganz so Sun-unabhängig, wie es oft dargestellt wird. Wir haben einen recht restriktiven CWS-Prozess, mit sehr ausgeprägter Qualitätssicherung. An und für sich ok. Das Problem ist allerdings, dass es ausserhalb Sun nahezu unmöglich ist, diesen korrekt zu befolgen. Es wird hier viel Wert auf umfangreiche automatische Tests gelegt, um Regressionen zu vermeiden. Allerdings müssen diese Tests unter wohldefinierten Bedingungen erfolgen, um überhaupt aussagekräftig zu sein. Testergebnisse sind in der Regel nur mit Tests aus einem Sun-Build vergleichbar. Für die Community sind aber builds von buildbots der einzig sinnvolle weg für CWS-Tests. D.h. im Moment haben wir
Re: [de-dev] Re: Welche Entscheidungen in HH getroffen werden
Moin Thorsten, Thorsten Behrens wrote: Mathias Bauer wrote: Ausnahmen werden im Release Status Meeting bzw. auf der releases Liste diskutiert und beschlossen. Da gibt es kurze Dienstwege fur die einen keine Reaktion fur 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. Moin Mathias, hm, und was ist der Timeout? ;) Den gibt es in der Tat, ist mir aber momentan nicht momentan. Andre weiß das vielleicht. Abgesehen davon ist in dem Licht der Thread unterhalb dieses Postings dann eher unerklarlich: http://www.openoffice.org/servlets/ReadMsg?list=releasesmsgNo=12910 Nun, inhaltlich kann ich da nichts beisteuern. Es sieht aber so aus, als wäre die Diskussion da irgendwie im Sande verlaufen. Vielleicht müsste man das etwas formaler gestalten. Ich könnte mir vorstellen, dass bei Kontroversen innerhalb einer bestimmten Frist eine Entscheidung herbeigeführt werden muss, natürlich in einem offenen Prozess, z.B. im Release Status Meeting. Bisher hängt es AFAIK davon ab, ob jemand den jeweiligen Issues dort explizit zur Sprache bringt. Diese Anekdote ändert aber nichts daran, dass jeder hier die gleichen Möglichkeiten bzw. Probleme hat. Ich sehe hier kein Sun-Privileg. Natürlich weiß ich nicht, ob es nicht Entwickler gibt (ob in Hamburg oder anderswo), der irgendwelche Code-Änderungen reinschummelt. ;-) [Grunde, warum Sun in den genannten Bereichen selbst entscheidet] Mathias, das einzige was ich hier mache, ist Beispiele aufzahlen, wo HH entscheidet. Und bis auf Release-Planung und evtl. Extension-Policy hast Du noch kein einziges Beispiel davon entkraftet. Sehe ich anders - bisher hast du nur Beispiele aufgezählt, wo Hamburg entscheidet, was Hamburg macht. Das finde ich immer noch nicht sonderlich spektakulär. Und ich sehe es als das Recht jedes Entwicklers an, dass er seinen eigenen Prioritäten folgt. Im Gegensatz zu anderen Entwicklern (nicht Hamburg) arbeiten wir ja immer noch auch an anderen Themen, und zwar durchaus basierend auf Community-Input. Gerade hier auf der Liste sollte man eigentlich wissen, dass wir oft Probleme miteinander diskutiert oder auch explizit um Feedback gebeten haben, gemeinsam an Bugs oder Specs gearbeitet haben etc. Das würde ich mir von anderen Entwicklern auch mal wünschen, dann wären wir schon einen Schritt weiter. So lange du diesen Punkt immer ignorierst, ist eine weitere Diskussion nicht besonders hilfreich. Gut, dann benenne es doch endlich einmal exakt. Und lege auch dar, dass das in den Faellen nicht einfach auf die Gruende zurueckzufuehren ist, die ich aufgezaehlt habe, sondern auf boese Absicht oder systematisches Defizit oder meinetwegen auch fehlende Sensibilitaet. Warum sollte ich das (hier) tun? Es ging aussschliesslich um das wo. Wenn wir uns da einig sind, werde ich versuchen, konstruktiv zu erklaren, warum das eine oder andere vielleicht Mitglieder der Community demotiviert hat. OK, das war in der Tat eine nicht-zielführende Frage. Dann frage ich das mal anders: wie stellst du dir vor, wie die Community denn in Planung etc. einbezogen werden soll? Nehmen wir ein konkretes Beispiel. Ich überlege mir gerade, welche Themen ich der Community für die nächsten 3.x-Releases vorschlagen will (beginnend mit 3.2), neben den langfristigen Schwerpunkten Performance und UI. Wie würdest du das machen? Und wie würdest du vor allem die Entscheidungsfindung machen? [Extension-Policy im ESC besprochen oder nicht] Diese Policy ist aber schon im ESC vor ueber einem Jahr angesprochen worden Ok, war ich nicht dabei. Hatte nur gedacht, das Michael Rene sich da vorher schon quergestellt hatten. Rene war da IIRC ziemlich indifferent. Und Michael war an Extensions zunächst gar nicht interessiert. Dann hat er es sich angesehen, musste sich dann aber auf der d...@extensions Liste erklären lassen, dass er mit Extensions nicht sein offensichtliches Ziel erreichen konnte, StarOffice-Anwender von ihrer Nutzung auszuschließen, da das eine Verletzung der fundamentalen Rechte der LGPL gewesen wäre (non discriminatory use). Daraufhin hat er sich zu Extensions erst einmal lange nicht geäußert. Hier mal ein Zitat von seinem Ausgangsposting auf der Liste: -- I was wondering if, during the development of the extension work, any thought has been given to tainting issues. eg. it seems entirely likely that some people would want to write their extensions using the GPL, or commercial software incompatible extensions. Will there be some license/license tag in some manifest that will allow these to be filtered out for proprietary products ? -- Wenn er jetzt seine Einstellung dazu geändert hat, finde ich das prima. Ich denke aber, dass wir alles weitere zu diesem Thema im ESC-Meeting
Re: [de-dev] Re: Welche Entscheidungen in HH getroffen werden
Moin André, André Schnabel wrote: Hi, Mathias Bauer schrieb: ... 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. Mit dem Konzept eines freien Projektes nicht. Allerdings mit dem Konstrukt, welche OOo im Moment ist, bzw. sein will: ... eine internationale Gemeinschaft von Freiwilligen und Sponsoren, allen voran Gründungsmitglied und Hauptsponsor Sun Microsystems. (So der Abbinder jeder offiziellen Meldung des OOo-Projektes). An ein derart exponiertes Mitglied, welches allen voran steht habe ich durchaus den Anspruch, dass es mehr tut, als ein Sun-Entwickler will. Das tun wir ja auch. Wenn du darüber diskutieren willst, wieviel wir denn verplant haben und wieviel Zeit ich z.B. als Project Lead frei verteilen kann: da müsste ich jetzt allerdings die Antwort schuldig bleiben, das habe ich mir nie ausgerechnet. Zur Verantwortung für das Gesamtprojekt gehört auch, Prozesse so zu leben, dass sie für alle passen. Da geht es halt nicht an, dass build-Fehler auf Mac PPC oder Linux 64bit (gar nicht zu erwähnen die diversen Ports, die existieren und durchaus funktionieren, sich aber nicht wirklich für eine enge Zusammenarbeit mit OOo interessieren) mit der Begründung Sund baut das nicht ignoriert werden. Auch in Werkzeugen, die von Sun zur Verfügung gestellt werden fehlen einfach entsprechende Bereiche (ich beziehe mich hier auf QA, wo weder in Quaste noch in TCM entsprechende Plattformen verfügbar sin. QUASTe ist dabei noch nicht das wirkliche Problem, denn es ist open source, im gegensatz zu TCM). Das sind viele gute Punkte, und wir beide wissen, dass da nicht alles so läuft, wie du und ich uns das wünschen. Wir müssen aber vorsichtig sein: es ist IMHO nicht die Verpflichtung eines Projekt, jeder auch noch so kleinen Verästelung hinterherzulaufen, das würde das Projekt töten. Du sprichst z.B. Ports an. Das ist ein schwieriges Thema. Ich hoffe, dass du es akzeptabel finden kannst, dass man nicht jeden exotischen Port aktiv durch Coden unterstützen muss, aber ich stimme zu, dass ein lauffähiger Port auch irgendwie nicht absichtlich oder leichtfertig gebrochen werden sollte. Da haben wir sicherlich Verbesserungsbedarf. Nur sollten unsere Aktivitäten um Build Bots, Tinderboxen etc. aber auch zeigen, dass wir uns wirklich darum bemühen. Du kannst uns also Fehler vorwerfen, aber nicht Ignoranz. Entwickler in Hamburg sind durchaus angewiesen, den Tinderbox-Status ihrer CWS zu checken und darin aufgetretene Probleme zu fixen. Nur haben wir viel zu wenig davon (und IMHO sind da auch die aufgerufen, die ein Interesse daran haben) und leider funktionieren die vorhandenen allzu oft nicht. Der Frust, den du z.B. mit dysfunktionalen Testwerkzeugen erlebst, kann jeder Entwickler also durchaus in anderer Form nachvollziehen. Es macht keinen Spaß, Build-Fehlern hinterherzulaufen, die sich dann am Ende als ein Problem des Bots herausstellen. Verbesserungsvorschläge dazu werden gerne genommen. Sollten wir selbst uns mehr darum bemühen? Vielleicht. Brauchen wir da Unterstützung? Auf jeden Fall! Auch deine Kritik an dem einen oder anderen Werkzeug finde ich verständlich. Wenn du Verbesserungsvorschläge hast, findest du nicht nur in mir sicherlich einen Verbündeten. Ich finde aber nicht, dass man das so formulieren soll, Sun soll das gefälligst fixen - das passt irgendwie nicht zu Sun soll nicht alles kontrollieren. Aber natürlich müsste man einen Weg finden, wie man das gemeinsam löst. Das erfordert also Mitarbeit von denen, die es interessiert. Das Thema QA hast du ja weiter unten noch einmal am Wickel. Wir hatten arge Startprobleme mit dem Lokalisierungsprozess, zu dem wir mehr oder weniger gezwungen wurden, weil Sun ihn so für Deutsch aufgesetzt hat, obwohl wir vorher explizit erklärt hatten wir wollen nicht mit Pootle arbeiten. Das hat insbesondere in den ersten Übersetzungsrunden dazu geführt, dass diejenigen, die bei uns die Übersetzer betreuen selbst mit massiven Probleme zu kämpfen hatten, wodurch extreme Verzögerungen entstanden. Nachdem wir im direkten Gespräch nochmal darauf hingewiesen haben und auch darauf, dass einige Zeitfenster im Prozess einfach zu eng sind bekommt man dann die Antwort würden wir das an einen externen Vendor geben, hätte der sogar noch weniger Zeit zur Verfügung. So eine Antwort motiviert extrem - insbesondere dazu, in der nächsten Rund die Übersetzer wieder anzuspornen, dass die Arbeit trotz knappen Zeitrahmens machbar ist (Gruß an Thomas ;) ). Ich bin kein Experte, finde es aber auch seltsam, dass man die Wahl des Toolings nicht offen gestaltet hat. Ich werde das daher gerne mal im ESC zur Sprache bringen. Wenn ich dazu noch Input brauche, weiß ich ja, an wen ich mich wenden kann. ;-) Ich hoffe
Re: [de-dev] Re: Welche Entscheidungen in HH getroffen werden
Hi, Thorsten Behrens wrote: [Extension-Policy im ESC besprochen oder nicht] Diese Policy ist aber schon im ESC vor ueber einem Jahr angesprochen worden Ok, war ich nicht dabei. Hatte nur gedacht, das Michael Rene sich da vorher schon quergestellt hatten. Welche Extension policy? Und je nachdem was genau gemeint ist habe ich mich dagegen ausgesprochen (iirc war Michael in dem Meeting entweder gerade or gar nicht da) Grüße, Rene - To unsubscribe, e-mail: dev-unsubscr...@de.openoffice.org For additional commands, e-mail: dev-h...@de.openoffice.org
Re: [de-dev] Re: Welche Entscheidungen in HH getroffen werden
Mathias Bauer wrote: [Extension-Policy im ESC besprochen oder nicht] Diese Policy ist aber schon im ESC vor ueber einem Jahr angesprochen worden Ok, war ich nicht dabei. Hatte nur gedacht, das Michael Rene sich da vorher schon quergestellt hatten. Rene war da IIRC ziemlich indifferent. Und Michael war an Extensions Vielleicht am Anfang. Zwischendurch habe ich immer wieder angesprochen, dass der extension-wildwuchs aufhören sollte undsachen die in den core gehören da rein sollten (presenter console, ...) Grüße, Rene - To unsubscribe, e-mail: dev-unsubscr...@de.openoffice.org For additional commands, e-mail: dev-h...@de.openoffice.org
Re: [de-dev] Re: Welche Entscheidungen in HH getroffen werden
Mathias Bauer wrote: Du sprichst z.B. Ports an. Das ist ein schwieriges Thema. Ich hoffe, dass du es akzeptabel finden kannst, dass man nicht jeden exotischen Port aktiv durch Coden unterstützen muss, aber ich stimme zu, dass ein korrekt. Linux/64bit ist aber keinesweks exotisch. Oder Mac PPC. (ok, das ist - inzwischen - ein wenig exotischer, aber auch nur bei Leuten, die ihre alten iBooks/PowerBooks/MacMinis/... Hardware bereits auf Intel-Macs getauscht haben Grüße, Rene - To unsubscribe, e-mail: dev-unsubscr...@de.openoffice.org For additional commands, e-mail: dev-h...@de.openoffice.org
Re: [de-dev] Re: Welche Entscheidungen in HH getroffen werden
Moin, Mathias Bauer schrieb: ... Ich habe jetzt nicht die genaue Zahl der Project Leads und wieviele davon Sunnies sind - es erscheint mir aber arg übertrieben zu behaupten, dass Projektleiter zunächst immer Sunnies sind. Klar, die Gründungsprojekte sind zunächst mit Sunnies besetzt worden, und daran hat sich meines Wissens nach bis heute auch nichts geändert. Ich verstehe das, ich kann mich auch nur schwer davon trennen. ;-) Wir haben aber neben den NL-Projekten auch noch ein paar weitere, die nicht von Sun-Mitarbeitern geführt werden: Extensions, Bibliographie, Lingucomponent, Documentation, Marketing, Website, sowie die Incubator-Projekte, Ich hatte mir verkniffen, den zweiten Ausspruch zu zitieren, da der eigentlich noch übler ist. Es gibt die richtigen Projectleads - und andere. Na ja - Michael Meeks arbeitet ja daran, dass man gegen solche Aussagen resistent ist. André - To unsubscribe, e-mail: dev-unsubscr...@de.openoffice.org For additional commands, e-mail: dev-h...@de.openoffice.org
Re: [de-dev] Re: Welche Entscheidungen in HH getroffen werden
Moin, Rene Engelhard schrieb: Mathias Bauer wrote: Du sprichst z.B. Ports an. Das ist ein schwieriges Thema. Ich hoffe, dass du es akzeptabel finden kannst, dass man nicht jeden exotischen Port aktiv durch Coden unterstützen muss, aber ich stimme zu, dass ein korrekt. Linux/64bit ist aber keinesweks exotisch. Oder Mac PPC. (ok, das ist - inzwischen - ein wenig exotischer, aber auch nur bei Leuten, die ihre alten iBooks/PowerBooks/MacMinis/... Hardware bereits auf Intel-Macs getauscht haben in dem Zusammenhang wäre es hilfreich, mal aufzuräumen, welche aktiven und stabilen Ports wir überhaupt betreuen: http://porting.openoffice.org/ Ist da nicht sonderlich hilfreich :( Gruß, André - To unsubscribe, e-mail: dev-unsubscr...@de.openoffice.org For additional commands, e-mail: dev-h...@de.openoffice.org
Re: [de-dev] Re: Welche Entscheidungen in HH getroffen werden
Rene Engelhard wrote: Hi, Thorsten Behrens wrote: [Extension-Policy im ESC besprochen oder nicht] Diese Policy ist aber schon im ESC vor ueber einem Jahr angesprochen worden Ok, war ich nicht dabei. Hatte nur gedacht, das Michael Rene sich da vorher schon quergestellt hatten. Welche Extension policy? Und je nachdem was genau gemeint ist habe ich mich dagegen ausgesprochen (iirc war Michael in dem Meeting entweder gerade or gar nicht da) Nein, als wir damals in einen F:F Meeting darüber gesprochen haben, war Michael dabei. Ist aber letztendlich auch egal, denn zum damaligen Zeitpunkt haben ihn Extensions auch gar nicht interessiert. Daher habe ich auch zu meinen diesbezüglichen Fragen auch keine Reaktion erhalten. Wir sollten uns aber nicht mit solchen Dingen aufhalten, sondern im ESC darüber reden. 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
Re: [de-dev] Re: Welche Entscheidungen in HH getroffen werden
Rene Engelhard wrote: Mathias Bauer wrote: [Extension-Policy im ESC besprochen oder nicht] Diese Policy ist aber schon im ESC vor ueber einem Jahr angesprochen worden Ok, war ich nicht dabei. Hatte nur gedacht, das Michael Rene sich da vorher schon quergestellt hatten. Rene war da IIRC ziemlich indifferent. Und Michael war an Extensions Vielleicht am Anfang. Zwischendurch habe ich immer wieder angesprochen, dass der extension-wildwuchs aufhören sollte undsachen die in den core gehören da rein sollten (presenter console, ...) Ich weiß jetzt nicht, ob das jetzt das ist, wovon Thorsten sprach - aber das ist auch in interessantes Thema. Ich persönlich finde auch, dass die Presenter Console in das Office gehört, aber für alle anderen Extensions, die in Hamburg implementiert wurden, sehe ich das nicht so. Insofern finde ich die Bezeichnung Wildwuchs etwas übertrieben. 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
Re: [de-dev] Re: Welche Entscheidungen in HH getroffen werden
Rene Engelhard wrote: Mathias Bauer wrote: Du sprichst z.B. Ports an. Das ist ein schwieriges Thema. Ich hoffe, dass du es akzeptabel finden kannst, dass man nicht jeden exotischen Port aktiv durch Coden unterstützen muss, aber ich stimme zu, dass ein korrekt. Linux/64bit ist aber keinesweks exotisch. Auch korrekt. Sollte also unterstützt werden, in der Tat. Wobei ich darunter verstehe, dass - Entwickler Patches oder CWS reviewen - CWS mit Build Bots darauf gebaut werden können (und dann natürlich auch sollen) - allen Beteiligten klar sein sollte, dass es diesen Port gibt und man sich bei allen plattformrelevanten Überlegungen klar werden sollte, was das denn für Linux/64Bit heißt. Hast du grundsätzlichen (nicht anekdotischen) Grund zur Klage diesbezüglich? Oder Mac PPC. (ok, das ist - inzwischen - ein wenig exotischer, aber auch nur bei Leuten, die ihre alten iBooks/PowerBooks/MacMinis/... Hardware bereits auf Intel-Macs getauscht haben Schwieriges Thema, für mich vergleichbar mit Windows 98, vielleicht etwas weniger exotisch und zumindest noch nicht EOL, dafür aber insgesamt auch mit noch weniger Usern. Ich bin nicht der Fachmann für den Mac, aber zunächst einmal würde ich erwarten, dass es eine aktive Community gibt, die den Port vorantreibt und maintained. Dann darf diese auch erwarten, dass sie bei den anderen Entwicklern auch Unterstützung dafür findet, ihre Arbeit nicht zu sabotieren. Ich hoffe aber nicht, dass du jetzt von den Hamburgern erwartet, dass sie selbst diesen Port machen. Wir haben schon durch die maßgebliche Beteiligung am Mac/Intel-Port ein erhebliches Investment getätigt. 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
Re: [de-dev] Re: Welche Entscheidungen in HH getroffen werden
Moin Thorsten, Mathias Bauer wrote: Und die Aussage, Community habe in den Köpfen der Entwickler nur am Rande Platz empfinde ich sogar fast als dreist, wenn ich sehe, wie gerade die Kollegen direkt um mich herum arbeiten. Nach einer weiteren Nacht Abstand kommt mir die Idee, dass der Grund für unsere unterschiedliche Einschätzung vielleicht ist, dass für dich Community stark sozialromantisch besetzt ist (das ist jetzt wertneutral gemeint), für mich aber mehr organisatorisch. Für mich ist wichtig, dass man in einer Community für andere offen ist und sich der Zusammenarbeit nicht verweigert, wenn sie gesucht wird. Für dich scheint die Interaktion wichtiger zu sein als das Ergebnis, oder du glaubst, dass das Ergebnis schon automatisch gut wird, wenn diese Interaktion stattfindet. Und insbesondere besteht für dich die Community in erster Linie aus Entwicklern, und weniger aus Anwendern. Sehe ich das richtig? 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
