RE: Wie unser Projekt derzeit funktioniert
Hallo, > -Original Message- > From: Dr. Michael Stehmann [mailto:anw...@rechtsanwalt-stehmann.de] > Sent: Monday, February 10, 2020 9:51 AM > To: dev-de@openoffice.apache.org > Subject: Re: Wie unser Projekt derzeit funktioniert > > Hallo, > > Am 09.02.20 um 10:32 schrieb Jörg Schmidt: > > > bei AOO-Calc sieht man leider deutlich wie es funktionell > hinter LO-Calc zurückgeblieben ist und eine Ursache dafür > scheint mir das wir unsere Arbeit schlecht koordinieren und > uns nicht über notwendige Priorisierungen unterhalten. > > Dafür würde bei Calc schon das Wiederaufleben der 'Regel' > von OOo-Calc Einiges bringen, die da hieß: wir streben für > Calc möglichst 100% Kompatibilität der Tabellenfunktionen > (gemeint sind 'Formeln') zu MS Excel an, OBWOHL wir für OOo > insgesamt _kein_ MSO-Clone sein wollen. > > > Tut mir leid, aber das entspricht nicht mehr ganz dem Stand der Dinge. > Man ist derzeit etwas weiter. > > "OpenFormula is an open standard for exchanging recalculated > formulae in > spreadsheets. OpenFormula is included in version 1.2 of the > OpenDocument > standard." [0] > > Wir sollten daher in erster Linie versuchen, diesen Standard möglichst > vollständig umzusetzen. Und der Widerspruch zu der Aussage der Kompatibilität zu MS Excel ist jetzt wo? Oder anders gefragt: Warum bekommt LO OpenFormula und Kompatibilität zu Excel nahezu perfekt unter einen Hut und wir nicht? Wohlgemerkt bezieht sich ja Deine Aussage NICHT auf das Problem des Personalmangels, sondern Du versuchst anzudeuten das die Implementierung von OpenFormula in Widerspruch zur Möglichkeit der Excel-Kompatibilität stünde, was einfach nicht stimmt. > MSO ist und sollte daher kein Maßstab sein. Auch das hatte ich bereits ausdrücklich hinschrieben! Auch hatte ich die inflationelle Aufblähung der Anzahl der Tabellenfunktionen in Excel gescholten. btw: Selbst bereits OOo hat gezeigt wie man Formel-Kompatibilität technisch herstellen kann ohne MS Excel nachäffen zu müssen und auf eigenständige Konzepte zu verzichten. Gruß Jörg - To unsubscribe, e-mail: dev-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-de-h...@openoffice.apache.org
RE: Wie unser Projekt derzeit funktioniert
Hallo, > -Original Message- > From: Dr. Michael Stehmann [mailto:anw...@rechtsanwalt-stehmann.de] > Sent: Monday, February 10, 2020 9:32 AM > To: dev-de@openoffice.apache.org > Subject: Re: Wie unser Projekt derzeit funktioniert > > Hallo, > > Am 08.02.20 um 10:41 schrieb Jörg Schmidt: > > > Ich fürchte es bleibt eine nicht restlos geklärte Frage wie > wir uns verhalten sollen bzw. die einen meinen wir verdienten > von den Anwendern Respekt weil wir ihnen kostenlos helfen, > die anderen meinen die Anwender verdienen von uns Respekt > weil sie unsere Multiplikatoren sind ... ich glaube diese > zwei Meinungen werden sich immer gegenüberstehen. > > > > Das eine schließt das andere nicht aus. genauso ist es > Wenn sich alle anderen gegenüber stets respektvoll verhalten, > könnte die > Welt besser und das Leben schöner sein. In der Tat. Man bekommt nur über die Jahre auch ein Gespür die Reaktionen der Community zu deuten und ich glaube nicht das es fair ist mir gewissermaßen etwas anzulasten auf das man bei Wolfgang mit Wohlwollen übergeht. (zumal ikch mich ja jüngst selbst noch darüber belehren lassen musste das es ein Kriterium "beliebt" hier garnicht gibt) Gruß Jörg - To unsubscribe, e-mail: dev-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-de-h...@openoffice.apache.org
Re: Wie unser Projekt derzeit funktioniert
Hallo, Am 09.02.20 um 10:32 schrieb Jörg Schmidt: > bei AOO-Calc sieht man leider deutlich wie es funktionell hinter LO-Calc > zurückgeblieben ist und eine Ursache dafür scheint mir das wir unsere Arbeit > schlecht koordinieren und uns nicht über notwendige Priorisierungen > unterhalten. > Dafür würde bei Calc schon das Wiederaufleben der 'Regel' von OOo-Calc > Einiges bringen, die da hieß: wir streben für Calc möglichst 100% > Kompatibilität der Tabellenfunktionen (gemeint sind 'Formeln') zu MS Excel > an, OBWOHL wir für OOo insgesamt _kein_ MSO-Clone sein wollen. > Tut mir leid, aber das entspricht nicht mehr ganz dem Stand der Dinge. Man ist derzeit etwas weiter. "OpenFormula is an open standard for exchanging recalculated formulae in spreadsheets. OpenFormula is included in version 1.2 of the OpenDocument standard." [0] Wir sollten daher in erster Linie versuchen, diesen Standard möglichst vollständig umzusetzen. Hier hilft uns Regina. Wir müssen allerdings dafür sorgen, dass ihre Beiträge (auch) in unseren Code integriert werden. MSO ist und sollte daher kein Maßstab sein. Was die "Kompatibilität" mit MSO angeht, erscheint mir generell die Integration von Apache POI [1] sinnvoll, wenn man darauf Wert auf diese Kompatibilität legen will. (Es gibt gute Gründe dafür, aber auch Gründe dagegen.) Gruß Michael [0] https://en.wikipedia.org/wiki/OpenFormula [1] https://poi.apache.org/ signature.asc Description: OpenPGP digital signature
Re: Wie unser Projekt derzeit funktioniert
Hallo, Am 08.02.20 um 10:41 schrieb Jörg Schmidt: > Ich fürchte es bleibt eine nicht restlos geklärte Frage wie wir uns verhalten > sollen bzw. die einen meinen wir verdienten von den Anwendern Respekt weil > wir ihnen kostenlos helfen, die anderen meinen die Anwender verdienen von uns > Respekt weil sie unsere Multiplikatoren sind ... ich glaube diese zwei > Meinungen werden sich immer gegenüberstehen. > Das eine schließt das andere nicht aus. Ich sehe da keinen Gegensatz. Wenn sich alle anderen gegenüber stets respektvoll verhalten, könnte die Welt besser und das Leben schöner sein. Gruß Michael signature.asc Description: OpenPGP digital signature
RE: Wie unser Projekt derzeit funktioniert
Hallo Peter, > -Original Message- > From: Peter Kovacs [mailto:pe...@apache.org] > Sent: Sunday, February 09, 2020 10:59 AM > To: dev-de@openoffice.apache.org > Subject: RE: Wie unser Projekt derzeit funktioniert > Ich finde auch das Attribut frostig falsch. Es gab hier in den letzten Tagen Streit auf der Liste, inzwischen sind die 'Wellen' bereits wieder am sich-Glätten, deswegen möchte ich klarstellen: Ich lege wirklich keinen Wert auf diese Formulierung - zuerst wollte ich "unhöflich" schreiben das schien mir nur noch ungeeigneter. Gruß Jörg - To unsubscribe, e-mail: dev-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-de-h...@openoffice.apache.org
RE: Wie unser Projekt derzeit funktioniert
Top zusätzliche Info. Ich mag zwar die Excel Referenz nicht, aber das Video ist eine nice Ressource. Wir sollten an sich aufpassen wegen Gebrauchsmuster. Die sind überall geschützt. Ich finde auch das Attribut frostig falsch. Das ist deine Interpretation. Mit 20% Informations Volumen gegenüber einem Persönlichem Dialog gibt es leider extrem viel Spielraum. Wir dürfen auch nicht Kulturelle und andere umgangsforms Unterschiede die zum Tragen können kommen vernachlässigen. Es ist unglaublich wichtig zu verstehen das es nicht persönlich gemeint ist. Beste Grüße Peter Am 9. Februar 2020 10:32:47 MEZ schrieb "Jörg Schmidt" : >Hallo Peter, > >> -Original Message- >> From: Peter Kovacs [mailto:pe...@apache.org] >> Sent: Saturday, February 08, 2020 11:18 AM >> To: dev-de@openoffice.apache.org >> Subject: Re: Wie unser Projekt derzeit funktioniert > >> Es wäre stressfreier würdest du einfach im Issue ergänzen was du >weißt >> und den Report verbessern. Es reicht schon wenn du Bidouilles Request >> Excel Beschreibung ist nicht genug aufnimmst. > >ich habe jetzt einen Kommentar an den Issue gehängt, von dem ich hoffe >er ist genügend erkärend. > >> Lass die Userin in Ruhe, die hat gemacht was sie konnte oder >> wollte. > >Ich hatte nicht vor die Userin in Unruhe zu versetzen, noch sie >derzeitig zu kontaktieren. Sollte ich sie kontaktieren weil ich eine >Extension erstellt bekommen habe, kann es doch wohl aber nicht schaden >ihr en passant mitzuteilen das die 'frostige' Reaktion auf ihren Issue >damit zu tun hatte das sie zu Teil den Issue falsch ausgefüllt hat. >Das wird an der entstandenen Lage nichts ändern aber es ist gut für das >Ansehen unseres Projektes, denn die Nutzerin wird sich denken 'schau >an, die AOO-Leute kümmern sich'. > >> Das >> hier ist keine Zwangsveranstaltung wie du das so siehst. > >?? > > > >Gruß >Jörg > > > >P.S. >ich habe verstanden das Probleme auch daraus resultierten das der Issue >falsch oder ungenau formuliert war, gleichzeitig (und weil wir darüber >ja derzeitig diskutiert haben) möchte ich auf Eines hinweisen: > >bei AOO-Calc sieht man leider deutlich wie es funktionell hinter >LO-Calc zurückgeblieben ist und eine Ursache dafür scheint mir das wir >unsere Arbeit schlecht koordinieren und uns nicht über notwendige >Priorisierungen unterhalten. >Dafür würde bei Calc schon das Wiederaufleben der 'Regel' von OOo-Calc >Einiges bringen, die da hieß: wir streben für Calc möglichst 100% >Kompatibilität der Tabellenfunktionen (gemeint sind 'Formeln') zu MS >Excel an, OBWOHL wir für OOo insgesamt _kein_ MSO-Clone sein wollen. > >Diese Frage der Tabellenfunktionen ist nämlich der maßgebliche Teil wo >AOO gegenüber LO zurückgefallen ist und ich sage das OBWOHL ist ein >grundsätzlicher Gegner all der Spezial-TabellenFunktionen bin, aber ich >muss zur Kenntnis nehmen das die meisten Anwender nicht gerne selbst >denken sondern fertige Dinge vor die Nase gesetzt haben wollen. > >Um bei, solchen Dingen, Einschätzungen richtig treffen zu können bedarf >es aber imho essentiell der Hinzuziehung von kompetenten Praktikern. >Ich weiß das dazu niemand die Programmierer zwingen kann, und deshalb >mache ich darauf nur viral aufmerksam, in der Hoffnung das zu einer >freiwilligen Berücksichtigung dieser Dinge führt. > > > > > > > >- >To unsubscribe, e-mail: dev-de-unsubscr...@openoffice.apache.org >For additional commands, e-mail: dev-de-h...@openoffice.apache.org
RE: Wie unser Projekt derzeit funktioniert
Hallo Peter, > -Original Message- > From: Peter Kovacs [mailto:pe...@apache.org] > Sent: Saturday, February 08, 2020 11:18 AM > To: dev-de@openoffice.apache.org > Subject: Re: Wie unser Projekt derzeit funktioniert > Es wäre stressfreier würdest du einfach im Issue ergänzen was du weißt > und den Report verbessern. Es reicht schon wenn du Bidouilles Request > Excel Beschreibung ist nicht genug aufnimmst. ich habe jetzt einen Kommentar an den Issue gehängt, von dem ich hoffe er ist genügend erkärend. > Lass die Userin in Ruhe, die hat gemacht was sie konnte oder > wollte. Ich hatte nicht vor die Userin in Unruhe zu versetzen, noch sie derzeitig zu kontaktieren. Sollte ich sie kontaktieren weil ich eine Extension erstellt bekommen habe, kann es doch wohl aber nicht schaden ihr en passant mitzuteilen das die 'frostige' Reaktion auf ihren Issue damit zu tun hatte das sie zu Teil den Issue falsch ausgefüllt hat. Das wird an der entstandenen Lage nichts ändern aber es ist gut für das Ansehen unseres Projektes, denn die Nutzerin wird sich denken 'schau an, die AOO-Leute kümmern sich'. > Das > hier ist keine Zwangsveranstaltung wie du das so siehst. ?? Gruß Jörg P.S. ich habe verstanden das Probleme auch daraus resultierten das der Issue falsch oder ungenau formuliert war, gleichzeitig (und weil wir darüber ja derzeitig diskutiert haben) möchte ich auf Eines hinweisen: bei AOO-Calc sieht man leider deutlich wie es funktionell hinter LO-Calc zurückgeblieben ist und eine Ursache dafür scheint mir das wir unsere Arbeit schlecht koordinieren und uns nicht über notwendige Priorisierungen unterhalten. Dafür würde bei Calc schon das Wiederaufleben der 'Regel' von OOo-Calc Einiges bringen, die da hieß: wir streben für Calc möglichst 100% Kompatibilität der Tabellenfunktionen (gemeint sind 'Formeln') zu MS Excel an, OBWOHL wir für OOo insgesamt _kein_ MSO-Clone sein wollen. Diese Frage der Tabellenfunktionen ist nämlich der maßgebliche Teil wo AOO gegenüber LO zurückgefallen ist und ich sage das OBWOHL ist ein grundsätzlicher Gegner all der Spezial-TabellenFunktionen bin, aber ich muss zur Kenntnis nehmen das die meisten Anwender nicht gerne selbst denken sondern fertige Dinge vor die Nase gesetzt haben wollen. Um bei, solchen Dingen, Einschätzungen richtig treffen zu können bedarf es aber imho essentiell der Hinzuziehung von kompetenten Praktikern. Ich weiß das dazu niemand die Programmierer zwingen kann, und deshalb mache ich darauf nur viral aufmerksam, in der Hoffnung das zu einer freiwilligen Berücksichtigung dieser Dinge führt. - To unsubscribe, e-mail: dev-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-de-h...@openoffice.apache.org
Re: Wie unser Projekt derzeit funktioniert
Jörg, Lass die Userin in Ruhe, die hat gemacht was sie konnte oder wollte. Das hier ist keine Zwangsveranstaltung wie du das so siehst. Meiner Meinung nach bist du in der Verantwortung, genauso wie jeder andere auch den Report zu einem Erfolg zu führen. oooFroum hat das auf seine weise gemacht und du machst das in dem du uns Anpisst. Fein. Aber Wunder dich nicht wenn du dafür auch hart eine Eingeschenkt bekommst. Es wäre stressfreier würdest du einfach im Issue ergänzen was du weißt und den Report verbessern. Es reicht schon wenn du Bidouilles Request Excel Beschreibung ist nicht genug aufnimmst. Und den Report neu eröffnest oder darum bittest wenn du es nicht kannst. Beste Grüße Peter On 08.02.20 10:41, Jörg Schmidt wrote: > Hallo Peter, > >> Ich bin seit 12 Jahren Berater. > Ich, offen gesagt, ähnlich lange und ich habe trotzdem gelegentlich meine Not > mit Kunden für die Computer immer noch etwas Neues sind. Manchmal klappt es > besser und machmal schlechter. > >> Man kann aus dem wie es präsentiert wurde annehmen das es >> sich um ein Support Reqeust handelt > Das war mir nicht aufgefallen und das ist das erste Argument das ich > aktzeptieren kann. > > Anmerkung: ich hatte der Nutzerin gesagt ich werde sie informieren wenn bzw. > sobald ich eine Extension erstellt habe. Ich werde Sie dann dabei auch auf > dieses Faktum, das sie den Issue falsch 'ausgefüllt' hat hinweisen. > (Ich hatte, gegenüber der Nutzerin, bisher weder Verständnis für ihren Ärger > ausgesprochen, noch Kritik für den nicht ausreichend gut formulierten Issue > geäußert. Die Nutzerin weiß im Übrigen sehr wahrscheinlich auch nicht das ich > Projektmitglied bin.) > > > Ich fürchte es bleibt eine nicht restlos geklärte Frage wie wir uns verhalten > sollen bzw. die einen meinen wir verdienten von den Anwendern Respekt weil > wir ihnen kostenlos helfen, die anderen meinen die Anwender verdienen von uns > Respekt weil sie unsere Multiplikatoren sind ... ich glaube diese zwei > Meinungen werden sich immer gegenüberstehen. > >> Ob das zu einem Schaden führt oder >> nicht weiß ich nicht ist mir auch egal. > Ich wiederhole mich: ich habe das getan was wir auf unserer offiziellen > Webseiten gutheißen und ich habe das in überlegter Weise getan. Es ist absurd > mir das als projektschädigendes Verhalten vorzuwerfen. > > Michaels Aussage i.S. es sollen/dürfen keine Feature-Requests in Bugzilla > gestellt werden und/oder ich dürfte als Projektmitglied nicht dazu raten, ist > bei derzeitigem Stand Michaels Privatmeinung. > > Und ich sage auch: ich werde mich selbstverständlich an jede Regel/Absprache > etc. halten, aber dazu muss es diese geben (und sie müssen bei wichtigen > Dingen so verbreitet werden das ich auch Kenntnis habe). > > >> Meine Empfehlung nimm es mit für die Zukunft. Vergangenes >> können wir nicht ändern > Danke für Dein Tun die Wellen zu glätten > > > Gruß > Jörg > > > - > To unsubscribe, e-mail: dev-de-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-de-h...@openoffice.apache.org > - To unsubscribe, e-mail: dev-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-de-h...@openoffice.apache.org
RE: Wie unser Projekt derzeit funktioniert
Hallo Peter, > Ich bin seit 12 Jahren Berater. Ich, offen gesagt, ähnlich lange und ich habe trotzdem gelegentlich meine Not mit Kunden für die Computer immer noch etwas Neues sind. Manchmal klappt es besser und machmal schlechter. > Man kann aus dem wie es präsentiert wurde annehmen das es > sich um ein Support Reqeust handelt Das war mir nicht aufgefallen und das ist das erste Argument das ich aktzeptieren kann. Anmerkung: ich hatte der Nutzerin gesagt ich werde sie informieren wenn bzw. sobald ich eine Extension erstellt habe. Ich werde Sie dann dabei auch auf dieses Faktum, das sie den Issue falsch 'ausgefüllt' hat hinweisen. (Ich hatte, gegenüber der Nutzerin, bisher weder Verständnis für ihren Ärger ausgesprochen, noch Kritik für den nicht ausreichend gut formulierten Issue geäußert. Die Nutzerin weiß im Übrigen sehr wahrscheinlich auch nicht das ich Projektmitglied bin.) Ich fürchte es bleibt eine nicht restlos geklärte Frage wie wir uns verhalten sollen bzw. die einen meinen wir verdienten von den Anwendern Respekt weil wir ihnen kostenlos helfen, die anderen meinen die Anwender verdienen von uns Respekt weil sie unsere Multiplikatoren sind ... ich glaube diese zwei Meinungen werden sich immer gegenüberstehen. > Ob das zu einem Schaden führt oder > nicht weiß ich nicht ist mir auch egal. Ich wiederhole mich: ich habe das getan was wir auf unserer offiziellen Webseiten gutheißen und ich habe das in überlegter Weise getan. Es ist absurd mir das als projektschädigendes Verhalten vorzuwerfen. Michaels Aussage i.S. es sollen/dürfen keine Feature-Requests in Bugzilla gestellt werden und/oder ich dürfte als Projektmitglied nicht dazu raten, ist bei derzeitigem Stand Michaels Privatmeinung. Und ich sage auch: ich werde mich selbstverständlich an jede Regel/Absprache etc. halten, aber dazu muss es diese geben (und sie müssen bei wichtigen Dingen so verbreitet werden das ich auch Kenntnis habe). > Meine Empfehlung nimm es mit für die Zukunft. Vergangenes > können wir nicht ändern Danke für Dein Tun die Wellen zu glätten Gruß Jörg - To unsubscribe, e-mail: dev-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-de-h...@openoffice.apache.org
RE: Wie unser Projekt derzeit funktioniert
Hallo Jörg, Ich bin seit 12 Jahren Berater. Und der Report war grottig. Es war als defekt beschrieben obwohl wäes ein enhancement ist. Er war gegen ein OS gestellt dabei sollte das Feature alle OS ansprechen. Dann schreibt man nich wie Applikation Excel. Wenn ich Excel 2000 habe ist das feature vielleicht nicht enthalten. In 365 kann das feature sich jederzeit ändern. Das ist einfach so nicht professionell oder zufriedenstellend. Man kann aus dem wie es präsentiert wurde annehmen das es sich um ein Support Reqeust handelt und die schließen wir in Bugzilla. Da gibt es keine Ausreden. Ob das zu einem Schaden führt oder nicht weiß ich nicht ist mir auch egal. Ich hätte erwartet das außer mir noch jemand ein Interesse hat das reports einen gewissen allgemeinen Standard genügen. Diese Anforderung stelle ich nicht gegen Gabi sie tut was sie kann, sondern anderen Mitgliedern die es besser wissen müssten. Meine Empfehlung nimm es mit für die Zukunft. Vergangenes können wir nicht ändern Am 7. Februar 2020 18:56:59 MEZ schrieb "Jörg Schmidt" : >Hallo Michael, > >> -Original Message- >> From: Dr. Michael Stehmann [mailto:anw...@rechtsanwalt-stehmann.de] >> Sent: Friday, February 07, 2020 1:32 PM >> To: dev-de@openoffice.apache.org >> Subject: Re: Wie unser Projekt derzeit funktioniert >> >> Hallo, >> >> Am 07.02.20 um 11:57 schrieb Jörg Schmidt: >> > Nachtrag >> > >> > >> > Hallo Michael, >> > >> > ich habe gerade übersehen das Du 'in Deinem eigenen Thread' >> geantwortet hast, denn sonst hätte ich das gleich geschrieben: >> > >> > Du hast mich projektschädigendem Verhalten beschuldigt, ich >> bitte Dich diese Aussage zu überdenken und entsprechend >klarzustellen. >> >> Das Ergebnis war objektiv projektschädigend. > >Dagegen verwahre ich mich. Insbesondere auch deshalb weil ich als >Committer Verpflichtungen gegenüber dem Projekt eingegangen bin, die >ich ernst mehme und die ich mir nicht durch eine unüberlegte Bemerkung >in Frage stellen lasse. > >Ich wiedehole das ich nicht das Projekt dadurch schädigen kann, das ich >etwas tue wozu auf unseren Seiten extra aufgefordert wird und ich hatte >festgestellt das die diesbezüglich genannte Seite inhaltlich aktuell >ware und ich mir sehr wohl bewusst über uneere Kapazitäten bin und >deshalb nun auch keineswegs einen Aufruf im Sinne 'schreibt mehr >Feature-Requests' verfasst habe, sondern nichtöffentlich einer >einzelnen Nutzerin einen Rat gegeben habe. > > > >Ich will aber gerne in Ruhe auf die anderen Dinge eingehen: > >> Ich gehe bis auf Weiteres davon aus, dass Dir die Folgen nicht vor >den >> Augen standen, als Du die Nutzerin animiert hast, einen >Featurerequest >> zu formulieren. > >doch, mir standen 'die Folgen' vor Augen und es lag überhaupt kein >Grund vor diese Folgen, die pro Jahr Dutzende (?) treffen nun gerade >hier als Hinderungsgrund zu sehen. > >> Es war daher objektiv absehbar, dass die Nutzerin, die sich >> der Mühe der >> Formulierung eines Featurerequest unterzogen hatte, >> enttäuscht werden würde. > >Nein, das war es nicht, denn was eigentlich zu erwarten war, war das >der Issue, wie hunderte Andere, in Ruhe dahindämmern würde, weil >einfach nicht genügend Leute da sind issues auch nur rein >'verwaltungstechnisch' zuverlässig und zeitnah zu bearbeiten. > >Das war aber, wennn auch etwas gemildert, schon bei OOo der Fall und >die Lage war eindeutig: man rief trotzdem zu Issues auf weil auch >Issues die man nicht richtig bearbeiten kann/konnte als allgemein >wichtige Quelle für Anregungen galten. > >> Ich muss leider - ebenfalls bis auf Weiteres - wohl davon >> ausgehen, dass >> Du die Verantwortung hierfür bei dem siehst, der der Nutzerin >> geantwortet hat. > >Dann stelle ich hiermit fest das ich bei demjenigen keine besondere >Verantwortung oder Schuld sehe sondern einzig seine Antwort nicht >höflich fand und die Tatsache das er darauf verwies kein MSO und/oder >Excel zu haben peinlich (oder lächerlich). >Wenn Du jetzt noch zur Verteidigung vorbringst das das Problem an der >deutschen Sprache lag, bin ich sprachlos - klar, kann nicht jeder >deutsch, aber man muss dieses Argument nicht überziehen bei einem >Dialog den man auch ohne Sprachkenntnisse deuten kann. > >Oder anders gesagt: wäre es nicht vernünftig das sich im Zweifel jemand >der vom Thema eines Issues keine Ahnung hat, vielleicht zurückhält? >Oder ist selbst dieser Hinweis nun schon wieder provokant? > >> Ok, man mag die Antwort daher als etwas voreilig ansehen. Was >> wäre aber >> die Alternative gewesen? > &
RE: Wie unser Projekt derzeit funktioniert
Hallo Michael, > -Original Message- > From: Dr. Michael Stehmann [mailto:anw...@rechtsanwalt-stehmann.de] > Sent: Friday, February 07, 2020 1:32 PM > To: dev-de@openoffice.apache.org > Subject: Re: Wie unser Projekt derzeit funktioniert > > Hallo, > > Am 07.02.20 um 11:57 schrieb Jörg Schmidt: > > Nachtrag > > > > > > Hallo Michael, > > > > ich habe gerade übersehen das Du 'in Deinem eigenen Thread' > geantwortet hast, denn sonst hätte ich das gleich geschrieben: > > > > Du hast mich projektschädigendem Verhalten beschuldigt, ich > bitte Dich diese Aussage zu überdenken und entsprechend klarzustellen. > > Das Ergebnis war objektiv projektschädigend. Dagegen verwahre ich mich. Insbesondere auch deshalb weil ich als Committer Verpflichtungen gegenüber dem Projekt eingegangen bin, die ich ernst mehme und die ich mir nicht durch eine unüberlegte Bemerkung in Frage stellen lasse. Ich wiedehole das ich nicht das Projekt dadurch schädigen kann, das ich etwas tue wozu auf unseren Seiten extra aufgefordert wird und ich hatte festgestellt das die diesbezüglich genannte Seite inhaltlich aktuell ware und ich mir sehr wohl bewusst über uneere Kapazitäten bin und deshalb nun auch keineswegs einen Aufruf im Sinne 'schreibt mehr Feature-Requests' verfasst habe, sondern nichtöffentlich einer einzelnen Nutzerin einen Rat gegeben habe. Ich will aber gerne in Ruhe auf die anderen Dinge eingehen: > Ich gehe bis auf Weiteres davon aus, dass Dir die Folgen nicht vor den > Augen standen, als Du die Nutzerin animiert hast, einen Featurerequest > zu formulieren. doch, mir standen 'die Folgen' vor Augen und es lag überhaupt kein Grund vor diese Folgen, die pro Jahr Dutzende (?) treffen nun gerade hier als Hinderungsgrund zu sehen. > Es war daher objektiv absehbar, dass die Nutzerin, die sich > der Mühe der > Formulierung eines Featurerequest unterzogen hatte, > enttäuscht werden würde. Nein, das war es nicht, denn was eigentlich zu erwarten war, war das der Issue, wie hunderte Andere, in Ruhe dahindämmern würde, weil einfach nicht genügend Leute da sind issues auch nur rein 'verwaltungstechnisch' zuverlässig und zeitnah zu bearbeiten. Das war aber, wennn auch etwas gemildert, schon bei OOo der Fall und die Lage war eindeutig: man rief trotzdem zu Issues auf weil auch Issues die man nicht richtig bearbeiten kann/konnte als allgemein wichtige Quelle für Anregungen galten. > Ich muss leider - ebenfalls bis auf Weiteres - wohl davon > ausgehen, dass > Du die Verantwortung hierfür bei dem siehst, der der Nutzerin > geantwortet hat. Dann stelle ich hiermit fest das ich bei demjenigen keine besondere Verantwortung oder Schuld sehe sondern einzig seine Antwort nicht höflich fand und die Tatsache das er darauf verwies kein MSO und/oder Excel zu haben peinlich (oder lächerlich). Wenn Du jetzt noch zur Verteidigung vorbringst das das Problem an der deutschen Sprache lag, bin ich sprachlos - klar, kann nicht jeder deutsch, aber man muss dieses Argument nicht überziehen bei einem Dialog den man auch ohne Sprachkenntnisse deuten kann. Oder anders gesagt: wäre es nicht vernünftig das sich im Zweifel jemand der vom Thema eines Issues keine Ahnung hat, vielleicht zurückhält? Oder ist selbst dieser Hinweis nun schon wieder provokant? > Ok, man mag die Antwort daher als etwas voreilig ansehen. Was > wäre aber > die Alternative gewesen? Wenn wir unsere Arbei koordinieren würden, gäbe es Zuständigkeiten für bestimmte Issue-Bereiche bzw. weil uns dafür das Personal fehlt z.B. eine simple Liste worauf Personen eingetragen sind die für bestimmte Bereiche kompentent sind und wo jeder nachschlagen kann (ohne die Leute kennen zu müssen) und dann kurz eine Email schreiben könnte: 'Hallo Jörg, Du bist doch Calc-Experte. Hier ist eine Nutzerin die irgendeine Sortierung von Excel auch in Calc haben will, ich verstehe das nicht ganz, schau doch Du bitte mal auf den Issue.' Die Reaktionszeit auf den Issue war äußerst vorbildlich, vielleicht hat diese Schnellingkeit zu einer weniger guten Antwort (wie ich meine) beigetragen. > In fachlicher Hinsicht hast Du bei mir weiterhin einen ausgezeichneten > Ruf. Michael, bitte, ich habe gesagt das mir meine Verpflichtungen als Committer in den Sinn kamen und ich möchte nicht einen Ruf erlangen der da hiesse ich halte mich nicht daran. Ebenso lesen auch Auftraggeber gelegentlich unsere Listen ... > 1. Zu überlegen, ob der Wunsch durch eine Extension erfüllt > werden kann. Ich habs überlegt, ich habe sogar gestern schon angefangen zu programmieren. In Starbasic kann ich einen Teil der Anforderungen optimal umsetzen, einen anderen aber nicht. Für Letzteres wäre zumindest Java, C++ nötig, die ich nicht kann. Sollte eine Extension fertig werden, so werde
RE: Wie unser Projekt derzeit funktioniert
Hallo Peter, > -Original Message- > From: Peter Kovacs [mailto:pe...@apache.org] > Sent: Friday, February 07, 2020 2:04 PM > To: dev-de@openoffice.apache.org > Subject: Re: Wie unser Projekt derzeit funktioniert > Aber ich bin offen wenn wir das ausprobieren wollen. Mit oder ohne > Plattform. (Obwohl lieber mit) Andere sind bei unkonventionellen Dingen leider weniger offen ... Ich fände z.B. wir könnten die Möglichkeiten nutzen die uns die Tatsache bietet das wir als ein Apache-Projekt Teil einer großen Apache-Gemeinschaft sind und ich annehme das sich die Leute auch projektübergreifend helfen würden. Andere finden schon diesen Vorschlag eine schlechte Idee. Warum entzieht sich meinem Verständnis. Gruß Jörg - To unsubscribe, e-mail: dev-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-de-h...@openoffice.apache.org
RE: Wie unser Projekt derzeit funktioniert
Hallo, > -Original Message- > From: Dave [mailto:davepo...@gmail.com] > Sent: Friday, February 07, 2020 1:53 PM > To: dev-de > Subject: Re: Wie unser Projekt derzeit funktioniert > > Ich stelle mir die Frage, ob es nicht möglich wäre, in Form von > Kooperationen mit Informatik-Fachbereichen bei Bachelor- oder > Masterarbeiten neue Programmiererinnen für AAO zu gewinnen? Allein die > Suche nach diesen wäre so eine Art Werbekampagne. Lg, Dave Bezüglich Praktika hatte ich das Gleiche vor Jahren in Zusammenhang mit der Vereinsidee vorgeschlagen, weoil es schon beim OOoDeV Thema war, da jedoch nicht umgesetzt wurde. Etwas hingegen nur Ähnliches hatte ich, vor einigen Monaten, offlist, hinsichtlich Mitarbeitern für Dokumentation, vorgeschlagen und jemanden um etwas Kontaktanbahnung gebeten und aus dem Ganzen entstand ein Streit und infolge reden wir nicht mehr miteinander. Für mich wieder eine völlig unverständliche Situation. Gruß Jörg - To unsubscribe, e-mail: dev-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-de-h...@openoffice.apache.org
Re: Wie unser Projekt derzeit funktioniert
Hallo, auch hier wären Extensionen ein Ansatz: Der oder die Studierende muss sich nicht in den Core-Code einarbeiten, sondern in "nur" in die API. Man ist freier in der Wahl der Programmiersprache und der Lizenz. Man bekommt eher etwas "Abgeschlossenes" in kalkulierbarer Zeit geschaffen. Beispiele aus der SUN-Zeit, wo noch eine intensivere Betreuung möglich war, zeigen, dass der Zeitaufwand einer Entwicklung im Core-Code auf den ersten Blick leicht unterschätzt wird. Und andere müssen dann nicht nach einiger Zeit, wenn die Interessen des studentischen Entwicklers oder der studentischen Entwicklerin längst andere sind, den Code pflegen. Gruß Michael signature.asc Description: OpenPGP digital signature
Re: Wie unser Projekt derzeit funktioniert
Hi Dave, Also wir haben etwa alle 3 Monate jemanden der schreibt er würde gerne mitmachen. Wir sagen dann so den ersten Schritt den man machen kann. Versuchen dann einzuordnen. Und dann muss der Interessierte dann was tun. Und das funktioniert dann nicht. Ich glaube wenn man mehr nach haken würde und Bauchpinselt dann passiert mehr. Aktuell sind aber alle aktiven mit anderen Dingen beschäftigt oder werden ständig abgelenkt. Ich will zum Beispiel eine Freiwillige anschreiben, welche mir gesagt hat sie würde gerne mitmachen. Ich bin aber die letzten 2 Wochen nicht dazu gekommen. So wie andere Sachen auch liegen bleiben. Wenn wir herausfinden wie wir interessierte auch an der Stange halten können wir nach Multiplikatoren suchen. Wir brauchen auch aufgaben. Auch diese müssen vorbereitet werden. Auch hier mangelt es. Aktuell müssen Neulinge (dazu zähle ich mich auch noch) viel in Eigenarbeit sich erarbeiten. Weiß nicht ob das so Studie Freundlich ist. Ich hätte das damals als ich an der Hochschule war zumindest nicht gemacht. Aber ich bin offen wenn wir das ausprobieren wollen. Mit oder ohne Plattform. (Obwohl lieber mit) Beste Grüße Peter On 07.02.20 13:53, Dave wrote: > Ich stelle mir die Frage, ob es nicht möglich wäre, in Form von > Kooperationen mit Informatik-Fachbereichen bei Bachelor- oder > Masterarbeiten neue Programmiererinnen für AAO zu gewinnen? Allein die > Suche nach diesen wäre so eine Art Werbekampagne. Lg, Dave > > On Fri, Feb 7, 2020 at 1:46 PM Peter Kovacs wrote: > >> Hallo, >> >> >> Kurze Ergänzung zum Thema Bugzilla im Allgemeinen: >> >> 1) support requests sollten im Forum gelöst werden. Deswegen wäre meine >> Empfhelung den Link der Foumsdiskussion zu posten. Selbst wenn er nicht >> in english ist. >> >> 2) Reuirements sollten nicht Abhängigkeiten auf externe Quellen haben. >> Die liegen außerhalb unseres Einflusses und können sich ändern. Also >> Feature wie Applikation XYZ ist eine sehr schwache Beschreibung. >> >> Muss auf jedenfalls ergänzt werden. >> >> 3) Man kann auch selber ergänzen. Selbst wenn man nicht glaubt das >> daraus was wird. Weil gerade dieses Sortierbeispiel ist vielleicht auch >> etwas das ein Junior OO Entwickler in angriff nehmen kann. >> >> Deswegen würde ich solche Requests auch nie per se abschreiben. Wir >> müssen uns aber darüber bewusster werden, und mehr Informationen >> anfügen, damit wir sie Anfängern geben können. >> >> >> Beste Grüße >> >> Peter >> >> On 07.02.20 13:32, Dr. Michael Stehmann wrote: >>> Hallo, >>> >>> Am 07.02.20 um 11:57 schrieb Jörg Schmidt: Nachtrag Hallo Michael, ich habe gerade übersehen das Du 'in Deinem eigenen Thread' geantwortet >> hast, denn sonst hätte ich das gleich geschrieben: Du hast mich projektschädigendem Verhalten beschuldigt, ich bitte Dich >> diese Aussage zu überdenken und entsprechend klarzustellen. >>> Das Ergebnis war objektiv projektschädigend. >>> >>> Du hast den Vorgang wie folgt geschildert: >>> >>> "Ich gab also den Rat doch bitte bei uns im Bugtracker eine >>> Feature-Request zu formulieren, obwohl ich wenig Hoffnung hatte das die >>> Nutzeriun sich diese Mühe machen würde. >>> >>> Sie machte sich aber die Mühe (#128278)." >>> >>> Ich gehe bis auf Weiteres davon aus, dass Dir die Folgen nicht vor den >>> Augen standen, als Du die Nutzerin animiert hast, einen Featurerequest >>> zu formulieren. >>> >>> Du konntest aber objektiv nicht davon ausgehen, dass ein Entwickler >>> diesen Request im Sinne der Nutzerin bearbeiten würde. Oder hast Du mit >>> einem Entwickler kommuniziert und ihm dieses Feature "an's Herz gelegt"? >>> >>> Daher habe ich ja auch geschrieben: >>> >>> "Damit Du das zukünftig vermeiden kannst, noch ein paar Informationen:" >>> >>> Es war daher objektiv absehbar, dass die Nutzerin, die sich der Mühe der >>> Formulierung eines Featurerequest unterzogen hatte, enttäuscht werden >> würde. >>> Ich muss leider - ebenfalls bis auf Weiteres - wohl davon ausgehen, dass >>> Du die Verantwortung hierfür bei dem siehst, der der Nutzerin >>> geantwortet hat. Du schriebst nämlich: >>> >>> "2. Wie kann man nur eine solche Antwort geben?" >>> >>> Ich gebe hierzu folgendes zu bedenken: Einem in englischer Sprache >>> verfassten Report war ein Screenshot beigefügt, dessen Texte in >>> deutscher Sprache waren. Man kann und sollte aber nicht davon ausgehen, >>> dass alle im Projekt der deutschen Sprache mächtig sind. >>> >>> Ok, man mag die Antwort daher als etwas voreilig ansehen. Was wäre aber >>> die Alternative gewesen? Hätte oooforum (fr) (offenbar ein Franzose) ein >>> "need more information" schreiben sollen? Dann hätte er in der Nutzerin >>> aber nur die Hoffnung auf die Umsetzung ihres Wunsches verstärkt und >>> damit wohl auch ihre finale Enttäuschung. >>> Zum Einen weil es hier um meine Person und meinen Ruf geht, und zwar >> auch über das Projekt hinaus. >>> In fachlicher Hinsicht hast Du bei mir weiterhin einen ausgezeichneten >>> Ruf. Ic
Re: Wie unser Projekt derzeit funktioniert
Ich stelle mir die Frage, ob es nicht möglich wäre, in Form von Kooperationen mit Informatik-Fachbereichen bei Bachelor- oder Masterarbeiten neue Programmiererinnen für AAO zu gewinnen? Allein die Suche nach diesen wäre so eine Art Werbekampagne. Lg, Dave On Fri, Feb 7, 2020 at 1:46 PM Peter Kovacs wrote: > Hallo, > > > Kurze Ergänzung zum Thema Bugzilla im Allgemeinen: > > 1) support requests sollten im Forum gelöst werden. Deswegen wäre meine > Empfhelung den Link der Foumsdiskussion zu posten. Selbst wenn er nicht > in english ist. > > 2) Reuirements sollten nicht Abhängigkeiten auf externe Quellen haben. > Die liegen außerhalb unseres Einflusses und können sich ändern. Also > Feature wie Applikation XYZ ist eine sehr schwache Beschreibung. > > Muss auf jedenfalls ergänzt werden. > > 3) Man kann auch selber ergänzen. Selbst wenn man nicht glaubt das > daraus was wird. Weil gerade dieses Sortierbeispiel ist vielleicht auch > etwas das ein Junior OO Entwickler in angriff nehmen kann. > > Deswegen würde ich solche Requests auch nie per se abschreiben. Wir > müssen uns aber darüber bewusster werden, und mehr Informationen > anfügen, damit wir sie Anfängern geben können. > > > Beste Grüße > > Peter > > On 07.02.20 13:32, Dr. Michael Stehmann wrote: > > Hallo, > > > > Am 07.02.20 um 11:57 schrieb Jörg Schmidt: > >> Nachtrag > >> > >> > >> Hallo Michael, > >> > >> ich habe gerade übersehen das Du 'in Deinem eigenen Thread' geantwortet > hast, denn sonst hätte ich das gleich geschrieben: > >> > >> Du hast mich projektschädigendem Verhalten beschuldigt, ich bitte Dich > diese Aussage zu überdenken und entsprechend klarzustellen. > > Das Ergebnis war objektiv projektschädigend. > > > > Du hast den Vorgang wie folgt geschildert: > > > > "Ich gab also den Rat doch bitte bei uns im Bugtracker eine > > Feature-Request zu formulieren, obwohl ich wenig Hoffnung hatte das die > > Nutzeriun sich diese Mühe machen würde. > > > > Sie machte sich aber die Mühe (#128278)." > > > > Ich gehe bis auf Weiteres davon aus, dass Dir die Folgen nicht vor den > > Augen standen, als Du die Nutzerin animiert hast, einen Featurerequest > > zu formulieren. > > > > Du konntest aber objektiv nicht davon ausgehen, dass ein Entwickler > > diesen Request im Sinne der Nutzerin bearbeiten würde. Oder hast Du mit > > einem Entwickler kommuniziert und ihm dieses Feature "an's Herz gelegt"? > > > > Daher habe ich ja auch geschrieben: > > > > "Damit Du das zukünftig vermeiden kannst, noch ein paar Informationen:" > > > > Es war daher objektiv absehbar, dass die Nutzerin, die sich der Mühe der > > Formulierung eines Featurerequest unterzogen hatte, enttäuscht werden > würde. > > > > Ich muss leider - ebenfalls bis auf Weiteres - wohl davon ausgehen, dass > > Du die Verantwortung hierfür bei dem siehst, der der Nutzerin > > geantwortet hat. Du schriebst nämlich: > > > > "2. Wie kann man nur eine solche Antwort geben?" > > > > Ich gebe hierzu folgendes zu bedenken: Einem in englischer Sprache > > verfassten Report war ein Screenshot beigefügt, dessen Texte in > > deutscher Sprache waren. Man kann und sollte aber nicht davon ausgehen, > > dass alle im Projekt der deutschen Sprache mächtig sind. > > > > Ok, man mag die Antwort daher als etwas voreilig ansehen. Was wäre aber > > die Alternative gewesen? Hätte oooforum (fr) (offenbar ein Franzose) ein > > "need more information" schreiben sollen? Dann hätte er in der Nutzerin > > aber nur die Hoffnung auf die Umsetzung ihres Wunsches verstärkt und > > damit wohl auch ihre finale Enttäuschung. > > > >> Zum Einen weil es hier um meine Person und meinen Ruf geht, und zwar > auch über das Projekt hinaus. > > In fachlicher Hinsicht hast Du bei mir weiterhin einen ausgezeichneten > > Ruf. Ich hoffe, ich muss das, was ich hierzu in den vergangenen Tagen > > geschrieben habe, nicht wiederholen, um dies zu belegen. > > > > Hervorzuheben ist auch Dein großer Eifer beim Usersupport und > > bemerkenswert Deine emotionale Beziehung zu unserem Projekt. > > > >> Zum Zweiten weil es um die Sachfrage geht wie mit Feature-Requests > verfahren werden soll. > > Mein Vorschlag wäre: > > > > 1. Zu überlegen, ob der Wunsch durch eine Extension erfüllt werden kann. > > Es war eigentlich schon immer "Politik" im Projekt, Extensions, wenn es > > eben geht, insoweit zu bevorzugen, wofür es auch gute Gründe gibt, die > > ich Dir sicherlich nicht zu erklären brauche. Das schließt nicht aus, > > dass ein Feature, dass durch eine Extension realisiert wurde, "bei > > Bewährung" (und brauchbarer Lizenz) dann irgendeinmal auch im Core-Code > > landet. > > > > Ein Beispiel ist Loook: Natürlich wäre es schön und nützlich, eine > > Volltextsuche in AOO zu haben, die ganze Verzeichnisbäume durchsuchen > > kann. Das wurde aber schon zu SUN-Zeiten nicht realisiert. Stattdessen > > gibt es ein kleines Python-Programm, welches dieses Feature verwirklicht > > und das unabhängig von OOo und AOO (und LO) gepflegt werden kann. Klar > > erfüllt es
Re: Wie unser Projekt derzeit funktioniert
Hallo, Kurze Ergänzung zum Thema Bugzilla im Allgemeinen: 1) support requests sollten im Forum gelöst werden. Deswegen wäre meine Empfhelung den Link der Foumsdiskussion zu posten. Selbst wenn er nicht in english ist. 2) Reuirements sollten nicht Abhängigkeiten auf externe Quellen haben. Die liegen außerhalb unseres Einflusses und können sich ändern. Also Feature wie Applikation XYZ ist eine sehr schwache Beschreibung. Muss auf jedenfalls ergänzt werden. 3) Man kann auch selber ergänzen. Selbst wenn man nicht glaubt das daraus was wird. Weil gerade dieses Sortierbeispiel ist vielleicht auch etwas das ein Junior OO Entwickler in angriff nehmen kann. Deswegen würde ich solche Requests auch nie per se abschreiben. Wir müssen uns aber darüber bewusster werden, und mehr Informationen anfügen, damit wir sie Anfängern geben können. Beste Grüße Peter On 07.02.20 13:32, Dr. Michael Stehmann wrote: > Hallo, > > Am 07.02.20 um 11:57 schrieb Jörg Schmidt: >> Nachtrag >> >> >> Hallo Michael, >> >> ich habe gerade übersehen das Du 'in Deinem eigenen Thread' geantwortet >> hast, denn sonst hätte ich das gleich geschrieben: >> >> Du hast mich projektschädigendem Verhalten beschuldigt, ich bitte Dich diese >> Aussage zu überdenken und entsprechend klarzustellen. > Das Ergebnis war objektiv projektschädigend. > > Du hast den Vorgang wie folgt geschildert: > > "Ich gab also den Rat doch bitte bei uns im Bugtracker eine > Feature-Request zu formulieren, obwohl ich wenig Hoffnung hatte das die > Nutzeriun sich diese Mühe machen würde. > > Sie machte sich aber die Mühe (#128278)." > > Ich gehe bis auf Weiteres davon aus, dass Dir die Folgen nicht vor den > Augen standen, als Du die Nutzerin animiert hast, einen Featurerequest > zu formulieren. > > Du konntest aber objektiv nicht davon ausgehen, dass ein Entwickler > diesen Request im Sinne der Nutzerin bearbeiten würde. Oder hast Du mit > einem Entwickler kommuniziert und ihm dieses Feature "an's Herz gelegt"? > > Daher habe ich ja auch geschrieben: > > "Damit Du das zukünftig vermeiden kannst, noch ein paar Informationen:" > > Es war daher objektiv absehbar, dass die Nutzerin, die sich der Mühe der > Formulierung eines Featurerequest unterzogen hatte, enttäuscht werden würde. > > Ich muss leider - ebenfalls bis auf Weiteres - wohl davon ausgehen, dass > Du die Verantwortung hierfür bei dem siehst, der der Nutzerin > geantwortet hat. Du schriebst nämlich: > > "2. Wie kann man nur eine solche Antwort geben?" > > Ich gebe hierzu folgendes zu bedenken: Einem in englischer Sprache > verfassten Report war ein Screenshot beigefügt, dessen Texte in > deutscher Sprache waren. Man kann und sollte aber nicht davon ausgehen, > dass alle im Projekt der deutschen Sprache mächtig sind. > > Ok, man mag die Antwort daher als etwas voreilig ansehen. Was wäre aber > die Alternative gewesen? Hätte oooforum (fr) (offenbar ein Franzose) ein > "need more information" schreiben sollen? Dann hätte er in der Nutzerin > aber nur die Hoffnung auf die Umsetzung ihres Wunsches verstärkt und > damit wohl auch ihre finale Enttäuschung. > >> Zum Einen weil es hier um meine Person und meinen Ruf geht, und zwar auch >> über das Projekt hinaus. > In fachlicher Hinsicht hast Du bei mir weiterhin einen ausgezeichneten > Ruf. Ich hoffe, ich muss das, was ich hierzu in den vergangenen Tagen > geschrieben habe, nicht wiederholen, um dies zu belegen. > > Hervorzuheben ist auch Dein großer Eifer beim Usersupport und > bemerkenswert Deine emotionale Beziehung zu unserem Projekt. > >> Zum Zweiten weil es um die Sachfrage geht wie mit Feature-Requests verfahren >> werden soll. > Mein Vorschlag wäre: > > 1. Zu überlegen, ob der Wunsch durch eine Extension erfüllt werden kann. > Es war eigentlich schon immer "Politik" im Projekt, Extensions, wenn es > eben geht, insoweit zu bevorzugen, wofür es auch gute Gründe gibt, die > ich Dir sicherlich nicht zu erklären brauche. Das schließt nicht aus, > dass ein Feature, dass durch eine Extension realisiert wurde, "bei > Bewährung" (und brauchbarer Lizenz) dann irgendeinmal auch im Core-Code > landet. > > Ein Beispiel ist Loook: Natürlich wäre es schön und nützlich, eine > Volltextsuche in AOO zu haben, die ganze Verzeichnisbäume durchsuchen > kann. Das wurde aber schon zu SUN-Zeiten nicht realisiert. Stattdessen > gibt es ein kleines Python-Programm, welches dieses Feature verwirklicht > und das unabhängig von OOo und AOO (und LO) gepflegt werden kann. Klar > erfüllt es nicht alle Wünsche (beispielweise die Markierung der Funde im > Text), aber es ist wohl ganz brauchbar. > > 2. In jedem Fall - möglichst mit dem Nutzer zusammen - eine detaillierte > Spezifikation zu erstellen. > > 3. Zu überlegen, ob man das Feature selbst realisieren kann. Wenn nicht, > dann: > > $. Jemanden, der den Wunsch vielleicht so oder so erfüllen könnte, die > Angelegenheit unter Hinweis auf die praktische Bedeutung des erbetenen > Features "ans Herz" zu legen. > > Gruß > Michael > > --
Re: Wie unser Projekt derzeit funktioniert
Hallo, Am 07.02.20 um 11:57 schrieb Jörg Schmidt: > Nachtrag > > > Hallo Michael, > > ich habe gerade übersehen das Du 'in Deinem eigenen Thread' geantwortet hast, > denn sonst hätte ich das gleich geschrieben: > > Du hast mich projektschädigendem Verhalten beschuldigt, ich bitte Dich diese > Aussage zu überdenken und entsprechend klarzustellen. Das Ergebnis war objektiv projektschädigend. Du hast den Vorgang wie folgt geschildert: "Ich gab also den Rat doch bitte bei uns im Bugtracker eine Feature-Request zu formulieren, obwohl ich wenig Hoffnung hatte das die Nutzeriun sich diese Mühe machen würde. Sie machte sich aber die Mühe (#128278)." Ich gehe bis auf Weiteres davon aus, dass Dir die Folgen nicht vor den Augen standen, als Du die Nutzerin animiert hast, einen Featurerequest zu formulieren. Du konntest aber objektiv nicht davon ausgehen, dass ein Entwickler diesen Request im Sinne der Nutzerin bearbeiten würde. Oder hast Du mit einem Entwickler kommuniziert und ihm dieses Feature "an's Herz gelegt"? Daher habe ich ja auch geschrieben: "Damit Du das zukünftig vermeiden kannst, noch ein paar Informationen:" Es war daher objektiv absehbar, dass die Nutzerin, die sich der Mühe der Formulierung eines Featurerequest unterzogen hatte, enttäuscht werden würde. Ich muss leider - ebenfalls bis auf Weiteres - wohl davon ausgehen, dass Du die Verantwortung hierfür bei dem siehst, der der Nutzerin geantwortet hat. Du schriebst nämlich: "2. Wie kann man nur eine solche Antwort geben?" Ich gebe hierzu folgendes zu bedenken: Einem in englischer Sprache verfassten Report war ein Screenshot beigefügt, dessen Texte in deutscher Sprache waren. Man kann und sollte aber nicht davon ausgehen, dass alle im Projekt der deutschen Sprache mächtig sind. Ok, man mag die Antwort daher als etwas voreilig ansehen. Was wäre aber die Alternative gewesen? Hätte oooforum (fr) (offenbar ein Franzose) ein "need more information" schreiben sollen? Dann hätte er in der Nutzerin aber nur die Hoffnung auf die Umsetzung ihres Wunsches verstärkt und damit wohl auch ihre finale Enttäuschung. > > Zum Einen weil es hier um meine Person und meinen Ruf geht, und zwar auch > über das Projekt hinaus. In fachlicher Hinsicht hast Du bei mir weiterhin einen ausgezeichneten Ruf. Ich hoffe, ich muss das, was ich hierzu in den vergangenen Tagen geschrieben habe, nicht wiederholen, um dies zu belegen. Hervorzuheben ist auch Dein großer Eifer beim Usersupport und bemerkenswert Deine emotionale Beziehung zu unserem Projekt. > Zum Zweiten weil es um die Sachfrage geht wie mit Feature-Requests verfahren > werden soll. Mein Vorschlag wäre: 1. Zu überlegen, ob der Wunsch durch eine Extension erfüllt werden kann. Es war eigentlich schon immer "Politik" im Projekt, Extensions, wenn es eben geht, insoweit zu bevorzugen, wofür es auch gute Gründe gibt, die ich Dir sicherlich nicht zu erklären brauche. Das schließt nicht aus, dass ein Feature, dass durch eine Extension realisiert wurde, "bei Bewährung" (und brauchbarer Lizenz) dann irgendeinmal auch im Core-Code landet. Ein Beispiel ist Loook: Natürlich wäre es schön und nützlich, eine Volltextsuche in AOO zu haben, die ganze Verzeichnisbäume durchsuchen kann. Das wurde aber schon zu SUN-Zeiten nicht realisiert. Stattdessen gibt es ein kleines Python-Programm, welches dieses Feature verwirklicht und das unabhängig von OOo und AOO (und LO) gepflegt werden kann. Klar erfüllt es nicht alle Wünsche (beispielweise die Markierung der Funde im Text), aber es ist wohl ganz brauchbar. 2. In jedem Fall - möglichst mit dem Nutzer zusammen - eine detaillierte Spezifikation zu erstellen. 3. Zu überlegen, ob man das Feature selbst realisieren kann. Wenn nicht, dann: $. Jemanden, der den Wunsch vielleicht so oder so erfüllen könnte, die Angelegenheit unter Hinweis auf die praktische Bedeutung des erbetenen Features "ans Herz" zu legen. Gruß Michael signature.asc Description: OpenPGP digital signature
RE: Wie unser Projekt derzeit funktioniert
Nachtrag Hallo Michael, ich habe gerade übersehen das Du 'in Deinem eigenen Thread' geantwortet hast, denn sonst hätte ich das gleich geschrieben: Du hast mich projektschädigendem Verhalten beschuldigt, ich bitte Dich diese Aussage zu überdenken und entsprechend klarzustellen. Zum Einen weil es hier um meine Person und meinen Ruf geht, und zwar auch über das Projekt hinaus. Zum Zweiten weil es um die Sachfrage geht wie mit Feature-Requests verfahren werden soll. Gruß Jörg - To unsubscribe, e-mail: dev-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-de-h...@openoffice.apache.org
RE: Wie unser Projekt derzeit funktioniert
> -Original Message-
> From: Dr. Michael Stehmann [mailto:anw...@rechtsanwalt-stehmann.de]
> Sent: Friday, February 07, 2020 10:46 AM
> To: dev-de@openoffice.apache.org
> Subject: Re: Wie unser Projekt derzeit funktioniert
>
>
> Hallo,
>
> dass das Report-Tool nicht in einem geordneten Verfahren gesichtet und
> bearbeitet wird, liegt einfach daran, dass es keinen gibt,
> der es macht.
>
> Weder der Chair, noch das PMC, noch eine Abstimmung auf der dev können
> irgendjemanden befehlen, sich darum zu kümmern.
>
> Es muss sich ein Freiwilliger, besser sogar eine Gruppe
> finden, der oder
> die diese Aufgabe übernimmt.
>
RICHTIG!
Und seit Jahren denke ich darüber nach mich darum zu kümmern und halte es immer
wieder auf Neue für sinnlos, weil ja jeder Versuch dafür eine tragfähige
Atrbeitsgrundlage zu schaffen niedergemacht würde.
Wer diese Issues bearbeiten würde müsste sich nämlich auf zumindest Folgendes
stützen können:
1.
eine von der Community getragene Absprache zu dem was ich 'Kriterien' nannte
2.
ein mit der Community vereinbartes Verfahren wie die Issues so 'aufgearbeit'
werden können das deren Umsetzung erleichtert bzw. überhaupt möglich wird
3.
eine irgendwie geartete Aussage der Programmierer wie sie sich verhalten werden
genauer gesagt ist das meine Meinung und andere haben ggf. andeere
Notwendigkeiten im Sinn und hierrüber müsste eben beraten und dann ejntschieden
werden.
Issues mehrheitlich für die 'Ablage' zu bearbeiten finde ich nämlich sinnlos
und Anwender anzulügen (indem ich so tue als würden ihre Anliegen ernst
genommen, wissend das das eigentlich nicht stimmt) unethisch.
> Wir sollten weniger fragen, was das Projekt tun oder irgend jemand
> organisieren müsste, sondern jeder Einzelne sollte sich fragen, was er
> tun kann und will.
Dann erkläre Du mir doch am Beispiel Issues wie diese ein Freiwilliger ohne
"Organisation" ("Absprache", "Koordination", ...) in vernünftigerweise
bearbeiten soll.
Erwartest Du den Einreichern der Issues etwas freundlich-unverbindliches zu
schreiben? Erwartest Du, nach Ermessen eines Einzelnen, die Issues zu
kommentieren und ansonsten liegen zu lassen? Erwartest Du das derjenige on-
oder off-List Programmier einzeln anspricht, ob sie Lust hätten diesen oder
jenen Issue abzuarbeiten?
Erwartest Du vor allem, das all diese Dinge rein von Einzelnen subjektiv
entschieden werden sollen, ohne Einflussmöglichkeit der Community als Ganzes?
Einfluss könnte die Community nehmen indem sie Kriterien aufstellt oder
Verfahrensweisen. Wie aber kann es dazu kommen wenn dieses Vorgehen ständig als
nicht erwünscht abgetan wird?
Und ich betone: es geht hier nirgends um Zwang, es geht nur um notwendige
freiwillige Absprachen. Nicht ganz freiwillig ist aber die Einsicht diese
Absprachen überhaupt treffen zu müssen, denn ohne Klarheit kann man nicht
vernünftig arbeiten.
Und einen persönlichen Satz noch:
in der Tat könnte ich mich hinstellen und auf dev mitteilen das ich ab sofort
die issues bearbeite (Motto: WEIL ich die issues bearbeite entscheide
ich, wem das nicht passt der soll doch selbst mitarbeiten)
Das ist zumindest jedoch nicht mein Weg, denn ich will hinreichend wissen das
das was ich tue auch im Einklang mit der Mehrheit der Projekt-Community ist.
Gruß
Jörg
-
To unsubscribe, e-mail: dev-de-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-de-h...@openoffice.apache.org
Re: Wie unser Projekt derzeit funktioniert
Hallo, dass das Report-Tool nicht in einem geordneten Verfahren gesichtet und bearbeitet wird, liegt einfach daran, dass es keinen gibt, der es macht. Weder der Chair, noch das PMC, noch eine Abstimmung auf der dev können irgendjemanden befehlen, sich darum zu kümmern. Es muss sich ein Freiwilliger, besser sogar eine Gruppe finden, der oder die diese Aufgabe übernimmt. So wie es mit den Übersetzungen war: Das Werkzeug war defekt, es gab aber Menschen, die übersetzen wollten, es gab jemanden, dem dieser Missstand auffiel, und dann hat sich eine Freiwillige gefunden, die sich der Aufgabe angenommen hat. Sie hat sich schlicht diesen "Hut" selbst aufgesetzt. Nur so kann es auch mit der QA laufen. Missstände zu benennen ist notwendig, damit sie bekannt werden, aber nicht hinreichend, um sie zu beheben. Wir sollten weniger fragen, was das Projekt tun oder irgend jemand organisieren müsste, sondern jeder Einzelne sollte sich fragen, was er tun kann und will. Gruß Michael signature.asc Description: OpenPGP digital signature
RE: Wie unser Projekt derzeit funktioniert
Hallo Michael, > -Original Message- > From: Dr. Michael Stehmann [mailto:anw...@rechtsanwalt-stehmann.de] > Sent: Thursday, February 06, 2020 8:42 PM > To: dev-de@openoffice.apache.org > Subject: Re: Wie unser Projekt derzeit funktioniert > > Hallo Jörg, > > tut mir leid, aber Dein Rat an die Nutzerin war falsch und für das > Projekt schädlich. > > Du hast sie auflaufen lassen. Siehst Du, sowas geschiet wenn man die Arbeit nicht koordiniert. Selbstverständlich ist mir klar das unsere Ressourcen eng sind, aber genauso war mir keinesfalls bewusst das es irgendeine offizielle oeder informelle Absprache gibt Feature-Issues nicht mehr haben zu wollen. > Damit Du das zukünftig vermeiden kannst, noch ein paar Informationen: > > In der Priorität der wenigen Entwickler, die wir haben, > stehen an erster > Stelle Security-Issues. Von der Bearbeitung erfährt man > jedoch aus guten > Gründen frühestens dann, wenn sie erledigt sind. > > An zweiter Stelle stehen Bug-Fixes und die "Bereinigung" des Codes. > > Erst dann und aus Ressourcenknappheit meist eben nicht überlegt jeder > Entwickler, ob er in der Lage ist, irgendetwas zu verbessern. > > Featurerequests von Nutzern sind daher, wenn es nicht ein > Killerfeature > ist, welches einfach umzusetzen ist, derzeit ohne Aussicht auf > Verwirklichung. Anhand Deiner Antwort scheint es mir so es wäre gewünscht das Anwender keine Feature-Wünsche mehr äußern sollen - stimmt das? Wenn ja, warum führen wir (und nicht etwa nur ich) die Anwender in die Irre wenn wir auf unserer Webseite Anderes sagen, siehe: http://www.openoffice.org/de/dev/pre_submission_de.html und ich BETONE: diese Webseite ist nicht etwa veraltet, sondern seit Übernahme von OO durch die ASF mehrfach überarbeitet worden und es ist öffentlich (Mailingliste) zu dem Inhalt der Überarbeitungen und dem Inhalt der Seite ansich, diskutiert worden. Alles ist also so gelaufen, wie Du es mir gestern noch als richtig darstelltest und nun soll ich schlussfolgern das das was auf dieser Seite steht nicht stimmt, ja sogar schädlich für unserer Projekt ist? > Es ist dann in der Tat für einen erfahrenen Extensionprogrammierer wie > Dich sinnvoller, zu überlegen, ob er eine Extension > entwickeln kann und > will. "Will" ja, "kann" nur eingeschränkt weil ich im konkreten Fall mit Basic nicht an das 'Menü' eines Autofilter in Calc herankomme, was hier für eine bedientechnisch gute Implementierung nötig wäre. > Einen Nutzer auf die Möglichkeit eines Featurerequests zu > verweisen, ist > demgegenüber nicht zielführend und wirkt auf mich unfreundlich sowohl > gegenüber dem Nutzer, als auch den Mitstreitern im Projekt, auf die > damit die Verantwortung und auch Arbeit (Beantwortung des Issues) > abgeschoben wird. siehe obenstehend. Es mag sein das ich auf Mailingliste etwas übersehen könnte, aber wenn ich mir so schwere Vorwürfe anhören muss OBWOHL ich nur das getan habe was wir auf unserer Webseite sagen, dann weiß ich nicht mehr was los ist. Nochmals betone ich ausdrücklich das die konkrete Webseite auch keineswegs veraltet ist und keineswegs der Inhalt irgendwioe 'heimlich' geändert wurde, sondern die überarbeitung _dieser_ Seite in öffentlicher Kenntnisnahme erfolgte. (Im Übrigen kann der Inhalt der Seite auch überhaupt nicht gegen die Interesen unseres Projekts manipuliert worden sein weil dioe Erwünschtheit von Verbesserungsvorschläge dort schon immmer stand und auch nach dem Wechsel von OOo zu AOO nicht irgendwannn zwischenzeitlich entfernt wurde, so das überhaupt die Chance bestanden hätte sie nachträglich 'heimlich' hinzuzufügen.) Und ich schreibe soviel, weil ich Deinen Vorwurf an mich, in einer so klaren Frage, für gänzlich unangemessen halte und weil ich nicht willends bin mich hier für entwas schuldig stempeln zu lassen für das ich nicht die geringste Schuld empfinden kann, sondern sogar unterstreiche der sicheren Meinung zu sein mich richtig verhalten zu haben. (auch hierzu eine Anmerkung: meine Einschätzung wäre etwas anders hätte ich denn in breiter Öffentlichkeit Werbung der Form 'bitte schreibt mehr Feature-Requests' gemacht hätte, jedoch auch das ist nicht der Fall gewesen) Gruß Jörg - To unsubscribe, e-mail: dev-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-de-h...@openoffice.apache.org
RE: Wie unser Projekt derzeit funktioniert, war: Chemnitzer Linux-Tage 2020
Hallo Peter, _bitte_ lies meine Antwort sorgfältig, denn ich nehme an Du verstehst meine Reaktion betreffs des Issues falsch und ich möchte nicht grundlos Streit. > -Original Message- > From: Peter Kovacs [mailto:pe...@apache.org] > Sent: Thursday, February 06, 2020 4:32 PM > To: dev-de@openoffice.apache.org > Subject: Re: Wie unser Projekt derzeit funktioniert, war: > Chemnitzer Linux-Tage 2020 > Ich habe die Infos ergänzt und den Report angepasst. > > Ich weiß nun nicht warum das ich nun machen muss. Du sollst das nicht machen, auch kann ich nicht erkennen das in dem Issue etwas gefehlt hätte, noch habe ich irgendwen aufgefordert etwas zu tun. WIR (das Projekt AOO) fordern unsere Nutzer auf Issues zu schreiben um uns zu helfen, auch für Featurewünsche, dann können wir die die wir zur Hilfe auffordern aber nicht so behandeln wie in dem issue geschehen. (Hinweis: ich selbst hatte die Dateianhänge geprüft (VOR der Antwort von "oooforum") und hatte der Nutzerin mitgeteilt diese seien technisch in Ordnung und ich wisse darüber hinaus nicht warum beim Download ein 'falscher' Name zugeordnet wird, halte das aber für kein Problem, weil projektseitig (AOO) sich Fachleute mit den Issus beschäftigen und diese keine Probleme mit diesen 'technischen Unregelmäßigkeiten' haben würden) > Warum kann > das jemand > anderes dem das viel früher aufgefallen ist nicht tun? z.B. weil es überhaupt keine praktikable Organisation/Absprache oder was auch immer gibt wer für die Betreuung der issues verantwortlich ist und nach welchen 'Kriterien' das erfolgen soll? Und weil ich mich hier, wieder einmal, für den leisesten Versuch über dieses Problem zu reden, angreifen lassen müss? Hinweis: Nein, spziell über Bugzilla habe ich nicht geredet, aber jedem muss doch auffallen das das dazu gehört. z.B. wäre eine konkrete Frage: Wenn in Bugzilla ein Featurewunsch geäußert wird, wie bewerten wir Diesen? Nach welchen Kriterien? Hält es wirklich jemand für zweckmäßig das vom Zufall abhängig zu machen, wer den Issue bearbeitet (wieder meine ich NICHT die Programmierung)? Und BITTE versucht nicht wieder an eine Riesenorganisation oder 'Grundsatzpapiere' zu denken, das alles gab es bei OOo auch nicht, aber ich kann doch wohl nicht annehmen das es gewollt sein könnte das in solchen Fragen allein der Zufall regieren soll. Worum geht/ging es hier? imho gibt es kein geregeltes Verfahren, wie wir issues bearbeiten (und ich meine damit nicht deren Umsetzung, sondern deren Sichtung und Kommunikation mit den Anwendern, sowie irgendeine 'Klassifizierung'/Planung, die im Mindestmaß den Programmierern überhaupt eine einfachen inhaltlichen Überblick ermöglicht, was an issues offen ist oder, im besseren Fall, Grundlagen legt welche Issues wir (als Projekt insgesamt) für wichtig halten und welche weniger, _z.B._ als Entscheidungshilfe für neu zu uns kommende Programmierer Wie sonst willst Du denn das Programm koordiniert weiterentwickeln? Wie sonst willst Du die Leistung Freiwilliger Außenstehender (derer die Bugs melden) wertschätzen, wenn Du nicht weist was Du ihnen antworten sollt, weil einfach keine Abschätzung möglich ist zu den Fragen: Wird ihr Issue überhaupt umgesetzt? Wenn ja, wann ungefähr? > Wovor hast du Angst? Ich habe keine Angst. Ich habe in einem konkreten Einzelfall kritisiert das man mit unseren Anwendern nicht so umgehen sollte wie "oooforum" das im issue getan hat und offen gesagt finde ich es lachhaft bis peinlich in einem freien OFFFICE-Projekt zu äußern man habe nicht einmal den notwendigen technischen Zugang, zu Vergleichszwecken, zu MS Office. Ich rede AN DIESER STELLE, nicht über 'FOSS-Politik', sonderen über praktische Notwendigkeiten. > Oder ist dir das Empören so wichtig? Ich musste mir vor einigen Tagen auf users-de den 'Kopf waschen lassen', weil ich mich unfreundlich gegenüber einem Anwender verhalten hatte. Mich hat das nicht erfreut, aber ich fand es angemessen. Und ich darf annehmen die Community fand es richtig, denn es gab keine Kritik an der Kritik. Rede bitte nicht über "Empörung", wenn wir doch hier einen ähnlichen Fall vor uns haben. Oder ist Höflichkeit nur auf Mailinglisten wichtig, aber nicht in Bugzilla? Gruß Jörg - To unsubscribe, e-mail: dev-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-de-h...@openoffice.apache.org
Re: Wie unser Projekt derzeit funktioniert
Hallo Jörg, tut mir leid, aber Dein Rat an die Nutzerin war falsch und für das Projekt schädlich. Du hast sie auflaufen lassen. Damit Du das zukünftig vermeiden kannst, noch ein paar Informationen: In der Priorität der wenigen Entwickler, die wir haben, stehen an erster Stelle Security-Issues. Von der Bearbeitung erfährt man jedoch aus guten Gründen frühestens dann, wenn sie erledigt sind. An zweiter Stelle stehen Bug-Fixes und die "Bereinigung" des Codes. Erst dann und aus Ressourcenknappheit meist eben nicht überlegt jeder Entwickler, ob er in der Lage ist, irgendetwas zu verbessern. Featurerequests von Nutzern sind daher, wenn es nicht ein Killerfeature ist, welches einfach umzusetzen ist, derzeit ohne Aussicht auf Verwirklichung. Es ist dann in der Tat für einen erfahrenen Extensionprogrammierer wie Dich sinnvoller, zu überlegen, ob er eine Extension entwickeln kann und will. Einen Nutzer auf die Möglichkeit eines Featurerequests zu verweisen, ist demgegenüber nicht zielführend und wirkt auf mich unfreundlich sowohl gegenüber dem Nutzer, als auch den Mitstreitern im Projekt, auf die damit die Verantwortung und auch Arbeit (Beantwortung des Issues) abgeschoben wird. Gruß Michael signature.asc Description: OpenPGP digital signature
Re: Wie unser Projekt derzeit funktioniert, war: Chemnitzer Linux-Tage 2020
Hallo Jörg, Ich habe die Infos ergänzt und den Report angepasst. Ich weiß nun nicht warum das ich nun machen muss. Warum kann das jemand anderes dem das viel früher aufgefallen ist nicht tun? Wovor hast du Angst? Oder ist dir das Empören so wichtig? Beste Grüße Peter On 06.02.20 15:45, Jörg Schmidt wrote: > Hallo Michael, > >> -Original Message- >> From: Dr. Michael Stehmann [mailto:anw...@rechtsanwalt-stehmann.de] >> Sent: Thursday, February 06, 2020 10:58 AM >> To: dev-de@openoffice.apache.org >> Subject: Wie unser Projekt derzeit funktioniert, war: >> Chemnitzer Linux-Tage 2020 >> >> Hallo, >> >> ich möchte einmal (lediglich exemplarisch) von ein paar Dingen >> berichten, an denen ich bestenfalls peripher beteiligt war und bin: >> >> Dabei ging es in erster Linie darum, Entwicklern und anderen >> Beitragenden die Arbeit zu erleichtern: >> >> 1. Wir haben unser Versionskontrollsystem von Subversion auf git >> umgestellt. Dies wird von allen Entwicklern als eine große >> Verbesserung >> betrachtet und zwar auch von denen, die zunächst skeptisch waren. >> >> 2. Der Pootle-Server für die Übersetzungen wurde instand >> gesetzt und ein >> technischer Prozess entwickelt, um zu übersetzende Strings >> kontinuierlich den Übersetzern zur Verfügung zu stellen und >> Übersetzungen kontinuierlich in den Code zu integrieren. >> >> 3. Apache OpenOffice zu bauen, ist alles andere als trivial. Matthias >> hat derzeit die Windows-Build im Griff und begleitet in engem Kontakt >> mit dem dortigen Maintainer die OS/2-Portierung. Um die Mac- und >> Linux-Builds kümmert sich derzeit Jim. Pedro schließlich deckt den >> BSD-Bereich ab. >> >> Mechtilde bemüht sich mit Erfolg, AOO auch unter Debian GNU/Linux mit >> jüngeren Compiler- und Bibliotheksversionen zu bauen (nur vorsorglich: >> an ein Bauen nach Debian-Richtlinien ist derzeit nicht zu >> denken). Diese >> Arbeit ist auch wegweisend für andere Distributionen. >> >> Mechtilde braucht diese Instanz auch für ihre Arbeiten im Rahmen der >> technischen Betreuung des Übersetzungsprozesses (s. u. 2.). > >> [...] >> Natürlich machen wir uns auch recht intensiv Gedanken (und >> tauschen sie >> aus), wie wir die Entwicklerbasis nachhaltig verbreitern >> können. Der IMO >> erfolgversprechendste Vorschlag kam hierzu in letzter Zeit >> von Patricia, >> die mit sehr guter Begründung vorschlug, pensionierte >> C++-Entwickler auf >> unser Projekt aufmerksam zu machen. Aber bis der Same dieser Idee >> Früchte tragen kann, dauert es zwangsläufig etwas. > Danke für diese Informationen. > >> Alle diese Arbeiten wurden "spontan" von interessierten >> Freiwilligen in >> Angriff genommen, ohne dass ein Projektleiter, ein >> Lenkungskomitee, ein >> Scrum-Master oder nur eine Projektplanung existierte. > ... und ohne das Du merkst was Du selbst hier gerade tust. Du führst hier > gerade und Du führst mit Mitteln die das Projekt der Form nach mehrheitlich > aktzeptieren wird. > > Es geht nicht um die Form (in wieviele Varianten mag ich das in den letzten > 10 Jahren wohl verneint haben) sonderen es geht um den Inhalt, und der Inhalt > ist hier das Du: > > darauf aufmerksam machst was da ist und wo man sich anschliessen kann. Damit > hebst Du aber diese Möglichkeiten auch über mögliche Andere hervor und gibst > damit eine Richtung vor ... und das alles ganz ohne Zwang. > > > > Aber lass mich auch noch etwas zu einigen konkreten Dingen sagen: > >> Die Abstimmung unter den Beteiligten läuft in der Regel >> informell. Wenn >> Andrea, Matthias, Mechtilde und Peter auf der FOSDEM in der >> Cafeteria an >> einem Tisch sitzen, reden sie nicht über das Wetter oder die >> Qualitäten >> belgischer Biere, sondern natürlich über das, was sie derzeit tun und >> vorhaben. > Und worum hattest Du mich (und andere) gebeten? Wenn wir uns irgendwo privat > treffen sollen wir doch bitte informieren was wir besprochen haben. > Das hast Du hier und heute getan, ich fürchte nur leider nur zufällig. > > Wir alle sollten uns bewusst sein wie wichtig wechselseitige Informationben > sind, ein Beispiel: > > ich hatte vor Längerer Zeit die Löschung einiger Webseiten kritisiert, das > geschah weil ich sah sie fehlen für den Support. Ich war zu diesem Zeitpunkt > nicht im Mindesten informiert das ein Upgrade des CMS ins Haus steht. > > Folge: > ich treffe aus Unwissenheit eine falsche Entscheidung (und andere ärgern sich > aber schweigen) denn eine Info dazu bekam ich nicht (die konnte ich Monate > später auf der dev zufällig aufschnappen) > >> Die einzige Ausnahme von der Regel informeller Zusammenarbeit war bei >> den genannten Beispielen die Umstellung auf git (s. u. 1.). Hier >> bedurfte es einer Abstimmung im PMC, weil Apache-Infra zu involvieren >> war und weil es um eine Migration weg von der Software eines anderen >> Apache-Projektes ging. > das war dann offensichtlich eine formelle Abstimmung und die andere Genannten > waren informell, die Summe aller bleibt "Abstimmmung
RE: Wie unser Projekt derzeit funktioniert, war: Chemnitzer Linux-Tage 2020
Hallo Michael, > -Original Message- > From: Dr. Michael Stehmann [mailto:anw...@rechtsanwalt-stehmann.de] > Sent: Thursday, February 06, 2020 10:58 AM > To: dev-de@openoffice.apache.org > Subject: Wie unser Projekt derzeit funktioniert, war: > Chemnitzer Linux-Tage 2020 > > Hallo, > > ich möchte einmal (lediglich exemplarisch) von ein paar Dingen > berichten, an denen ich bestenfalls peripher beteiligt war und bin: > > Dabei ging es in erster Linie darum, Entwicklern und anderen > Beitragenden die Arbeit zu erleichtern: > > 1. Wir haben unser Versionskontrollsystem von Subversion auf git > umgestellt. Dies wird von allen Entwicklern als eine große > Verbesserung > betrachtet und zwar auch von denen, die zunächst skeptisch waren. > > 2. Der Pootle-Server für die Übersetzungen wurde instand > gesetzt und ein > technischer Prozess entwickelt, um zu übersetzende Strings > kontinuierlich den Übersetzern zur Verfügung zu stellen und > Übersetzungen kontinuierlich in den Code zu integrieren. > > 3. Apache OpenOffice zu bauen, ist alles andere als trivial. Matthias > hat derzeit die Windows-Build im Griff und begleitet in engem Kontakt > mit dem dortigen Maintainer die OS/2-Portierung. Um die Mac- und > Linux-Builds kümmert sich derzeit Jim. Pedro schließlich deckt den > BSD-Bereich ab. > > Mechtilde bemüht sich mit Erfolg, AOO auch unter Debian GNU/Linux mit > jüngeren Compiler- und Bibliotheksversionen zu bauen (nur vorsorglich: > an ein Bauen nach Debian-Richtlinien ist derzeit nicht zu > denken). Diese > Arbeit ist auch wegweisend für andere Distributionen. > > Mechtilde braucht diese Instanz auch für ihre Arbeiten im Rahmen der > technischen Betreuung des Übersetzungsprozesses (s. u. 2.). > [...] > Natürlich machen wir uns auch recht intensiv Gedanken (und > tauschen sie > aus), wie wir die Entwicklerbasis nachhaltig verbreitern > können. Der IMO > erfolgversprechendste Vorschlag kam hierzu in letzter Zeit > von Patricia, > die mit sehr guter Begründung vorschlug, pensionierte > C++-Entwickler auf > unser Projekt aufmerksam zu machen. Aber bis der Same dieser Idee > Früchte tragen kann, dauert es zwangsläufig etwas. Danke für diese Informationen. > Alle diese Arbeiten wurden "spontan" von interessierten > Freiwilligen in > Angriff genommen, ohne dass ein Projektleiter, ein > Lenkungskomitee, ein > Scrum-Master oder nur eine Projektplanung existierte. ... und ohne das Du merkst was Du selbst hier gerade tust. Du führst hier gerade und Du führst mit Mitteln die das Projekt der Form nach mehrheitlich aktzeptieren wird. Es geht nicht um die Form (in wieviele Varianten mag ich das in den letzten 10 Jahren wohl verneint haben) sonderen es geht um den Inhalt, und der Inhalt ist hier das Du: darauf aufmerksam machst was da ist und wo man sich anschliessen kann. Damit hebst Du aber diese Möglichkeiten auch über mögliche Andere hervor und gibst damit eine Richtung vor ... und das alles ganz ohne Zwang. Aber lass mich auch noch etwas zu einigen konkreten Dingen sagen: > Die Abstimmung unter den Beteiligten läuft in der Regel > informell. Wenn > Andrea, Matthias, Mechtilde und Peter auf der FOSDEM in der > Cafeteria an > einem Tisch sitzen, reden sie nicht über das Wetter oder die > Qualitäten > belgischer Biere, sondern natürlich über das, was sie derzeit tun und > vorhaben. Und worum hattest Du mich (und andere) gebeten? Wenn wir uns irgendwo privat treffen sollen wir doch bitte informieren was wir besprochen haben. Das hast Du hier und heute getan, ich fürchte nur leider nur zufällig. Wir alle sollten uns bewusst sein wie wichtig wechselseitige Informationben sind, ein Beispiel: ich hatte vor Längerer Zeit die Löschung einiger Webseiten kritisiert, das geschah weil ich sah sie fehlen für den Support. Ich war zu diesem Zeitpunkt nicht im Mindesten informiert das ein Upgrade des CMS ins Haus steht. Folge: ich treffe aus Unwissenheit eine falsche Entscheidung (und andere ärgern sich aber schweigen) denn eine Info dazu bekam ich nicht (die konnte ich Monate später auf der dev zufällig aufschnappen) > Die einzige Ausnahme von der Regel informeller Zusammenarbeit war bei > den genannten Beispielen die Umstellung auf git (s. u. 1.). Hier > bedurfte es einer Abstimmung im PMC, weil Apache-Infra zu involvieren > war und weil es um eine Migration weg von der Software eines anderen > Apache-Projektes ging. das war dann offensichtlich eine formelle Abstimmung und die andere Genannten waren informell, die Summe aller bleibt "Abstimmmung". > Die im Projekt Aktiven erhalten keine Entlohnung und sind freiwillig > ehrenamtlich tätig. In der Regel "bringen sie Geld mit". Sie sind > Begeisterte und das ist IMO die beste Voraussetzung, auch andere zu > begeistern. Aus welchem Grunde schreibt Du das? Du dürftest wissen das wir (also Du und ich) in dieser Frage einer Meinung sind. Was also soll das, offensichtlich doch nur zwischen den Zeilen meinen Vorschlag angreif
