[TYPO3-german] +1 / -1 Thread

[d.ros]

Am 23.01.2013 13:26, schrieb Georg Ringer:
> Am 23.01.2013 13:18, schrieb Dieter Bunkerd:
>> Mit dem entsprechenden Budget ausgestattet, bin ich mir sogar sicher,
>> dass das wer angegangen wäre.
>
> Geld ist nicht die Lösung aller Probleme
>

Hallo Liste,

erst mal vielen Dank an diese Diskussionsrunde, die mich dazu bewogen 
hat, meine derzeitige Meinung kund zu tun und viel wichtiger: 
Lösungsansätze zu schaffen. Denn es geht mir stark auf den Keks, dass 
öfters mal Phrasendrescherei betrieben wird, ohne Lösungsansätze zu bieten.

Sollte das an dieser Stelle nicht passen, würde ich mich freuen, wenn es 
an anderer Stelle weiter kommuniziert und ausgebaut wird, bis Lösungen 
folgen.

Vorab: Ich kann sowohl die Entwicklersicht aber auch die Agentursicht 
verstehen. Denn ich bin von beidem betroffen.


Feststellungen:

» Die Fähigkeit schnell festzustellen, welche Extension unter welchen 
Umständen funktioniert ist momentan nicht möglich und kommen momentan 
dann auf das Konto "Erfahrung". -Suboptimal

Jemand, der nicht im Thema ist, oder wirklich nur rudimentäre Kenntnisse 
der Materie hat, verzweifelt.

Mein Lösungsansatz:

1.1.) Im Extension Repository muss klar erkennbar sein, bis zu welcher 
Systemversion eine Extension kompatibel ist. Und das schon in der 
Listview / Overview.

1.2.) Die Filterfunktion im Extension Repository wird übersehen und 
sollte erweitert werden. Bei Eingabe einer Suche sollte der Filter 
automatisch aufklappen, damit diese Möglichkeit einen Fokus erhält. 
Alternativ eine neue Position, wo dieser immer sichtbar ist. Ferner 
sollten die Filter _piBase und extbase hinzukommen und die Extensions 
die Alpha, Test, Obsolete und Experimental geflaggt sind automatisch 
ausgeblendet sein.

1.3.) Votings für Extensions sollten eine zentrale Rolle bekommen, um 
eine Entscheidung schneller herbeiführen zu können.

1.4.) Extensions, die die Funktionalität einer bestehenden 
Basisextension erweitern, sollten einen zusätzlichen Flag für den Filter 
bekommen und standardmäßig ausgeblendet sein - Denn diese 
Funktionalitätserweiternden Extensions sollten automatisch in der 
Detailview einer Basisextension aggregiert werden. Dadurch erhalten wir 
eine bessere Übersicht im Ganzen und können bei Ansicht einer 
Basisextension den gesamten Funktionsumfang bewerten, samt der 
zusätzlichen externen Erweiterungen die diese Basisextension erweitern.

1.5.) Autor in der Listview ? Das interessiert keinen und gehört in die 
Detailview. -Verschenkter Platz.

1.6.) Sich ein Beispiel an jQuery nehmen. Hier wird bei einer Suche 
zwischen "Recent Updates" und "New Plugin" differenziert. Die Listview 
ist "Clean" und die haben es sogar geschafft über den Tellerrand zu 
schauen und Mediaqueries berücksichtigt. Nett sind auch die tagbasierte 
Aufbereitung und die Detailview.

1.7.) Links zu Homepage d. Entwicklers, Demoversion, Dokumentation, Bug 
reporting, Commercial und Free-Support sollten in jeder Detailview zu 
sehen sein und aktuell gehalten werden.



» Die Fähigkeit schnell festzustellen, welche Änderungen in einer 
Extension gemacht worden sind, müssen sich schwerlich erarbeitet werden.

Mein Lösungsansatz:
2.1.) GIT, github oder SVN für alle Entwickler bindend und die 
Changelogs automatisch aufbereiten.

2.2.) Die Changes der aktuellsten Version sollten in der Listview der 
Extension Repositories per Knopfdruck einblenden. ( Als erfahrener 
Anwender / Entwickler erhält man so einen schnellen Überblick, was sich 
gerade geändert hat und spart Zeit beim morgendlichen "Checken" )

