[TYPO3-german] +1 / -1 Thread

[Philipp Gampe]

Hi d.ros,

d.ros wrote:

> 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

Eine Erweiterung des TER ist schon immer angedacht, scheiterte jedoch an der 
komplexen Technik und des alten, wartbaren Codes.
Eigentlich brächte es nur ein Voting Feature (gab es mal) und ein 
automatisches Setzen der Kompatibilität für jede Major Version.

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

Leider war, aber es gibt viele Internet Posts und man findet schnell Hilfe.

> 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.

Wie oben beschrieben muss dafür jemand den TER Code anpacken und es muss man 
allen 4.5+ Versionen kompatibel bleiben.

> 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.

Die Filtervoreinstellungen können sicher angepasst werden und auch etwas JS 
Magie sollte kein Problem sein. Einfach mal bei nächsten T3o Code Sprint 
vorsprechen ;)

Ps: Man kann ein komplettes Image der TYPO3.org Instanz bekommen, wenn man 
sich selbst die Hände schmutzig machen möchte. Ein kurze Email an 
admin at typo3.org genügt.

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

Benötigt einen TER Coder und das Voting muss pro Version, als auch global 
möglich sein.

> 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 aber ein solcher Flag muss von allen TYPO3 Versionen unterstützt werden 
oder transparent nur für das TER Frontend zur Verfügung stehen.

Da fehlt übrigens immer noch ein TER Frontend für die Maintainer!

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

+1, einfach eine Patch einreichen (Core rulez). Oder sich beim nächsten T3o 
Sprint beteiligen.

> 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.

Es lässt sich vieles machen, wenn denn nur mal jemand ein neues TER 
schreibt.
War das jQuery Plugin Repo nicht längere Zeit down?

> 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.

Ich denke dies macht erst mit einem Maintainer Frontend Sinn. Außerdem 
sollte man an dieser Stelle über eine bessere Forge Integration nachdenken.

Was ist mit Extensions auf Github, Composer Extensions ...

> » 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.

+/-0 Es sollte aber als Feature verfügbar sein, wenn Git oder SVN benutzt 
werden. Eventuell kann auch ein Diff der letzten beiden Versionen 
veröffentlicht werden. Dann braucht man auch kein VCS.

> 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" )

+1 siehe oben

> 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.

Mit Maintainer Interface wäre dies einfacher.

Jedoch musst du bedenken, dass jeder Entwickler bzgl. "Important Changes" 
anders denkt und du damit wieder einen Kriterienkatalog benötigst.
Ich sehe schon die Diskussionen :)

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

+1

> Mein Lösungsansatz:
> 3.1. < 1.7.
> 
> 3.2) Das Forge sollte bindend für alle Extensionentwickler sein um eine
> einheitliche Basis zu schaffen.

Nope ... Github ist eine gute Alternative. Und es gibt ja auch noch weitere 
Source Code Seiten im Netz.
Warum muss man die Entwickler zwingen. Forge anzubieten sollte genügen.

> 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.

reStucturedText + http://docs.typo3.org/typo3cms/extensions/
Mit PanDoc gibt es auch einen Markdown->reST Konverter, reST ist jedoch 
flexibler und lässt sich in der einfachen Variante wie Markdown verwenden.

> 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.

Ich bin mir nicht sicher, ob dies von dein Extension Autoren so gewollte 
ist.
Es sollte optional sein und es ist ja mit der aktuelle TER Software durchaus 
möglich, wie die Budget Diskussion gezeigt hat.

Update: Es ist möglich. Einfach unter <Project>/Settings/Modules das Häkchen 
bei Board setzen und dann unter <Project>/Settings/Forums ein Forum anlegen.

> 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.

Es sollte eigentlich selbstverständlich sein ... aber uups ... falsche 
Sprache ;)

> 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.

+1 Ein Maintainer Frontend mit der Möglichkeit einen Link auf die Doku 
nachträglich zu setzen wäre optimal.

> 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.

Es gab/gibt die Möglichkeit im Bugtracker Bug Bounties zu vergeben ... das 
hat sich aber nie durchgesetzt.
Die Leute zahlen lieber einmal einen größeren Betrag, als kontinuierlich 
einen kleineren.
Das ist übrigens auch außerhalb des Webumfeldes so. Schon mal versucht für 
einen lokalen (Sport-) Verein Sponsorengelder einzuwerben?

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

Man kann niemanden zu etwas zwingen. Aber man kann sanft die Richtung 
vorgeben.

> » 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.

Das ist schwer durchzusetzen. Jeder Versuch eines TER Koordinationsteams ist 
an Manpower kläglich gescheitert (wie so viele gute TYPO3 Ideen).

> 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.

Das wäre toll ... aber oft ist es einfacher selbst etwas zu bauen (und zu 
veröffentlichen), als Stundenlang mit dem Extension-Autor/Maintainer zu 
diskutieren.
 
> » Versionsclash
> 
> Die momentane Situation ist nun mal so wie sie ist. Viele "Breaking
> Changes" lassen das Meer aufbrausen.

Verglichen mit anderen Produkten sind es ja eher wenige Breaking Changes.

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

Wie meinen? Es ist nicht jeder technisch begabt. Wenn ich zu viel Zeit habe 
(davon leider im Moment eher weniger), dann biete ich durchaus schon mal an, 
auf die Webseite zuzugreifen. Auch auf meine Seite haben schon Leute 
zugreifen dürfen um zu debuggen.

> 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.

Es ist zumindest eine sehr starke Empfehlung und jede nicht Extbase 
Extension sollte gut überlegt sein.
Die Abstractheit von Extbase Extensions erleichtert auch Changes im Core, da 
der Code im Zweifel viel einfacher migriert werden kann.

> "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.

+10

> 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.

Einen ganz großen Bruch hat es ja nicht gegeben. Eher sind es die vielen 
kleinen Bugs die durchaus nerven.

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

Flow ist ziemlich gut und ich werde mir Neos nach den Klausuren auf jeden 
Fall mal tiefer anschauen, sie evtl. mein private Homepage auf Neos 
migrieren ... für ein "Bitte weitergehen" taugt es allemal ;)

> » Community Wille zum TYPO3 CMS

Insbesondere sind helfende Hände gewünscht ... DevDays ... lokale Code 
Sprints und Bar Camps :)

Die ewigen Nörgler können gerne zu Haus bleiben.

> 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.

Ich denke die Budget Polls haben Einige wachgerüttelt und sollte auf jeden 
Fall nächstes Jahr wiederholt werden.

Aber bitte bedenke auch das die Community viel größer ist, als die T3A!

Viele liebe Grüße

p.s.: dam ... schon wieder 3:30 :P
-- 
Philipp Gampe – PGP-Key 0AD96065 – TYPO3 UG Bonn/Köln
Documentation – linkvalidator
TYPO3 .... inspiring people to share!