[TYPO3-german] +1 / -1 Thread

[Ingo Renner]

Am 1/23/13 10:06 AM, schrieb d.ros:

Ich helfe mal ein bisl aus...

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

http://forge.typo3.org/issues/44850

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

http://forge.typo3.org/issues/44851

> Alternativ eine neue Position, wo dieser immer sichtbar ist. Ferner
> sollten die Filter _piBase und extbase hinzukommen und die Extensions

http://forge.typo3.org/issues/44852

> die Alpha, Test, Obsolete und Experimental geflaggt sind automatisch
> ausgeblendet sein.

http://forge.typo3.org/issues/44853


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

Hilft auch nicht immer, aber ich glaube dazu gibt es schon eine Issue.


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

http://forge.typo3.org/issues/44854


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

http://forge.typo3.org/issues/44855

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

Dafür haben neuere Uploads bei uns eine höhere Gewichtung. Updates 
werden also mit einer besseren Position in den Suchergebnissen belohnt.

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

Dazu gibt es schon Issues, wir sind dran, aber sind für jede 
Unterstützung offen und dankbar,


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

+1

> Changelogs automatisch aufbereiten.

Leider nicht ganz einfach, weil zu viele verschiedene Stile


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

+1

> 3.3) SXW ist blöd. Warum sollen Extensionentwickler doppelt und dreifach
> belastet werden.

Das wurde erkannt und deswegen gibt es den Umstieg auf ReST

> 3.4) Hilfe zur Selbsthilfe. Jede Extension die im Forge angelegt wird,
> sollte auch einen Link zu einer Plattform zum präferierten Useraustausch
> bereitstellen.

Halte ich für sinnvoll, fällt aber auch unter 1.7


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

+1000 - ergo, die deutsche Liste schließen? :)

Eine deutsche Liste sollte es schon geben, aber vielleicht nicht 
unbedingt auf offiziellen Kanälen?

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

http://forge.typo3.org/issues/44856

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

schwieriges, und für sich ein eigenes Thema.


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

Ja, das ist durchaus ein Problem.

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

entspricht dem Punkt zuvor.


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

Ich denke da sind wir auf einem guten Weg, siehe Budget Poll


Ingo

-- 
Ingo Renner
TYPO3 Core Developer, Release Manager TYPO3 4.2

TYPO3 - Open Source Enterprise Content Management System
http://typo3.org

Apache Solr for TYPO3 -
Open Source Enterprise Search meets Open Source Enterprise CMS
http://www.typo3-solr.com