Raphael Bircher schrieb: > > Weil wir hier auf dieser Liste unter dem Dach von Apache sind. Die De > Community war nie ein unabhängiges Gebilde, selbst wenn das viele > glaubten. Die ganze Infrastruktur, gehörte früher einer Firma, jetzt > einer Organisation. Unsere Entscheidungen die wir hier getroffen haben > was OOo anbelangt hatten eigentlich rein formale Bedeutung. Sie waren > genau so lange Gültig bis der Hausherr nein sagte. Das war auch bei den > Release so. Wir hätten ein Release stoppen können, SUN oder Oracle hätte > es ohne weiteres genau gleich rausbringen können. > Bisher hat noch kein Apache uns verboten, diese Liste auch für Abstimmungen und Wahlen zu nutzen.
> In einem Sportclub kann sich eine Mannschaft eigene Regeln geben. Zum > beispiel Bussgeld für das zu späte Erscheinen im Training usw. Wenn aber > die Vereinsführung kommt, und sagt, "Nein, wollen wir nicht" dann ist es > unerheblich was du für Regeln abgemacht hast. Genau das ist der "Apache-Way": jedes Projekt (Mannschaft) gibt sich eigene Regeln: Auch wenn ich es schon oft zitiert habe- hier noch einmal: "Since the appointed Project Management Committees have the power to create their own self-governing rules, there is no single vision on how PMCs should run a project and the communities they host." http://apache.org/foundation/how-it-works.html#management > > SUN war liess uns alle machen, doch damit bildeten sich Grüppchen, die > nicht selten ihr eigenes Süppchen kochten. Apache weiss dass es gewisse > einheitliche Linien braucht, und bei uns hat man diese sogar Schwarz auf > Weiss. > > Das Problem ist, dass einige dieser von uns aufgestellten Regeln > entgegen denen von Apache stehen. Apache mag keine Leads, Wenn Du hierauf anspielen solltest: "We do not have a hierarchical structure." (a.a.O.), solltest Du auch über den nächsten Satz nachdenken: "Rather, different groups of contributors have different rights and responsibilities in the organization." Ich sehe also keine Kollision. und es gibt > auch in keinem Apache Projekt Personen die das Projekt vertreten können. Darum geht es bei unseren Co-Leads und APs auch überhaupt nicht. Da die deutschsprachige Community nie eine rechtsfähige Entität gewesen ist, geht es nicht um ein "Vertreten" der Community nach außen, allenfalls in einem repräsentativen Sinn kann man diesen Ausdruck gebrauchen. Auch die CoLeads sind nur Ansprechpartner für Außenstehende, die eine konkrete Person brauchen, an die sie sich wenden können. Die CoLeads haben niemals die Community "beherrscht", noch waren sie in der Lage, sie zu irgendetwas zu verpflichten, sie haben vielmehr der Community einen Dienst erwiesen, indem sie sich als Ansprechperson zur Verfügung gestellt haben. Wenn sie etwas nach außen vertreten haben, waren sie stets nur Sprachrohr der Community, die sich im Konsens oder in demokratischer Abstimmung einen Standpunkt gebildet hatte. Anders geht es auch nicht in einem Freiwilligenprojekt. s.a. "The Apache projects are managed using a collaborative, consensus-based process." Die Community hat nie CoLeads oder APs gewählt, um den Machthunger von irgend jemanden zu stillen, sondern weil es Aufgaben gab, die zweckmäßigerweise nachhaltig von einzelnen Personen wahrzunehmen waren. Dazu gehört bei den CoLeads beispielweise auch Mediation und Motivation innerhalb der Community. > Nicht mal die Board Mitglieder können das. Apache antwortet als Projekt > oder eben nicht. Es steht jedem Commiter frei interviews zu geben, zu > bloggen usw. aber nicht im Namen von Apache OpenOffice oder gar der ASF. Was die Meinung der Community ist, legt diese fest - hier sind wir stolz auf unsere demokratische Tradition; es ist aber PR-technisch durchaus sinnvoll, wenn diese Meinung von bestimmten Personen den Medien etc. kommuniziert werden. Was tatsächlich Konsensus ist, kann auch "im Namen" der Community verbreitet werden - und zwar weder als Meinung "von Apache OpenOffice oder gar der ASF", sondern als Meinung der deutschsprachigen Community. Bisher hat sich auch noch kein Community-Mitglied den Mund verbieten lassen, weil es CoLeads oder Marketing-APs gab. > > Ja, wir können abstimmen, ob wir die Ansprechpartner und die Co-Leads > streichen, nur ist das eine rein formale Abstimmung. Wir sind jetzt in > einem anderen Haus, und da gelten nun mal andere Regeln. Hier bei Apache > erachte ich die Community Regeln als wirkungslos. > Ich pflege mich an Regeln zu halten, die in einem demokratischen Prozess beschlossen wurden in einer Gemeinschaft, der ich mich freiwillig angeschlossen habe und die ich jederzeit wieder verlassen kann. Regeln, die auch wieder in demokratischer Abstimmung geändert oder aufgehoben werden können. Insoweit sind die Regeln bei mir keineswegs "wirkungslos". > Zudem, hand auf's Herz, die ganze Wahl/Lead/Ansprechpartner Sache ist > hoffnungslos überholt für unser Projekt. Selbst LibreOffice (und da > sitzen viele Köpfe die das Ganze entworfen haben) haben das Konzept > nicht übernommen. LibreOffice hat sich eine andere Struktur gegeben. Ich erlaube mir die Einschätzung, dass dort die Entscheidungen sicherlich nicht "konsensualer" und "basisdemokratischer" gefällt werden, als von oder bei uns. > > Nennt mir ein paar Gründe warum man ein Konzept nach mals durchkauen > muss dass: > - Dem aktuellen Stand nicht gerecht wird > - gegen die Regeln der Organisation verstösst > Nur aus sturheit, aus Trotz um zu zeigen dass man noch da ist, oder > vielleicht einfach weil man nicht kappieren will, dass es manchmal > Veränderungen gibt. Es geht nicht um Sturheit, sondern um Verlässlichkeit und auch um demokratische Kultur. Es kann eben nicht irgend jemand sagen: "Ab heute gelten bestimmte Regeln nicht mehr." - Er kann allenfalls sagen, dass er sie für sich nicht akzeptiert. Wie wir zusammenarbeiten wollen, um unser gemeinsames Ziel zu erreichen, und wie wir dieses Ziel in Worte fassen, bestimmen wir in einem demokratischen und konsensoriertierten Prozess und nicht irgendeiner von uns mit Verbindlichkeit für die Anderen. > Leute, ich weiss, dass einige hier gerne das alte zurück haben wollen. > Ja, die alte Community war schön, ich mochte auch vieles davon. Aber wer > sagt, dass diese Form die einzig gute ist. Wer hier behauptet, dass wir > nicht noch eine viel bessere Form schaffen können? Vielleicht sind wir > ja, wenn wir nach den Apache Regeln arbeiten viel erfolgreicher, als je. > Wir arbeiten hier nach "Apache-Regeln" - s.o.. Wir haben nur eine andere Struktur als andere Apache-Projekte - auch weil wir anders sind, als andere Apache-Projekte. Die "Apache-Regeln" tragen dieser Unterschiedlichkeit auch - wie dargelegt - Rechnung, indem sie jeden Projekt erlauben, sich eigene Strukturen zu geben. > *Ich bin der Meinung, dass wir mal offen für das Neue sein sollten. Am > alten festzuhalten bringt uns nicht weiter* > Ok, mach' konkrete Vorschläge, diskutier' sie hier. Es gibt vieles zu verbessern - keine Frage. Ich bin aber der Meinung, man sollte ein Gebäude, sei es noch so alt und morsch, erst dann abreißen, wenn die Bauzeichnungen für ein neues vorliegen. Gruß Michael
signature.asc
Description: OpenPGP digital signature
