Noch ein paar Anmerkungen zu . . .
Es besteht der Wunsch, dass Joomla sich nicht ständig ändert und sich automatisch updatet.
Dem kann ich uneingeschränkt zustimmen.
Und jetzt das Tolle: Möchte ich diesen Prozess beeinflussen, hebe ich die Hand, und trete einem Team bei und kann durch mein aktives zutun Joomla, die Entwicklung und Migration sowie deren Auswirkung direkt oder indirekt beeinflussen....
Da ist es ja wieder das Totschlagargument. Wie ich schon in #51 sagte: nicht jeder, der Joomla nutzt, hat aus verschiedenen Gründen die Zeit oder das Wissen sich intensiver bei Joomla einzubringen. Überspitzt kann diese Aussage auch so interpretiert werden: wer sich nicht beeiligt hat selbst Schuld und kein Recht Forderungen zu stellen. Das führt dann leider dazu, dass sich eine Entwickler-Blase bildet, die von den Anforderungen der Anwender über kurz oder lang gar keine Ahnung mehr hat. Dahinter steckt offenbar auch die Ansicht, dass die Formulierung von Anforderugen eine Bringschuld ist, was aber zur weiteren Selbstisolierung der Entwickler führt mit dem möglichen Effekt, dass Softwareprojekte mit Volldampf gegen die Wand fahren (so meine Erfahrungen).
Dem kann u.a. durch aktives Zugehen auf die Endanwender (dazu sie unten) begegnet werden und durch das Akzeptieren, dass die Sammlung von Anforderungen eine Holschuld ist. So wäre es z.B. durchaus möglich die Anforderungen und Planungen für zukünftige Versionen mit jeder stable-Version aktiver und verständlicher (s.u.) zu kommunizieren und Feedback einzufordern und nicht nur auf Links (github ) zu verweisen, wo jeder seine Anforderungen plazieren kann, was dann doch die wenigsten tun bzw. vor allem nur diejenigen, die als Entwickler arbeiten. Ein stetig wiederholt angebotener Link wird sicherlich öfter genutz werden. Das wird sicher nicht die große Masse anziehen aber dennoch deutlich mehr Beteiligung erzeugen und vor Allem mehr Feedback der Endanwender bringen.
Wenn einer nicht entwickeln kann - er kann Entwickler entlasten und z.B. Tests machen oder Anforderungen (issues) verwalten. Zum Beispiel prüfen, ob ein gemeldeter Fehler wirklich ein Fehler ist - genau das was wir hier im Forum machen.
Wichtig wäre dabei allerdings auch, dass die Anforderungen besser erklärt werden. Mir selbst ist z.B. der dahinterliegende Problemstellung, die Ziele und die Folgen letztlich unklar (Beispiel: Template style assigned text plurals #40732 - da finde ich am Ende nur Quellcode, mit dem ich überhaupt nichts anfangen kann - was jemanden, der willens ist Feedback zu geben sofort wieder abschreckt.).
Da kann ich dann auch nur schwer testen, wenn ich die Anforderung gar nicht erst verstehe (weiteres Beispiel: ComponentDispatcher comments #41005). Da ist dann doch ein gewisser Erklärungsaufwand erforderlich. Andernfalls bekommt die Blase eine immer dickere Hülle, da wegen fehlendem Verständnis erst gar kein Feedback von außerhalb kommt.
Gibt es dafür Belege, Aussagen, Videos, Webinars oder was auch immer, das Beweist, dass es "denen ("da oben")" nicht bewusst ist, was ihre Entwicklungen für Konsequenzen hat?
Also hier im Forum habe ich dazu schon des öfteren Beiträge gefunden. Und die Ankündigung einer weiteren Major Version zu einer Zeit, wo die meisten Endanwender noch nicht einmal die Migration der aktuellen Major Version abgeschlossen haben, zeigt aus meiner Sicht schon, dass die Konsquenzen zumindest nicht in vollem Umfang klar sind.
Übrigens: wer mit einer Software und seinen Entwicklern nicht zufrieden ist kündigt das in der Regel nicht an sondern geht einfach weg (auch eine meiner Erfahrungen). Daher ist die Frage nach "Beweisen" an dieser Stelle nicht wirklich zielführend.
Unzufriedenheit wird übrigens auch und gerade durch Migrationen verursacht. Da wird lieber stillschweigend auf eine andere Software umgestiegen, selbst wenn es dadurch funktionale Einschränkungen gibt und der Wechsel Zusatzaufwand bedeutet (nach der Devise "Lieber ein Ende mit Schrecken als ein Schrecken ohne Ende" - da können selbst Kosten von zig-Millionen einen Wechsel nicht verhindern, wie Beispiele aus der Industrie zeigen). Denn eines muss auch klar sein: funktionale Defizite können durch Eigenentwicklung nachhaltig ausgeglichen werden - vorausgesetzt diese werden nicht bei einer kommenden Migrationen zunichte gemacht. Von daher können die Defizite von WP nicht unbedingt als Gegenargument genutzt werden.
Diese Entscheidungen werden dann nach dem Prinzip der Mehrstimmigkeit umgesetzt. Ob diese Entscheidungen uns allen gefallen, steht auf einem völlig anderen Blatt.
Das ist ja genau das Problem, dass Entscheidungen getroffen werden, die nur innerhalb der Entwickler-Community und deren unmittelbarem Umfeld abgestimmt sind (so zumindest meine Wahrnehmung). Ich sehe nicht wo Endanwender in die Entscheidungen aktiv mit einbezogen werden. Oder anders gesagt: diese Entscheidungsprozesse sind nicht gerade transparent.
Übrigens: Endanwender sind für mich vor Allem diejenigen, die sich bei der Gestaltung einer Webseite im Wesentlichen auf die Konfigurationsmöglichkeiten von Joomla und der Extentions beschränken und allenfalls CSS-Anpassungen realisieren - aber nur selten eigene Programmerweiterungen - z.B. über JavaScript - vornehmen (weil sie nicht wollen oder nur eingeschränkt können) und auch viele der angebotenen Features (wie z.B. Child-Templates) nur eingeschränkt oder gar nicht nutzen. Daraus ergeben sich natürlich spezielle Anforderungen - aber dazu schreibe ich (vielleicht) später mal was.
), und vor allem transparente Prozesse und nachvollziehbare Entscheidungen vorzufinden.