Hallo Jörg, Diese Diskussion gehört IMO in dieser Ausführlichkeit nicht mehr auf eine Users-Liste.
Daher nur jeweils ein kurzes Statement von mir dazu. Weitere Diskussionen sollten wir auf der dev@ fortsetzen. Am 02.05.20 um 18:55 schrieb Jörg Schmidt: > Hallo Mechtilde, > >> ermöglicht, downloadbar hier: >>> https://www.heise.de/ct/ftp/10/14/166/ >>> >>> Es wäre technisch kein Problem, diese Funktion in >> OPenOffice zu integrieren, indem man diese Extension, ganz >> oder teilweise übernimmt. >> >> Wenn das Technisch kein Problem ist, diese Extension in Apache >> OpenOffice zu intrgrieren, dann kannst Du dies ja schon mal als Gull >> Request vorbereiten. > > Es gibt zu der Frage 'Extensions mit dem Programm ausliefern' Erfahrungen aus > der Vergangenheit und wir sollten darauf aufbauend den richtigen Weg finden > und der kann imho nicht sein jetzt wieder isoliert einzelne Extensions ins > Programmpaket zu packen, sondern es müsste etwas technisch Koordiniertes > sein, sagen wir einmal so etwas wie eine 'Main-Extension'(*) und ein klar > koordiniertes Vorgehen, z.B. in der Form das wir diese 'Main-Extension' > nutzen um Neues auszuprobieren und dann Später das, was sich davon bewährt > hat, möglichst in nativen Code ins Programm übernehmen. > Es ist, meines Erachtens, unsere moralische Pflicht unseren Nutzern > Sicherheit und Kontinuität im Programm zu bieten, wir dürfen nicht darauf > setzen Programmfeatures vom Engagement Einzelner abhängig zu machen. in einem Projekt, dass *ausschließlich* von Freiwilligen betrieben wird, hängt *alles* vom Engagement Einzelner ab. Wir machen dies alles in unserer spärlichen Freizeit. > (*) > damit meine ich eine regelmäßig in AOO vorhandene Extension, die verschiedene > Einzel-Features bündelt (technisch als Bibliotheken oder Module) und die die > normale QA verpflichtend durchlaufen müsste. "Extension" auch deshalb weil es > Chancen für Nicht-C++-Programmierer bietet, zur Verbesserung von AOO konkret > beizutragen, gleichzeitig darf aber an dieser Stelle nicht der > Qualitätsanspruch gesenkt werden. Die mitausgelieferten Erweiterungen werden genauso getestet wie Apache OpenOffice selbst. > > > Zu tun wäre, meiner Meinung nach, das was ich gerade sagte, und aber ich habe > keine Lust mich wieder einmal 'abwatschen' zu lassen, weil ich Koordination > einfordere und ich habe auch keine Lust mich persönlich lieb Kind zu machen, > nur um etwas in Eigenregie ohne Widerstand so umsetzen zu können wie es mir > _vordergründig_ vielleicht richtig erschiene. > > Ja, Du hast Letzteres richtig verstanden, ich will keine Lösungen > durchgesetzt sehen um meiner Person oder Meinung willen, sondern ich richte > die Forderung nach kritischer Betrachtung allen Tuns, auch gegen meine > eigenen Vorschläge und halte es für vernünftig in der Community um die > gemeinsamen Ziele zu streiten, Kritik vorzubringen im Interesse der Sache und > in Hoffnung dadurch etwas im Programm zu verbessern. > Ich glaube insgesamt nicht an Verbesserung die spontan dadurch entsteht, das > man auf kritisches Hinterfragen des eigenen Tuns verzichtet. Wir hinterfragen täglich unser Tun für Apache OpenOffice. Dies tun wir schon im Hinblick auf den effektiven Einsatz unseres Engagements. Auch dass es überhaupt wieder möglich geworden ist, Apache OpenOffice in vielen Sprachen bereitstellen zu können, ist spontanem aber nachhaltigem Engagement zu verdanken. Meinen Dank geht dazu an alle Übersetzer. Aber ohne Prozessmanagement funktioniert es nicht. > Gruß > Jörg Gruß -- Mechtilde Stehmann ## Apache OpenOffice ## Freie Office Suite für Linux, MacOSX, Windows ## Debian Developer ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F
signature.asc
Description: OpenPGP digital signature