2.3.)Links in der Listview im Web- und CMS-Repository zu Dokumentation / 
Support /  sollten obligatorisch sein, sowie "Important Changes" die das 
Verhalten oder die Datenbank ändern, müssen gesondert gekennzeichnet 
sein - EINHEITLICH.



» Die dezentrale und uneinheitliche Dokumentations- und 
Supportphilosophie macht es jedem schwer Extensions zu erkennen, zu 
bewerten zu vergleichen zu bugfixen und zu lernen.

Mein Lösungsansatz:
3.1. < 1.7.

3.2) Das Forge sollte bindend für alle Extensionentwickler sein um eine 
einheitliche Basis zu schaffen.

3.3) SXW ist blöd. Warum sollen Extensionentwickler doppelt und dreifach 
belastet werden. Das Forge sollte die Möglichkeit haben eine ordentliche 
Dokumentation schreiben zu können. Standarmäßig als Markdown, erweiterte 
Möglichkeiten um Bildmaterial und Videos zu setzen und alternativ einen 
iFrame zu setzen um ganz individuell zu sein.
Wer unbedingt extern und individuell Dokumentieren will - bitte. Dann 
bitte aber ein Link dahin, der an zentraler Stelle zu finden ist - also 
in der Detailview der Extension im Repository und selbstverständlich im 
Forge.

3.4) Hilfe zur Selbsthilfe. Jede Extension die im Forge angelegt wird, 
sollte auch einen Link zu einer Plattform zum präferierten Useraustausch 
bereitstellen. Sei es ein Forum, Verweis in den IRC oder zu einer 
Mailingliste. Mein Favorit ist jedoch tatsächlich ein Forum, da so der 
Einstieg für Neulinge am komfortabelsten nachzuvollziehen ist. Es gibt 
einfach zu viele Stellen im Internet mit Halbwissen, wo es doch so 
einfach und sinnvoll sein kann als Entwickler die präferierte Plattform 
zu benennen. Man kann nicht auf allen Hochzeiten tanzen und den Support 
für eine Extension im Internetnirvana verpuffen lassen. Konsolidiert, 
für jeden nachvollziehbar.

3.5) Der Support in den vorbeschriebenen Kanälen sollte ausschließlich 
auf Englisch erfolgen, so wie es im IRC und in der englischen 
Mailingliste getan wird. Somit sperren wir am wenigsten Leute aus. Und 
stärken die Internationalisierung der Community. Insbesondere sehe ich 
im Moment gute Leute in Frankreich,Polen und Skandinavien die ein echtes 
Problem mit Deutsch haben.

3.6) Extensions ohne Dokumentation müssen standardmäßig per Flag/Filter 
ausgeblendet sein. Es kann nicht sein, dass das Repository durch useless 
cases belastet wird. Denn ohne Dokumentation tappt man gerne im dunklen.

3.7) Es muss einfacher werden präferierten Support / Commercial Support 
/ Commercial Extensionerweiterung zu monetarisieren. Insbesondere ist 
das Thema Crowdfunding ein Thema das stark begutachtet werden sollte. 
Klar jeder kann Emails schreiben und den Entwickler fragen. Hand aufs 
Herz: Es machen wenige bis keiner. Wenn aber klare Definitionen von 
Problemstellungen mit einem "per Knopfdruck" Monetarisierungsinstrument 
belegt werden, dass es zulässt auch Teilbeträge anzunehmen und zu 
fakturieren, werden sich mehr Menschen ( private und gewerbliche ) und 
Unternehmen dazu durchringen etwas zu bezahlen. Es muss davon 
weggegangen werden, nur nach Lust und Laune die Extensions zu erweitern 
und zu supporten. Resultieren tut das ganze doch aus der Tatsache, dass 
viele Entwickler auch noch Geld verdienen müssen, neben dem Extension 
entwickeln. Aber warum sollte man es diesen Leuten nicht einfacher 
machen, Ihre Extensions zu verbessern.

