[de-dev] Re: Warum die TDF der Platz für eine wiedervereinte Community sein sollte
Hallo Raphael, jetzt zum ersten Mal verstehe ich als Nichtprogrammierer den Unterschied zwischen den Arbeitsweisen von LO und OOo. Die sind doch gewaltig. Danke für deinen Beitrag. Du hast vollkommen recht: In einer Büro-Umgebung, in einer Bank oder einem anderen Betrieb wären größere Bugs absolut unerträglich. Auch in einem kleineren Verlag, der sich auf das Textsystem einfach verlassen muss, wenn es nicht untergehen will. Das LO-Team scheint davon auszugehen, dass die Anwender aus Spaß irgendwelche Releases testen können, und nicht wirklich produktiv sein wollen oder müssen. Ich wünsche, Oracle entwickelt einen Oracle Office Suite - OOS für die zahlenden Kunden und kooperiert im vollen Sinne mit der OOo-Community. Für meinen Bereich (FH) würde ich sogar den Kauf einer Software, wenn die Preise für Bildung bescheiden bleiben, bevorzugen. Eine Rückkehr zu Microsoft, auch wenn es kostenlos wäre, wäre ein technologischer Rückschritt. Best Dave 2011/5/28 Raphael Bircher r.birc...@gmx.ch Hallo Christian Ich hab mir wirklich lange überlegt, ob ich auf diese Mail antworten soll, denn sie spricht genau den Hauptpunkt an, warum ich mich bei LibO nicht zu Hause fühle. Am 26.05.11 15:59, schrieb Christian Lohmaier: Hallo Michael, *, QA kommt nur durch die Personen zustande die die QA durchführen, und dann auch von Entwicklern, die die gefundenen Fehler beheben. Da beginnt bereits schon das Problem. Bei OOo fühlte sich zumindest Oracle für die Qualität verantwortlich. Wenn ein Bug wirklich stöhrte, konnte man fast immer auf einen Bugfix von dort zählen. Wenn halt mal der entsprechende Programmierer kein Ohr haben wollte, ging man halt eine oder zwei Etagen höher rein. Bugfixes sind meist unspektakulär, und der Enduser bekommt (hoffentlich) nichts davon mit. Somit sind sie für die meisten freien Entwickler uninteressant. Die Firmen die bei LO mitarbeiten sind alle sammt Linux Distributionen. Wenn der Bug also auf Linux ist, gibts Chancen dass er gefixt wird. Aber was, wenn der Bug Windows, oder Mac OS X ist. Bei ganz ganz groben Sachen hilft da Novell manchmal noch, aber auch eher Zähneknirrschend. Alle anderen Bugs bleiben einfach liegen. Schau mal in den Bugtracker, Ihr habt nach etwas mehr als einem Jahr bereits 1800 offene Bugs rumliegen. Dem gegenüber stehen 1200 gefixte. Ohne diskussion, auch bei OOo blieben Bugs offen, Aber im Verhältniss sieht die Bilanz doch einiges besser aus. Bei OOo macht die QA die Community, bei LO macht die QA die Community. Bei OOo fixen Oracle-Entwickler die Bugs (in naher Zukunft dann nicht mehr), bei LibreOffice die Entwickler aus der Community. Der einzige Unterschied ist in der Grundeinstellung zu der Art des Releases, da gibt es einen Unterschied. Selbst wenn dieser unterschied schon ziemlich gross ist, es ist nicht der einzige. Der wirklich grosse Unterschied ist, dass es die Workflows von LibO erlauben dass nahezu ungetesteter Code in das Programm einfliesst. Bei OOo ist das ein Vergehen gegen den Workflow. Es gibt zum Beispiel keine Möglichkeit ein Buggy Feature aufzuhalten. Denn es landet direkt im Master. Der QA hat keine Handhabe gegen den Entwickler, es sei denn es sind ganz üble Bugs, die können zum Blocker ernannt werden. Aber selbst die kriterien für einen Blocker sind so schwammig, dass man fast jedem Bug den Blockerstatus absprechen kann. QA kann man daher für LibO eigentlich gar nicht machen. Man kann Testen, und Fehler melden, was dann damit passiert liegt in den Händen der Programmierer. Auf diese Weise kann man die Qualität nicht sicher stellen. Bei OOo sass man als QA am längeren Hebel. Wenn man als QA stop rief, dann war stop, ob das den Programmierer nun passt oder nicht. Das war zwar keine angenehme Sache für die Programmierer, aber machte dafür die ohnehin sehr unattraktive QA Arbeit wesentlich angenehmer. Ich hatte garantiert Einfluss, was bei LibreOffice nicht der Fall ist. Klar, es war etwas unglücklich, dass dieses System komplett von Mitarbeiter einer Firma kontrolliert wurde und in manchen Fällen wurde das System vielleicht zu stur umgesetzt. Aber es funktionierte. Bei OOo waren die Tests obligatorisch, in den meisten Fällen machten diese Arbeit Leute aus Hamburg. Diese Tests fanden bereits in den CWS statt, also bevor es überhaupt im Master landet. Dabei gab es viele Regeln, vielleicht ein paar zu viele, aber immerhin wurde getestet. Adequate Tests könnte man bei LibO in den Nightly Builds einbauen. Die erste Beta hat aber bewiesen, dass sich wohl kaum jemand um diese Builds schährt, geschweige denn noch ernsthaft testet. Ebenfalls existieren keine Informationen wer was getestet hat. Bei LibreOffice geht man gar nicht erst mit dem Anspruch heran, ein perfektes Release abliefern zu können, das geht bei einer Software bei diesem Umfang einfach nicht, hat es bei OOo nie gegeben, wird es auch anderswo nie geben. Mit dieser Einstellung wird man sehr schnell nachlässig: Wer
[de-dev] Re: Warum die TDF der Platz für eine wiedervereinte Community sein sollte
Hallo, David Paenson wrote on 2011-05-29 13.25: Du hast vollkommen recht: In einer Büro-Umgebung, in einer Bank oder einem anderen Betrieb wären größere Bugs absolut unerträglich. Auch in einem kleineren Verlag, der sich auf das Textsystem einfach verlassen muss, wenn es nicht untergehen will. Das LO-Team scheint davon auszugehen, dass die Anwender aus Spaß irgendwelche Releases testen können, und nicht wirklich produktiv sein wollen oder müssen. ich möchte gar nicht im Detail darauf eingehen, aber Raphaels Ausführungen sind schlicht unqualifiziert. Ich finde es schwach, auf diese Art und Weise die Arbeit der LibreOffice-Entwickler diskreditieren zu wollen. Und wer sich mal mit der Geschichte der TDF und deren Gründen befasst hat, der weiß, dass das mal eben ein paar Etagen höher reingehen, wie Rapahel es schreibt, insbesondere in den letzten Monaten ein Ding der Unmöglichkeit geworden ist. Ich denke, wir haben genug erfahrene Leute bei uns an Bord (unter anderem den langjährigen QA-Lead des OpenOffice.org-Projekts), die uns mit ihrem Wissen unterstützen. Weder bei LibreOffice ist alles Gold was glänzt, noch bei OpenOffice.org. Die Unterstellung, LibreOffice würde in nicht produktiv einsetzbarer Form zum Anwender ausgeliefert, zeugt jedoch nicht gerade von Verständnis, oder fairer Behandlung. Das, was das OpenOffice.org-Projekt für sich beansprucht -- fair behandelt zu werden -- dürfen denke ich wir ebenso beanspruchen. Nachdem Raphael die letzten Monate eher mit mehrfachen Rücktritten vom Rücktritt denn mit produktiver Arbeit auf sich aufmerksam gemacht hat, und auf dieser Liste schon gesagt hat, dass ihm das Thema eigentlich ohnehin egal ist, weil er andere Pläne hat, finde ich solche Statements besonders in dieser Situation reichlich vermessen. Sich hinstellen und sagen, wie etwas sein sollte, und es aktiv machen, das sind zwei paar Stiefel. Ich bevorzuge dann doch Letzteres. Unterschiedliche Sichtweisen zu Prozessen und Ideen sind legitim, und sachlich kann man gerne darüber diskutieren -- aber diese Behauptung, wie zitiert, kann und will ich so nicht stehen lassen. Florian -- Florian Effenberger flo...@documentfoundation.org Steering Committee and Founding Member of The Document Foundation Tel: +49 8341 99660880 | Mobile: +49 151 14424108 Skype: floeff | Twitter/Identi.ca: @floeff -- - To unsubscribe send email to dev-unsubscr...@de.openoffice.org For additional commands send email to sy...@de.openoffice.org with Subject: help
[de-dev] Re: Warum die TDF der Platz für eine wiedervereinte Community sein sollte
Hallo Raphael, sorry, auch ich habe mich lange gefragt, ob ich antworten soll. Aber da andere den Schwachsinn, den Du schreibst für bare Münze nehmen, sehe ich mich gezwungen einige Sachen klarzustellen. 2011/5/28 Raphael Bircher r.birc...@gmx.ch: Am 26.05.11 15:59, schrieb Christian Lohmaier: Bei OOo fühlte sich zumindest Oracle für die Qualität verantwortlich. Wenn ein Bug wirklich stöhrte, konnte man fast immer auf einen Bugfix von dort zählen. Was bringt Dich auf die Idee, daß man bei LO nicht auf einen Bugfix zählen kann, wenn ein Bug wirklich stört? Wenn halt mal der entsprechende Programmierer kein Ohr haben wollte, ging man halt eine oder zwei Etagen höher rein. Hahahahahahahaha! Bitte, FAKTEN, nicht nur Geschwafel. Gibt mir mal ein Beispiel, wo Du (oder jemand anders, der nix mit Oracle zu tun hat) mal ein oder zwei Etagen höher gegangen ist. Was ist denn überhaupt nach Deiner Definition eine Etage höher, und was ist dann die zweite Etage. Sorry, aber Du schwafelst wieder nur irgendwelches Zeug, von dem Du glaubst es sei so, aber von dem du selber überhaupt keine Ahnung hast. Wie oft hattest DU SELBST mit cws-QA zu tun? Noch nicht mal als QA-Rep, einfach nur als Member würde mir schon reichen. Schau mal in den Bugtracker, Ihr habt nach etwas mehr als einem Jahr bereits 1800 offene Bugs rumliegen. Dem gegenüber stehen 1200 gefixte. Bitte, schau doch mal bei OOo: über 2 offene Bugs, das auf 10 Jahre, macht pro Jahr 2000 offene Bugs, und das trotz der sooo tollen Unterstützung von Oracle. Demgegenüber stehen run 45000 gefixte Issues (und das sind nicht nur code-issues). Aber nur mit den blanko Zahlen, ohne zusätzliche Kriterien bringt das nix. Ohne diskussion, auch bei OOo blieben Bugs offen, Aber im Verhältniss sieht die Bilanz doch einiges besser aus. Nein, sieht sie nicht. Mal abgesehen davon, daß bei den offenen Bugs bei LibreOffice auch etliche EasyHacks, sprich einsteigertaugliche Aufgaben gesammelt sind - aus den reinen Zahlen kannst Du keine Bilanz ableiten. Der einzige Unterschied ist in der Grundeinstellung zu der Art des Releases, da gibt es einen Unterschied. Selbst wenn dieser unterschied schon ziemlich gross ist, es ist nicht der einzige. Der wirklich grosse Unterschied ist, dass es die Workflows von LibO erlauben dass nahezu ungetesteter Code in das Programm einfliesst. Wenn es in den Code einfließt, heißt das noch lange nicht, daß das auch im Programm landet. Auch in einen CWS wird nahezu ungetesteter Code reingeschrieben. Alles was neu ist ist per Definition ungetestet. Bei OOo testet das dann ein dem Entwickler zugeneigter QA-Mensch, bei LO werfen sich alle darauf. Wo findet man den Fehler schneller: Wenn zwei Leute draufschauen, oder wenn 50 Leute draufschauen? Mal anders rum: Bei LO wäre es undenkbar, daß eine Verschlimmbesserung wie der Serienbriefassistent im Produkt landen würde. Sowas ist nur dadurch möglich, daß es erst abgeschottet in irgendeinem CWS erstellt wird, und dann nach dem Motto Hurrah, hier bin ich im Produkt landet. Und wenn man dann was kritisiert heißt es: Jetzt ist es zu spät, jetzt ist es ja schon implementiert, hättest Du mal früher reagiert. Also kommts ins Produkt, obwohl jedem klar ist, daß die Lösung Murks ist. Es gibt zum Beispiel keine Möglichkeit ein Buggy Feature aufzuhalten. Klar gibt es das. Und das einfacher als bei OOo. Überraschungsmomente ala Ich hab da mal was vorbereitet - friß oder stirb gibts hier quasi nicht. Denn es landet direkt im Master. Ja und? von Master aus werden keine Endnutzer-Releases erstellt. Und die Release-Branches werden auch so frühzeitig abgezweigt, daß nicht noch kurz vor Schluß ein Feature plötzlich auftaucht, so wie es bei OOo oft der Fall war. Kurz vor der Deadline werden auf Teufel-komm-raus noch unzählige CWS integriert und schon tauchen für den externen Beobachter 5 neue Features auf, von denen vorher noch keine Rede war. Bei LO passiert das nicht. Es gibt Master, da landen neue Sachen, für Umfangreichere Sachen gibt es auch da extra Branches. Aber Master und den Release-Branch kannst Du nicht gleichsetzen. Der QA hat keine Handhabe gegen den Entwickler, es sei denn es sind ganz üble Bugs, die können zum Blocker ernannt werden. Sorry, aber womit belegst Du diese Aussage? Wo ist es anders gegenüber Oracle/OOo. Auch bei OOo hast Du keine andere Handhabe als bei LO: Issue melden, zum Blocker-Issue hinzufügen und hoffen, daß das release-team den als wichtig genug einstuft, um das Release zu verzögern. Mehr Handhabe hat die QA bei OOo auch nicht. Aber selbst die kriterien für einen Blocker sind so schwammig, dass man fast jedem Bug den Blockerstatus absprechen kann. Ist doch bei OOo auch nicht anders definiert! Bei OOo sass man als QA am längeren Hebel. Das ist Schwachsinn. Wenn man als QA stop rief, dann war stop, ob das den Programmierer nun passt oder nicht. OK, wieder mal Ende der Märchenstunde und Fakten/Beispiele bitte. Wann hast Du (oder wer anders,
[de-dev] Re: Warum die TDF der Platz für eine wiedervereinte Community sein sollte
Hallo zusammen, bisher habe ich mich aus der ganzen Diskussion herausgehalten. Doch dies kann ich so nicht stehen lassen. Ohne auf einzelne Sätze einzugehen, muss ich als noch fungierender QA-Repräsentant der deutschsprachigen OpenOffice.org Community sagen, dass ich ähnliche Erfahrungen wie Raphael gemacht habe. Auch habe ich immer wieder bei Diskussionen aus der Community um störende Bugs darum gebeten, mir doch entsprechende Beschreibungen zukommen zulassen, um diese Problematik auch an anderer Stelle (mit den Entwicklern) diskutieren zu können. Wenn es diese Beschreibungen gab, sind diese Fehler auch zeitnah gefixt worden. Leider gab es nur wenige, die bereit waren, mir diese Informationen zu geben. Umgekehrt habe ich die Erfahrung gemacht, dass meine Beiträge bezüglich Bugs (ausschließlich) in LibO nicht erwünscht sind. Daher habe ich für mich auch den Entschluss gefasst, bei OpenOffice.org zu bleiben. Gruß Mechtilde Am 29.05.2011 um 15:02 schrieb Christian Lohmaier: Hallo Raphael, sorry, auch ich habe mich lange gefragt, ob ich antworten soll. Aber da andere den Schwachsinn, den Du schreibst für bare Münze nehmen, sehe ich mich gezwungen einige Sachen klarzustellen. 2011/5/28 Raphael Bircher r.birc...@gmx.ch: Am 26.05.11 15:59, schrieb Christian Lohmaier: Bei OOo fühlte sich zumindest Oracle für die Qualität verantwortlich. Wenn ein Bug wirklich stöhrte, konnte man fast immer auf einen Bugfix von dort zählen. Was bringt Dich auf die Idee, daß man bei LO nicht auf einen Bugfix zählen kann, wenn ein Bug wirklich stört? Wenn halt mal der entsprechende Programmierer kein Ohr haben wollte, ging man halt eine oder zwei Etagen höher rein. Hahahahahahahaha! Bitte, FAKTEN, nicht nur Geschwafel. Gibt mir mal ein Beispiel, wo Du (oder jemand anders, der nix mit Oracle zu tun hat) mal ein oder zwei Etagen höher gegangen ist. Was ist denn überhaupt nach Deiner Definition eine Etage höher, und was ist dann die zweite Etage. Sorry, aber Du schwafelst wieder nur irgendwelches Zeug, von dem Du glaubst es sei so, aber von dem du selber überhaupt keine Ahnung hast. Wie oft hattest DU SELBST mit cws-QA zu tun? Noch nicht mal als QA-Rep, einfach nur als Member würde mir schon reichen. Schau mal in den Bugtracker, Ihr habt nach etwas mehr als einem Jahr bereits 1800 offene Bugs rumliegen. Dem gegenüber stehen 1200 gefixte. Bitte, schau doch mal bei OOo: über 2 offene Bugs, das auf 10 Jahre, macht pro Jahr 2000 offene Bugs, und das trotz der sooo tollen Unterstützung von Oracle. Demgegenüber stehen run 45000 gefixte Issues (und das sind nicht nur code-issues). Aber nur mit den blanko Zahlen, ohne zusätzliche Kriterien bringt das nix. Ohne diskussion, auch bei OOo blieben Bugs offen, Aber im Verhältniss sieht die Bilanz doch einiges besser aus. Nein, sieht sie nicht. Mal abgesehen davon, daß bei den offenen Bugs bei LibreOffice auch etliche EasyHacks, sprich einsteigertaugliche Aufgaben gesammelt sind - aus den reinen Zahlen kannst Du keine Bilanz ableiten. Der einzige Unterschied ist in der Grundeinstellung zu der Art des Releases, da gibt es einen Unterschied. Selbst wenn dieser unterschied schon ziemlich gross ist, es ist nicht der einzige. Der wirklich grosse Unterschied ist, dass es die Workflows von LibO erlauben dass nahezu ungetesteter Code in das Programm einfliesst. Wenn es in den Code einfließt, heißt das noch lange nicht, daß das auch im Programm landet. Auch in einen CWS wird nahezu ungetesteter Code reingeschrieben. Alles was neu ist ist per Definition ungetestet. Bei OOo testet das dann ein dem Entwickler zugeneigter QA-Mensch, bei LO werfen sich alle darauf. Wo findet man den Fehler schneller: Wenn zwei Leute draufschauen, oder wenn 50 Leute draufschauen? Mal anders rum: Bei LO wäre es undenkbar, daß eine Verschlimmbesserung wie der Serienbriefassistent im Produkt landen würde. Sowas ist nur dadurch möglich, daß es erst abgeschottet in irgendeinem CWS erstellt wird, und dann nach dem Motto Hurrah, hier bin ich im Produkt landet. Und wenn man dann was kritisiert heißt es: Jetzt ist es zu spät, jetzt ist es ja schon implementiert, hättest Du mal früher reagiert. Also kommts ins Produkt, obwohl jedem klar ist, daß die Lösung Murks ist. Es gibt zum Beispiel keine Möglichkeit ein Buggy Feature aufzuhalten. Klar gibt es das. Und das einfacher als bei OOo. Überraschungsmomente ala Ich hab da mal was vorbereitet - friß oder stirb gibts hier quasi nicht. Denn es landet direkt im Master. Ja und? von Master aus werden keine Endnutzer-Releases erstellt. Und die Release-Branches werden auch so frühzeitig abgezweigt, daß nicht noch kurz vor Schluß ein Feature plötzlich auftaucht, so wie es bei OOo oft der Fall war. Kurz vor der Deadline werden auf Teufel-komm-raus noch unzählige CWS integriert und schon tauchen für den externen Beobachter 5 neue Features auf, von denen vorher noch keine
[de-dev] Re: Warum die TDF der Platz für eine wiedervereinte Community sein sollte
Am 29.05.11 15:02, schrieb Christian Lohmaier: Hallo Raphael, sorry, auch ich habe mich lange gefragt, ob ich antworten soll. Aber da andere den Schwachsinn, den Du schreibst für bare Münze nehmen, sehe ich mich gezwungen einige Sachen klarzustellen. [...] Du weichst meinen Kernaussagen generell aus. Bei OOo hatte die QA einen festen Bestandteil im Entwicklungsprozess, die QA musste in jedem Fall passiert werden. Wenn nicht genügend QA zur Verfügung standen, bremste das eben die Entwicklung aus. Aber es war vom Workflow her nicht möglich, dass Ungetesteter Code einfliesst. Bei LibO ist das vom Workflow her möglich. Ob es dann geschiet ist eine andere Sache. Bei LibO geht die Entwicklung weiter, unabhängig davon ob getestet wurde oder nicht. Es wird angenommen, das getestet wird, aber ob, in welchem Umfang und was, weiss niemand. Das ist eine singifikante Schwachstelle die LibO hat. Ich weiss, dass man diese nicht wahrhaben will, und deswegen erachte ich auch jegliche Diskussionen als sinnlos. Wir haben verschiedene Ansichten, und für mich ist das OK. Gruss Raphael -- My private Homepage: http://www.raphaelbircher.ch/ -- - To unsubscribe send email to dev-unsubscr...@de.openoffice.org For additional commands send email to sy...@de.openoffice.org with Subject: help
[de-dev] Re: Warum die TDF der Platz für eine wiedervereinte Community sein sollte
Hallo Mechtilde, Am 29.05.2011 15:28, schrieb Mechtilde Stehmann: Umgekehrt habe ich die Erfahrung gemacht, dass meine Beiträge bezüglich Bugs (ausschließlich) in LibO nicht erwünscht sind. Mir ist als initial-Problem, das du heftig kritisiert hast der Wegfall des Importassistenten und damit der automatische Import einer vorhandenen OOo-Konfigurationen bekannt. Nach einigem hin-und her gibt es dazu in LibO eine Kompromisslösung, in die die Entwickler durchaus Zeit investiert haben. Unerwünscht würde ich das nicht nennen (im gegenteil, es gab in dem Moment wenige, denen so eine Individualbetreuung zuteil kam.) Leider hattest du dich schon nach wenigen Tagen überhaupt nichtmehr an der Diskussion dazu beteiligt. Insofern wurde halt der Kompromiss von anderen weitergetragen. Ich finde es sehr sehr schade, dass hier Stimmung gemacht wird vollkommen an der Sachlage vorbei. Gruß, André -- - To unsubscribe send email to dev-unsubscr...@de.openoffice.org For additional commands send email to sy...@de.openoffice.org with Subject: help
[de-dev] Re: Warum die TDF der Platz für eine wiedervereinte Community sein sollte
Hallo André, hallo *, ich möchte hier nicht auf einzelne Gespräche eingehen. Aber es gab eine ganze Reihe von Beiträgen von mir zu diesem Thema. Das von Dir beschriebene war weder der erste noch der letzte Beitrag von mir zu diesem Thema Nur einen Punkt herauszugreifen, verzerrt das Bild. Gruß Mechtilde Am 29.05.2011 20:55, schrieb André Schnabel: Hallo Mechtilde, Am 29.05.2011 15:28, schrieb Mechtilde Stehmann: Umgekehrt habe ich die Erfahrung gemacht, dass meine Beiträge bezüglich Bugs (ausschließlich) in LibO nicht erwünscht sind. Mir ist als initial-Problem, das du heftig kritisiert hast der Wegfall des Importassistenten und damit der automatische Import einer vorhandenen OOo-Konfigurationen bekannt. Nach einigem hin-und her gibt es dazu in LibO eine Kompromisslösung, in die die Entwickler durchaus Zeit investiert haben. Unerwünscht würde ich das nicht nennen (im gegenteil, es gab in dem Moment wenige, denen so eine Individualbetreuung zuteil kam.) Leider hattest du dich schon nach wenigen Tagen überhaupt nichtmehr an der Diskussion dazu beteiligt. Insofern wurde halt der Kompromiss von anderen weitergetragen. Ich finde es sehr sehr schade, dass hier Stimmung gemacht wird vollkommen an der Sachlage vorbei. Gruß, André -- Dipl. Ing. Mechtilde Stehmann ## http://de.openoffice.org ## Ansprechpartnerin für die deutschsprachige QA ## Freie Office-Suite für Linux, Mac, Windows, Solaris ## Meine Seite http://www.mechtilde.de ## PGP encryption welcome! Key-ID: 0x53B3892B signature.asc Description: OpenPGP digital signature
[de-dev] Re: Aktueller Zustand - OOo-Projekt
Hallo, Gerhard Riedinger wrote: Zum Thema, was aus dem Projekt geworden ist, mag Günters Thread zur Zählung der potentiellen Mitarbeiter ganz hilfreich sein. Ich will das Ergebnis hier nicht auswerten geschweige denn kommentieren; das obliegt sicherlich dem Co-Lead selbst. Ich denke schon, dass jeder sich ein Bild machen darf und seine Beobachtungen auch aussprechen darf: Der „Zählappell“¹ hätte „etwa eine Woche“ dauern sollen, inzwischen sind 10 Tage vergangen. Es haben sich in dieser Zeit 4 (vier) Personen gemeldet, die noch „bereit zu aktiver Mitarbeit“ sind. Darunter waren noch nicht einmal die beiden Co-Leads des Projekts (sondern nur einer) und nicht einer der Ansprechpartner des Projekts! (Wobei die Liste der Ansprechpartner² insofern fehlerhaft ist, als dass dort noch Personen geführt werden, die – wie du – von ihren Funktionen inzwischen zurückgetreten sind.) [Zusammenfassung] Ich bedauere das außerordentlich, aber das sind nun einmal die heutigen Fakten. Ich schließe mich – ebenfalls mit Bedauern – deinen Beobachtungen an. Darüber hinaus sind die jetzt noch geführten Diskussionen für mich meist eher Ausdruck einer mit Händen zu fassenden kognitiven Dissonanz³ als Anzeichen eines handlungs- oder auch nur überlebensfähigen Projekts. [1] http://www.mail-archive.com/dev%40de.openoffice.org/msg31928.html ff. [2] http://de.openoffice.org/dev/ansprechpartner.html [3] vgl. http://de.wikipedia.org/wiki/Kognitive_Dissonanz Grüße -- Martin Bayer www.mbayer.de -- - To unsubscribe send email to dev-unsubscr...@de.openoffice.org For additional commands send email to sy...@de.openoffice.org with Subject: help
