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
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.). 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. Es gab auch weder Sprints, noch Deadlines. Diese Aufgaben wurden insofern gemeinsam bewältigt, als dass sie einer anfing und dann andere mit- und weitermachten. 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. Treffen mit physischer Anwesenheit zu organisieren wäre auch schwierig zu und kostspielig. Die zu Beteiligenden sind nämlich über drei Kontinente (Nord- und Südamerika einmal als separate Kontinente betrachtet) verteilt. Man stimmt ich halt über Kanäle des Internet ab (was wegen der Zeitzonen schon schwierig genug ist). Die europäischen, insbesondere die deutschen Beteiligten treffen sich auch häufiger auf den verschiedenen Events. Und wenn Mechtilde und ich in Hamburg sind, werden natürlich Markus und Matthias und meist auch andere informiert. 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. Apache OpenOffice hat den Vorzug, dass die allermeisten Entwickler die Software selber nutzen und meist in Kontakt zu anderen Nutzern stehen. 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. 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. Ich will unser Projekt nicht "hochjubeln". Es ist allen, die ich kenne, bewusst, dass unser Projekt in einer prekären Situation ist - und das nicht erst seit gestern. Aber das beschränkt nicht nur stark unsere Möglichkeiten, sondern eröffnet auch jedem einzelnen Chancen - vor allem sich an interessanten Aufgaben zu erproben und zu bewähren. Unser "Bus-Faktor" [0] ist leider, was jedem bewusst ist, klein. Daher werden Neue von allen "mit offenen Armen empfangen". Aufgrund der Situation überlegt auch jeder immer wieder, wie Prozesse verbessert und die Arbeit effizienter gestaltet werden kann. Die vorgenannten Beispiele mögen als Beleg hierfür aufgefasst werden. Gruß Michael [0] https://de.wikipedia.org/wiki/Truck_Number signature.asc Description: OpenPGP digital signature
