RE: Hilfe (was: Hilfe on de-users)
Hallo Michael, > -Original Message- > From: Dr. Michael Stehmann [mailto:anw...@rechtsanwalt-stehmann.de] > Sent: Tuesday, May 05, 2020 10:57 AM > To: dev-de@openoffice.apache.org > Subject: Re: Hilfe (was: Hilfe on de-users) > > Hallo Jörg, > > ich möchte nur auf einen Punkt eingehen, habe daher Deine Mail nur > auszugsweise zitiert: > > Am 05.05.20 um 05:30 schrieb Jörg Schmidt: > > > NEIN! > > Damals wurde die Richtung von SUN & Co. bestimmt. GENAU DAS > war auch der rationale Grund für erst die unterschwellige > Forderung nach einer Stiftung, die jahrelang in der Community > gärte, und nachfolgend die Umsettzung dessen (=TDF/LO) als > das Verhalten von Oracle einen Anlass bot, weil die Stimmung > der Mehrheit quasi umkippte. > > SUN war immer der "wohlwollende Diktator", dessen Handeln > man deshalb aktzeptierte (teils nnur tolerierte wo man > inhaltlich doch unzufrieden war), Oracle hingegen war nicht > mehr wohlwollend (oder wurde nicht so empfunden), und also > kippte die Stimmung. > > > Das ist ein gutes Beispiel, welches das Problem verdeutlicht. > > SUN bzw. das Management der StarDivision konnte (nur) deshalb die > Richtung bestimmen, weil man über die notwendigen Ressourcen, > vor allem > in finanziell und personell, verfügte. > > Die Entwickler mussten den Vorgaben folgen, weil es ihr Arbeitsvertrag > so vorsah. btw: Genauso ist das bei IBM auch, wird aber an bestimmter Stelle bestritten, weil man sonst einräumen müsste die Leistungen von IBM-Angesstellten waren nur Erfüllung eines Arbeitsvertrages. > Hätten sie etwas anderes machen wollen, so hätten sie den > Arbeitsplatz wechseln müssen und SUN hätte dann halt neue > Leute eingestellt. > > Das Management eines Unternehmens wiederum kann nur eine Richtung > vorgeben, die nachhaltig wirtschaftlichen Erfolg für das Unternehmen > verspricht. > > In der Praxis mag das etwas komplizierter sein; aber die Folgen > suboptimaler Entscheidung in ökonomischer Hinsicht oder einer > suboptimalen Durchführung derselben sind bekannt: Oracle hat sich von > diesem Geschäftszweig unter "Freistellung" der Mitarbeiter getrennt. > In einem Freiwilligenprojekt ist dies aber völlig anders: Das ist doch nur eine Frage wie weit Du bei der Betrachtung abstrahieren willst. Natürlich sind Freiwillige keine Firma, aber natürlich ist es auch Teil der Überlegung von Freiwilligen wie und warum sie freiwillig arbeiten. Jeder Freiwilige muss sich seine freiwillige (und kostenlose) Arbeit nämlich auch leisten können, indem er an anderer Stelle soviel erarbeit das er und seine Familie versorgt sind und dieses Wechselspiel (Ehrenamtlichkeit hier, Lohnarbeit/Selbstständigkeit dort) bestimmt seine Gesamt-Entscheidung. > Wenn ich irgendein Projekt managen will, muss ich mir - wie auch der > Manager in einem Unternehmen - als erstes Gedanken über die Resourcen > machen. > > Welche Ressourcen brauche ich für das ins Auge gefasste > Projekt, wo sind > sie vorhanden oder wie können sie erworben werden. Das gilt für alle > notwendigen Ressourcen, vor allem bei uns aber für HR. JA! GENAU DARUM geht es mir. (was ist/meint "HR"?) > Der Weg über den Abschluss von Arbeitsverträgen oder Werkverträgen ist > mir aus naheliegenden Gründen versperrt, denn es fehlt (schon) an den > hierzu notwendigen finanziellen Ressourcen. > > Ergo muss ich entweder Freiwillige gewinnen, wobei der Kreis > derer, die > sinnvoller Weise in Betracht kommen, sehr beschränkt ist. Außerdem ist > dies eine sehr langwierige Angelegenheit, die darüber hinaus eine hohe > Frustrationstoleranz erfordert. Sinnvoll ist hierfür ferner ein hoher > Grad an Vernetzung, die selbst wiederum einen hohen Arbeitsaufwand > erfordert. > > Realistischerweise muss ich mich also als Projektmanager > bereits bei der > Formulierung der Projektziele "nach der Decke strecken", die bei uns > halt relativ kurz ist. > > Um ein anderes Beispiel von Dir aufzugreifen: Ich kann dann > eben keinen > Palast planen, sondern nur eine Hütte. Ja, genauso ist es bzw. so ist es richtig dargestellt. > Kurz zusammengefasst: Jeglicher Planung sind enge Grenzen > gesteckt. Wir > verfügen nur über sehr begrenzte personelle Ressourcen. Wir sind also > glücklich, dass es nicht 'reinregnet und wir können auch ein Baugerüst > zur Verfügung stellen und freuen uns drüber, dass die Steckdosen > funktionieren. Aber An- oder Umbauten sind derzeit außerhalb unserer > Reichweite. > > Soweit ich das überblicke, handeln die, die auf der Baustelle > arbeiten, > koordiniert, engagiert und motiviert, reflektiert, effizient, > ergebnisorientiert und erfolgreich, JA, so IST es! > allerdings eben auc
Re: Hilfe (was: Hilfe on de-users)
Hallo Jörg, ich möchte nur auf einen Punkt eingehen, habe daher Deine Mail nur auszugsweise zitiert: Am 05.05.20 um 05:30 schrieb Jörg Schmidt: > NEIN! > Damals wurde die Richtung von SUN & Co. bestimmt. GENAU DAS war auch der > rationale Grund für erst die unterschwellige Forderung nach einer Stiftung, > die jahrelang in der Community gärte, und nachfolgend die Umsettzung dessen > (=TDF/LO) als das Verhalten von Oracle einen Anlass bot, weil die Stimmung > der Mehrheit quasi umkippte. > SUN war immer der "wohlwollende Diktator", dessen Handeln man deshalb > aktzeptierte (teils nnur tolerierte wo man inhaltlich doch unzufrieden war), > Oracle hingegen war nicht mehr wohlwollend (oder wurde nicht so empfunden), > und also kippte die Stimmung. > Das ist ein gutes Beispiel, welches das Problem verdeutlicht. SUN bzw. das Management der StarDivision konnte (nur) deshalb die Richtung bestimmen, weil man über die notwendigen Ressourcen, vor allem in finanziell und personell, verfügte. Die Entwickler mussten den Vorgaben folgen, weil es ihr Arbeitsvertrag so vorsah. Hätten sie etwas anderes machen wollen, so hätten sie den Arbeitsplatz wechseln müssen und SUN hätte dann halt neue Leute eingestellt. Das Management eines Unternehmens wiederum kann nur eine Richtung vorgeben, die nachhaltig wirtschaftlichen Erfolg für das Unternehmen verspricht. In der Praxis mag das etwas komplizierter sein; aber die Folgen suboptimaler Entscheidung in ökonomischer Hinsicht oder einer suboptimalen Durchführung derselben sind bekannt: Oracle hat sich von diesem Geschäftszweig unter "Freistellung" der Mitarbeiter getrennt. In einem Freiwilligenprojekt ist dies aber völlig anders: Wenn ich irgendein Projekt managen will, muss ich mir - wie auch der Manager in einem Unternehmen - als erstes Gedanken über die Resourcen machen. Welche Ressourcen brauche ich für das ins Auge gefasste Projekt, wo sind sie vorhanden oder wie können sie erworben werden. Das gilt für alle notwendigen Ressourcen, vor allem bei uns aber für HR. Habe ich tatsächlich Leute, die über die notwendigen Fähigkeiten verfügen, dann muss ich sie (nur noch) überzeugen, wie "wichtig", "toll" oder sonst was das Projekt ist. Habe ich sie nicht, muss ich mir überlegen, wie ich sie gewinnen kann. Der Weg über den Abschluss von Arbeitsverträgen oder Werkverträgen ist mir aus naheliegenden Gründen versperrt, denn es fehlt (schon) an den hierzu notwendigen finanziellen Ressourcen. Ergo muss ich entweder Freiwillige gewinnen, wobei der Kreis derer, die sinnvoller Weise in Betracht kommen, sehr beschränkt ist. Außerdem ist dies eine sehr langwierige Angelegenheit, die darüber hinaus eine hohe Frustrationstoleranz erfordert. Sinnvoll ist hierfür ferner ein hoher Grad an Vernetzung, die selbst wiederum einen hohen Arbeitsaufwand erfordert. Realistischerweise muss ich mich also als Projektmanager bereits bei der Formulierung der Projektziele "nach der Decke strecken", die bei uns halt relativ kurz ist. Um ein anderes Beispiel von Dir aufzugreifen: Ich kann dann eben keinen Palast planen, sondern nur eine Hütte. Und hier kommt dann die nächste Schwierigkeit: Wir können nicht "auf der grünen Wiese" bauen. Wir haben leider einen sehr großen und komplexen Palast geerbt. Wer sich einmal auch nur am Rande mit den Problemen eines "Bauens im Bestand" befasst hat, wird ahnen, welche Probleme dies aufwirft. Kurz zusammengefasst: Jeglicher Planung sind enge Grenzen gesteckt. Wir verfügen nur über sehr begrenzte personelle Ressourcen. Wir sind also glücklich, dass es nicht 'reinregnet und wir können auch ein Baugerüst zur Verfügung stellen und freuen uns drüber, dass die Steckdosen funktionieren. Aber An- oder Umbauten sind derzeit außerhalb unserer Reichweite. Soweit ich das überblicke, handeln die, die auf der Baustelle arbeiten, koordiniert, engagiert und motiviert, reflektiert, effizient, ergebnisorientiert und erfolgreich, allerdings eben auch recht unspektakulär. Qualifizierte Kritik beispielsweise mit dem Ziel der Prozessoptimierung und Arbeitserleichterung ist stets willkommen. Und wer eine Lücke entdeckt hat und erklärt, er wolle sie schließen, wird selbstverständlich die Unterstützung erhalten, die geleistet werden kann. Gruß Michael signature.asc Description: OpenPGP digital signature
Re: Hilfe (was: Hilfe on de-users)
Hallo Jörg, um nicht zu viel Zeit zu verschwenden, werde ich nur auf das mir Wesentliche eingehen. Daher habe ich E-Mail auch gekürzt. Am 04.05.20 um 06:32 schrieb Jörg Schmidt: > Hallo Mechtilde, > > ich möchte Dir Antworten, auf die von Dir aufgeworfenen Fragen (bzw. > Antworten, Anmerkungen) nicht schuldig bleiben, auch um keine > Missverständnisse entstehen zu lassen. > > Beim Rest habe ich lange mit mit mir gerungen ob es Sinn macht meine Meinung > überhaupt noch kundzutun, aber bitte lies Du es, und mache Anmerkungen wenn > Du magst. > > Auf feindseelige Reaktionen anderer werde nicht eingehen. Wenn wir hier Leute > haben, die meinen, Management erfordere kein Wissen und könne mal einfach aus > dem Bauch heraus erledigt werden, so ist das deren Sache und es ist Sache der > Community insgesamt diese Dinge geradezurücken. Die Leute die wir hier haben, sind die Community. Hier tut jede/r das, was sie/er kann und tun möchte. Es gibt keine "instanz2 die irgendetwas gerade rückt. >> in einem Projekt, dass *ausschließlich* von Freiwilligen >> betrieben wird, >> hängt *alles* vom Engagement Einzelner ab. > > Ich hatte formuliert was ich auch inhaltlich meine, wir dürfen uns nicht von > Einzelnen _abhängig_ machen, was einzelne Features im Programm betrifft Wir sind von denen abhängig, die einzelne Features oder Programmkorrekturen einbringen können. Und da gibt jede/r sein Bestes. > Warum nicht offen Etwas sagen wie: 'Jörg, ich würde mir mehr Wertschätzung > für, diese oder jene Arbeit wünschen, denn wir arbeiten angestrengt aber fast > niemanden ist es ein Wort wert.' Ich brauche nicht um *mehr* Wertschätzung zu betteln. Wenn ich etwas tue, bekomme ich auch eine entsprechende WErtschätzung. dies gilt nicht nur bei Apache openOffice, sondern bei allen Projekten der Freien Software Community, bei denen ich immer wieder etwas beitage. > Wenn Du es gelesen hast, hatte ich Ähnliches auf dev jüngst für die Arbeit > der ProOO-Box an der Doku eingefordert, und könnte Dich deshalb in diesem > Empfinden recht gut verstehen. Da sehe ich das Problem, ich fordere deine Wertschätzung. ich erhalte sie quasi für meine Beiträge "geschenkt". *es muss heißen: ich fordere Keine Wertschätzung* > >> Aber ohne Prozessmanagement funktioniert es nicht. > > Bravo. Griffe doch nur dieser Gedanke breiteren Raum im Projekt, in konkreter > (Prozessmanagement) wie in allgemeiner (Management) Form. Das ist die Basis der Arbeit jedes Einzelnen. Ich kann aber nur das managen, was mir zur Verfügung steht. Dies sind, wie beim Translationprozess geschildert, in erster Linie meine eigenen Ressourcen. > Wie wollen wir vernünftig mit Issues umgehen? Peters 'Liste' zu dem Thema war > nicht schlecht, aber es fehlte der wichtige Teil der Kommunikation > Anwender-Projekt (an der Stelle hat sich LO in den letzten Jahren extrem > verbessert) und die Aussage von Matthias (es gibt keine Grenze zwischen > Anwendern und Entwickler WEIL in einem freien Projekt ja jeder alles selbst > anpacken kann) wird der Thematik (das Anwender, und nicht Projektmitglieder > Feature-Wünsche haben) überhaupt nicht gerecht. Jede/r Anwender/in ist auch Teil des Projektes. Ein Projekt lebt nicht für sich Alleine. > Es geht, auch bei der Frage Issues, darum das es eine Richtung geben muss, > früher setzten diese SUN, Oracle oder IBM, heute müssen wir das selbst tun. Und die Richtung wird von den vorhandenen Ressourcen bestimmt. Das war damals(TM) so und gilt heute noch > Lass es mich erklären, damit wir uns nicht missverstehen: > *Niemand bestreitet das Recht jedes Entwickleres, sich die Issues umzusetzen > die er/sie möchte. und was viel wichtiger ist, ob die vorhandenen Personen in der Lage sind eine Fehlerbehebung umzusetzen. > *Gleichzeitig muss es doch unser gemeinsames Anliegen sein aus all diesen > Aktivitäten ein Programm zu machen das in sich 'rund' ist und dessen > Entwicklung auch in vernünftigen Bahnen verläuft (Letzteres meint es wäre > falsch/schlecht ein Programm zu haben mit 'Super-Features' an einer Stelle > und ganz schlimmen Bugs an anderen Stellen, sondern es braucht einen > Mittelweg) und wir müssen auch offen dafür sein, Leuten konkrete Aufgaben > zuzuweisen, die danach fragen. Wenn Menschen auf uns zukommen, die diese Fähigkeiten mitbringen, Fehler zu beheben, können Sie das gerne tun un bekommen soweit wie möglich auch Unterstützung. > Wo aber ein Projekt so inhomogen ist (notwendiger und sinnvoller Weise, und > nicht wegen des auch existenten Personalmangels) wie das Unsere, da muss imho > ein PMC koordinieren, da muss imho ein PMC aktiv führen. Das finge schon mit > so einfachen Dingen an, das Gesamtprojekt regelmäßig über 'den Stand der > Dinge' zu informieren. Die Maillingliste d...@openoffice.apache.org ist unser Informationskanal. > Wir alle wissen um die Vakanz unserer Öffentlichkeitsarbeit (zur Not begrenze > das Thema für die Diskussion hier geografisch auf DACH, falls Du
Re: Hilfe (was: Hilfe on de-users)
Hallo Jörg, um nicht zu viel Zeit zu verschwenden, werde ich nur auf das mir Wesentliche eingehen. Daher habe ich E-Mail auch gekürzt. Am 04.05.20 um 06:32 schrieb Jörg Schmidt: > Hallo Mechtilde, > > ich möchte Dir Antworten, auf die von Dir aufgeworfenen Fragen (bzw. > Antworten, Anmerkungen) nicht schuldig bleiben, auch um keine > Missverständnisse entstehen zu lassen. > > Beim Rest habe ich lange mit mit mir gerungen ob es Sinn macht meine Meinung > überhaupt noch kundzutun, aber bitte lies Du es, und mache Anmerkungen wenn > Du magst. > > Auf feindseelige Reaktionen anderer werde nicht eingehen. Wenn wir hier Leute > haben, die meinen, Management erfordere kein Wissen und könne mal einfach aus > dem Bauch heraus erledigt werden, so ist das deren Sache und es ist Sache der > Community insgesamt diese Dinge geradezurücken. Die Leute die wir hier haben, sind die Community. Hier tut jede/r das, was sie/er kann und tun möchte. Es gibt keine "instanz2 die irgendetwas gerade rückt. >> in einem Projekt, dass *ausschließlich* von Freiwilligen >> betrieben wird, >> hängt *alles* vom Engagement Einzelner ab. > > Ich hatte formuliert was ich auch inhaltlich meine, wir dürfen uns nicht von > Einzelnen _abhängig_ machen, was einzelne Features im Programm betrifft Wir sind von denen abhängig, die einzelne Features oder Programmkorrekturen einbringen können. Und da gibt jede/r sein Bestes. > Warum nicht offen Etwas sagen wie: 'Jörg, ich würde mir mehr Wertschätzung > für, diese oder jene Arbeit wünschen, denn wir arbeiten angestrengt aber fast > niemanden ist es ein Wort wert.' Ich brauche nicht um *mehr* Wertschätzung zu betteln. Wenn ich etwas tue, bekomme ich auch eine entsprechende WErtschätzung. dies gilt nicht nur bei Apache openOffice, sondern bei allen Projekten der Freien Software Community, bei denen ich immer wieder etwas beitage. > Wenn Du es gelesen hast, hatte ich Ähnliches auf dev jüngst für die Arbeit > der ProOO-Box an der Doku eingefordert, und könnte Dich deshalb in diesem > Empfinden recht gut verstehen. Da sehe ich das Problem, ich fordere deine Wertschätzung. ich erhalte sie quasi für meine Beiträge "geschenkt". > >> Aber ohne Prozessmanagement funktioniert es nicht. > > Bravo. Griffe doch nur dieser Gedanke breiteren Raum im Projekt, in konkreter > (Prozessmanagement) wie in allgemeiner (Management) Form. Das ist die Basis der Arbeit jedes Einzelnen. Ich kann aber nur das managen, was mir zur Verfügung steht. Dies sind, wie beim Translationprozess geschildert, in erster Linie meine eigenen Ressourcen. > Wie wollen wir vernünftig mit Issues umgehen? Peters 'Liste' zu dem Thema war > nicht schlecht, aber es fehlte der wichtige Teil der Kommunikation > Anwender-Projekt (an der Stelle hat sich LO in den letzten Jahren extrem > verbessert) und die Aussage von Matthias (es gibt keine Grenze zwischen > Anwendern und Entwickler WEIL in einem freien Projekt ja jeder alles selbst > anpacken kann) wird der Thematik (das Anwender, und nicht Projektmitglieder > Feature-Wünsche haben) überhaupt nicht gerecht. Jede/r Anwender/in ist auch Teil des Projektes. Ein Projekt lebt nicht für sich Alleine. > Es geht, auch bei der Frage Issues, darum das es eine Richtung geben muss, > früher setzten diese SUN, Oracle oder IBM, heute müssen wir das selbst tun. Und die Richtung wird von den vorhandenen Ressourcen bestimmt. Das war damals(TM) so und gilt heute noch > Lass es mich erklären, damit wir uns nicht missverstehen: > *Niemand bestreitet das Recht jedes Entwickleres, sich die Issues umzusetzen > die er/sie möchte. und was viel wichtiger ist, ob die vorhandenen Personen in der Lage sind eine Fehlerbehebung umzusetzen. > *Gleichzeitig muss es doch unser gemeinsames Anliegen sein aus all diesen > Aktivitäten ein Programm zu machen das in sich 'rund' ist und dessen > Entwicklung auch in vernünftigen Bahnen verläuft (Letzteres meint es wäre > falsch/schlecht ein Programm zu haben mit 'Super-Features' an einer Stelle > und ganz schlimmen Bugs an anderen Stellen, sondern es braucht einen > Mittelweg) und wir müssen auch offen dafür sein, Leuten konkrete Aufgaben > zuzuweisen, die danach fragen. Wenn Menschen auf uns zukommen, die diese Fähigkeiten mitbringen, Fehler zu beheben, können Sie das gerne tun un bekommen soweit wie möglich auch Unterstützung. > Wo aber ein Projekt so inhomogen ist (notwendiger und sinnvoller Weise, und > nicht wegen des auch existenten Personalmangels) wie das Unsere, da muss imho > ein PMC koordinieren, da muss imho ein PMC aktiv führen. Das finge schon mit > so einfachen Dingen an, das Gesamtprojekt regelmäßig über 'den Stand der > Dinge' zu informieren. Die Maillingliste d...@openoffice.apache.org ist unser Informationskanal. > Wir alle wissen um die Vakanz unserer Öffentlichkeitsarbeit (zur Not begrenze > das Thema für die Diskussion hier geografisch auf DACH, falls Du meinen > würdest es wäre international merklich besser)