Wer das per se für seine Extension ausschließt - kein Thema. Der lässt 
es halt.



» Verpulverte Energie.

4.1) Es gibt so viele Extensions, die ein und die selbe Funktionalität 
bereitstellen, nur mit verschiedenen Lösungsansätzen. Wenn also eine 
Extension erstellt wird, die eine andere Basisextension ersetzt, dann 
bin ich der Überzeugung, dass es notwendig ist, immer klarstellen zu 
lassen, warum diese Extension nun eine Daseinsberechtigung haben soll 
gegenüber der ersteren Lösung. Das sollte eine Kommunikationspolicy sein.

4.2) Wenn Extensionentwickler anfangen Extensions zu erstellen sollte in 
allen Kommunikationskanälen klargestellt werden, dass es besser sein 
kann eine bestehende Extension zu erweitern, anstatt immer einer neue 
ins Repository zu schmeißen. Das sollte eine Kommunikationspolicy sein. 
Durch die Konsolidierung kann mehr Qualität ein höherer Funktionsumfang 
und auch ein breiterer Support für einzelne Extensions erbracht werden.



» Versionsclash

Die momentane Situation ist nun mal so wie sie ist. Viele "Breaking 
Changes" lassen das Meer aufbrausen.

Wenn jemand 3 Tage nach einem Fehler sucht, dann bin ich der Meinung, 
dass er nicht auf dem richtigen Platz sitzt. Sorry.

Es ist momentan unabdinglich bei neuen Projekten auf Extbase zu setzen, 
um diese "Update-sicher" zu halten und eine spätere Portierung im 
kaufmännischen Rahmen zu halten.

"Agenturen" die jetzt hier "Rohrspatzen", sind die, die mehr nehmen als 
sie geben. Sonst wären diese schon lange Unterstützer und hätten mehr 
Verständnis für den notwendigen Wandel. Wenn nun bestimmte 
Funktionalitäten momentan dem Kunden mehr Geld kosten, da diese erst 
entwickelt werden müssen, dann ist das momentan so und muss entsprechend 
kommuniziert werden oder Auftragssynergien müssen her. Sicher ist eins: 
Man muss ständig lernen. Dazu gehört es auch, nicht mehr die alten 
Kalkulationsgrundlagen für Projekte anzulegen.

Wer auf andere Systeme setzt, wird sich in 3 Jahren vielleicht umsehen, 
dass die Entscheidung doch eher suboptimal war. Gefühlte 10 Jahre war 
TYPO3 ein Fels in der Brandung durch die starke und stringente Auf- und 
Abwärtskompatibilität. Das soll wieder so werden, dafür ist aber leider 
dieser harte Bruch nötig. BTW: Vielleicht hätte man den Compatibility 
Layer erstmal fertigstellen sollen, bevor man Funktionen entfernt. Das 
Gremium, dass das entschieden hat, hatte keinen Blick für das große 
Ganze. Jetzt wird ja entgegengewirkt.

NEOS & FLOW ? -> IMHO ein Fehler die Systeme schon jetzt so präsent zu 
kommunizieren.



» Community Wille zum TYPO3 CMS

Fehlentscheidungen die an "oberster" Stelle gemacht worden sind gilt es 
zu korrigieren. Die Association täte sich gut daran Surveys zu machen, 
die bevorstehende Entscheidungen an die Community reichen, um Trends 
besser aufnehmen zu können, um eine qualifiziertere Einschätzung von 
"gewolltem" machen zu können. Ich bin mir sicher, dass die daraus 
resultierenden Trends es ermöglichen bessere Entscheidungen zu treffen. 
Folglich sollen die Surveys keinesfalls bindend sein, sondern ein 
Hilfsmittel, um aus dem größtmöglichen Querschnitt an Anwendern einen 
guten Mittelwert in eigene Entscheidungen einfließen zu lassen.



----------------------------------------------------------------------------------------------


Nun ist es dunkel und ich fühle mich befreit. Ich hoffe, dass ich 
einigermaßen konstruktiv war, die Themen nicht zu zerrissen und diese
(langen) Zeilen zu einer besseren TYPO3 Welt beitragen werden.

So Long

David