Hallo,
welche konkreten, neuen Fetaures (Inhaltselemente/Module usw.) sind eigentlich für kommende (LTS) Versionen geplant?
Bevor man alle GitHub Einträge dahingehend durchforstet - evtl. gibt es eine Planungsübersicht? ...
Danke
Franko
Druckbare Version
Hallo,
welche konkreten, neuen Fetaures (Inhaltselemente/Module usw.) sind eigentlich für kommende (LTS) Versionen geplant?
Bevor man alle GitHub Einträge dahingehend durchforstet - evtl. gibt es eine Planungsübersicht? ...
Danke
Franko
wird wohl eher so sein, wie Toflar das vom Entwicklertreffen berichtet hat - wer Lust hat was zu bauen, macht es...
Schon klar -Dennoch:Zitat:
Zitat von zonky
Als Grundlage der Anfrage hier die mit Label "feature" markierten aktuellen GitHub Einträge:
https://github.com/contao/contao/labels/feature
Alles sinnvolle Improvements!
Allerdings im weitesten Sinne keine "neuen" Content Features gemäß dieses Themas.
Am ehesten evtl. sowas wie #2781, #601 o. #55 (just a sample).
Dies soll keine Wishlist werden (obwohl es irgendwie darauf hinaus läuft :D).
Vielmehr eine Anfrage zur grundsätzlichen Ausrichtung/Vorgehensweise im Contao Kosmos diesbezüglich.
Mir ist klar das es folgende Gründe gibt:
- Der Core soll schlank bleiben
- Es gibt verschiedene Wege zur bel., eigenen Anpassung (Template/DCA/Hooks usw.)
- Es gibt die Möglichkeit über Erweiterungen (gerade zum Thema z.B. RSCE/Metamodel)
Ist alles korrekt und nachvollziehbar!
Auch ist es wahr (und nachvollziehbar) das man den enthusiastischen (OpenSource) Entwicklern (Core-Team o. Extension Anbieter)
nicht vorschreiben kann was diese umzusetzen haben o. immer zeitnah jede Extension mit jeder Contao Version aktuell gehalten werden kann!
Dennoch:
Bezüglich des Core haben wir LTS Versionen (zwecks Planungssicherheit). Mit jeder installierten Extension wird ein Update möglicherweise fraglich.
Sind features Teil des Cores ist dies kein Ding ...
Wie wäre es zumindest mit einer Art offiziellen GitHub Contao Awesome List.
Wenn auch nur um eine Art Sammlung/Übersicht des Bedarfs zu halten?
... wo bleibt denn da die Spannung, wenn wir User schon vorher alles kennen würden - "Wait, One More Thing" :D
Hm, ein Spannungsbogen ist immer toll (s. S. Jobs announcements :D).Zitat:
Zitat von zonky
Wie gesagt ich denke da nicht an einen birthdaymailer o.ä. -
Eher halt an grundlegendes wie neues CSS Grid Framework, Mini-Cal mit Jahresübersicht (12 Month) - so was in der Art ...
(obwohl auch das alles subjective wishes sind)
...
Ich will da kein Showstopper sein, aber die grundlegenden Sachen für Contao werden im Core-Team abgehandelt und die zusätzlichen Featuren wie z.B. die Bildbehandlung von Moritz kommen "von Außen".
Wenn ich mich richtig erinnere, gab es vor Jahren auch mal die Idee, vor dem Start der Entwicklung einer Erweiterung das mal kund zu tun um Parallelentwicklungen zu vermeiden oder Mitstreiter zu finden.
So richtig gefruchtet hat wohl nie...
Ich weiß. Es ist/bleibt die alte Frage:
Was gehört in den Core und warum?
Grundsätzlich könnte man die Aussage
"Der Core soll schlank bleiben es gibt ja andere Möglichkeiten"
dann auch so interpretieren das dann auch die Gallery o. der Slider etc. eigentlich dann ausgelagert werden könnten.
Fazit wäre der Contao Core bleibt hinsichtlich der aktuellen Content Features wie er ist ...
(Provokant - Nur als Ausgangsbasis)
Nochmal: Ich love Contao. Ich finde es toll und möchte niemanden auf die Füße treten.
Diesbezüglich könnte man m.M.n. dennoch zukünftige Vorgehensweisen zumindest erörtern.
Das Auslagern der Module wie Newsletter, Events, News, Liste usw. war ja schon ein Anfang...Zitat:
Zitat von Franko
Bei MM ist das ja komplett Modular - mit dem Core an sich kann man eigentlich nix anfangen... damit die "MM-Greenhons" am Anfang nicht überfordert sind gibt es Bundles, die mehrere Sachen en bloc installieren.
Nun ist die Zielgruppe von MM sicher eine etwas andere als Contao per se es ist - vondaher würde das Auslagern aller CS-Typen + optionalem wieder Einfügen bei den Newbies für zu viel Verwirrung sorgen.
Ist mir letztens erst in die Finger gefallen, falls du sowas meinst:Zitat:
Zitat von Franko
https://github.com/may17/awesome-contao
Jepp, Joe's Liste gibt es es gefühlt ja schon ewig ;)Zitat:
Zitat von Doi
Meinte eher "offiziell" im Sinne von: Was wird erwartet/gewünscht.
Bestenfalls nach einer Art Community Voting sortiert.
(Ganz unabhängig von einer tatsächlichen Umsetzung)
Für Feature Requests gibt es GitHub. Dort kannst du ja auch bei bestehenden Feature Requests ein Tumbs-up setzen.
Ok, laut Definition hast du Recht.Zitat:
Zitat von zonky
Also nicht "Core" sondern gemeint als Bestandteil einer z.B. LTS-Version ...
Jepp, thats the actual way.Zitat:
Zitat von Spooky
Ich könnte also einen "Feature Request" setzen.
Anhand der Zustimmungen (Tumbs-up) könnte man nachvollziehen wie sehr dieses feature erwartet wird.
In der Hoffnung das sich jemand dann anhand der Nachfrage der Umsetzung annimmt.
Allerdings gehen solche Anfragen m.M.n. in der Fülle der GitHub Requests unter. Wünschenswert wäre hierzu evtl.
eine einheitliche, offizielle Contao/GitHub Anlaufstelle die entsprechend breit verlinkt/kommuniziert wird.
Forum Leser/Contao Nutzer (die nicht jeden Tag GitHub Einträge verfolgen) könnten dann auch einfach voten/teilnehmen.
(Meinte ich mit offizieller Awesome List)
Vorteil:
- Einheitliche Bedarfs-Übersicht
- Einfache Einsicht bzw. Teilnahme/Voting
- Entwickler erhalten aktuelle Nachfrage Statistiken zwecks Priorisierung
Weiß nicht wie es andere Systeme handhaben (Tellerrand).
Wäre aber evtl. ein Anfang.
Kurzer Ausflug:Zitat:
Zitat von zonky
Ich hatte mich damals (vor langer Zeit :D) auf Typolight/Contao konzentriert da hier z.B. News/Events etc. Bestandteil waren.
Entsprechende Erweiterungen waren damals für z.B. Typo3 unzählig vorhanden.
Die richtige Erweiterung (passend zur Version) zu finden war nervig und zeitraubend (vom Update Workflow ganz zu schweigen).
Mittlerweile existieren auch f. Contao zahlreiche Erweiterungen
(Was eigentlich gut ist!).
Aber halt möglicherweise auch mehrere, von versch. Autoren, die gleiche Aufgaben abdecken.
Samples Buchung/Reservierung:
A / B / C / D / E
Bedeutet dann auch:
- Qual der Wahl
- Bei Contao Updates zuvor installierte Erweiterungen prüfen
Auch hier kennt evtl. jemand Konstrukte wie andere das Dilemma organisatorisch/technisch lösen?
Will sagen:
Eine von Contao organisierte, zentrale Anlaufstelle für z.B. immer wieder benötigte Widgets (z.B. BE Maps Geo-Coding usw.) wäre für Entwickler nützlich.
Oder eine Art Aufgaben orientierte, zentrale Contao Anlaufstelle an die sich mehrere Entwickler beteiligen können und nicht jeder separat die gleichen Aufgaben umsetzen.
Weiß nicht wie man sowas optimal organisieren könnte. Hilfreich wäre es aber um halt:
- Identische Aufgaben/Erweiterungen zu reduzieren
- Erweiterungs Pflege über Dev-Power zu bündeln
- Contao Update Workflow hinsichtlich Erweiterungen noch sicherer zu gestalten
das Ansinnen in allen Ehren, aber ich glaube das wird nix weil es da ein Dilemma gibt:
Man könnte sowas wie ein Siegel "Geprüfte Erweiterung" vergeben - aber wer prüft das und wer bezahlt den Aufwand?
Die meinsten Erweiterungen sind kostenfrei, so dass von dem/der Entwickler:in kein Geld zu erwarten ist.
Thema Spenden können wir gleich abkürzen - wird nix! siehe meine verschiedenen Ausführungen zu dem Thema bei MM.
Erweiterungen gegen Bezahlung anzubieten ist an sich eine Möglichkeit, die ich durchaus begrüßen würde. Nur wird man ggf. als "kleine Marketingbude" plötzlich zum Softwarehersteller und muss entsprechende Erwartungen an Qualität, Features und Support bieten. Das ist dann eigentlich nicht mehr das Kerngeschäft.
Was kann man dennoch machen?
* "kuratierte Listen" wie die von Joe oder die von mir zu DSGVO/Consent-Tools sind noch recht einfach zu handhaben
* es gab/gibt im CWiki zu bestimmten Themen wie z.B. Shops Vergleichslisten (letztes Update: 2018...) - sowas find ich ganz gut als Übersicht
* die Suche in den Erweiterungen zu einem Thema ist manchmal schwierig und wenn der/die Entwickler:in nicht die richtigen Worte in der Beschreibung haben, findet man das nicht - wenn mir so was auffällt, mach ich ein Ticket ... aber auch da liegt der Hase im Pfeffer: es gibt eine Vielzahl von Erweiterungen die entweder keine Readme haben oder wo außer dem Namen nichts weiter drinn steht :(
bei den Erweiterungen wäre die Frage, ob eine (ergänzende) Verschlagwortung durch Redakteure machbar wäre
Eine weitere Vorgehensweise wäre z.B.:
Für mich pers. sollten "Notification Center", "Change Language" oder "RockSolid Custom Elements" Bestandteil der Auslieferung sein.
Nun sind gerade diese Beispieel blöd gewählt, da man davon ausgehen kann,
das gerade diese Erweiterungen von der Pflege mit aktuellen Contao Versionen einher gehen :D
(Also eine Integration überflüssig ist).
Aber:
Gerade bei der RSCE könnte man womöglich zahlreiche FE-Erweiterungen (Slider/Galleries/Team-Views/Referenzen/Portfolios/Job-Lists usw.) einsparen.
Die "Hürde" für viele wäre dabei jedoch halt die Umsetzung.
Hatte schon mal im Forum angeregt hierzu eine Art public Gist-List mit funktionierenden RSCE Datei(en) zu sammeln.
Hier wäre halt die Community gefragt!
Sofern es dann auch hierzu wieder eine einheitliche, zentrale Übersicht gäbe/bereit gestellt würde.
Auch damit könnte man dann auf viele FE-Erweiterungen verzichten - und hinsichtlich Contao Updates wäre "nur" eine einzige Erweiterung zu berücksichtigen
....
aber auch damit müsste man zum Typ "technisch interessierte/r Hausmann/-frau" sein - da ich technischen Support für einige Agenturen mache kann ich da nur sagen, das die das damit nicht gebacken bekommen.Zitat:
Zitat von Franko
Ich kann da nur für mich sprechen, aber RSCE sind bei mir doch immer speziell auf einen einzigen Anwendungsfall zugeschnitten. Ich baue die selten so, dass sie universell verwendbar wären. Insofern sehe ich da nur eine sehr sehr eingeschränkte Möglichkeit, das weiter zu teilen.Zitat:
Zitat von Franko
hmm - Ich versuche meine Bezeichnungen der Elemente und der Widgets recht allgemein zu halten und wenn ich was neues bauen muss kopiere ich mir die config aus vorhandenen Sachen zusammen - die Templates muss man dann nochmal bezüglich CSS-Klassen überarbeitenZitat:
Zitat von lucina
Versuchen tue ich das auch, und ich nehme mir auch immer vor, etwas wieder zu verwerten. Klappt nur nie.
Neulich erst wieder: Ein Mediaplayer, der Audio, Video und Krams von Spotify & Konsorten anspielt im Look & Feel der Site ... Da war dann halt das Markup speziell & potentiell teilbar, aber ohne CSS hat's halt keine Freude gemacht. Und das CSS für die Buttons war halt auch sehr speziell.
Insofern ... ;-)
vom eigentlichen Thema sind wir weit weg gekommen...Zitat:
Zitat von Franko
was halte ich fest:
* Übersicht der Core-Feature-Requests auf Github abfragen - https://github.com/contao/contao/iss...abel%3Afeature
* der Rest ist schwierig, gibt keine Finanzierung, zu wenige ziehen mit...
oder?
Ich teile deine Anmerkungen und befürchte selbiges (Kommerzielle Angebote lasse ich mal außen vor).Zitat:
Zitat von zonky
Auch ist wohl hinsichtlich Sponsoring/Monetarisierung nicht viel zu erwarten (Thema haben/hatten wir ja und du kannst das vor allen (zusammen mit Andy) besser einschätzen).
Würde dennoch gerne nochmals Ziele zusammenfassen:
- Zentrale Übersicht erwünschter Funktionalitäten (inkl. (Community) Voting Möglichkeit)
- Mögliche Prio der Umsetzung anhand dieser Liste/Status/Analyse
- Reduzierte Erweiterung Auswahl hinsichtlich identischer Aufgaben/Lösungen
- Bündelung der Entwickler Power anhand obiger Aufgaben/Prios
Wie gesagt - Weiß auch nicht wie man das technisch/Orga nachhaltig realisieren könnte.
Halt als Anregung zu lesen ...
Wäre aber ideal um weitere Contao Vorteile nachhaltig gegenüber Mitbewerbern hervorheben zu können ...
bzgl.siehe https://community.contao.org/de/show...l=1#post547052Zitat:
Zitat von Franko
Du kannst aber auch Feature Entwicklungen für Contao finanzieren lassen.
zu A: https://github.com/contao/contao/iss...abel%3AfeatureZitat:
Zitat von Franko
zu B: phuuu was soll ich dazu als pro vs. contra sagen: https://github.com/contao/contao/issues/3097
zu C: das geht m.E. nur über kuratierte Listen oder besser Featuretabellen... wer machts?!?
zu D: die meisten Programmierer sind schon etwas "eigen" ;-) - da sehe ich wenig Chancen
@zonky/@Spooky
Jepp, die Möglichkeiten existieren.
Frage halt ob darüberhinaus noch Möglichkeiten existieren ...
Bin gerne bereit mich von der Orga einzubringen ...Zitat:
zu C: das geht m.E. nur über kuratierte Listen oder besser Featuretabellen... wer machts?!?
Tja, dann bringt es alles nichts. Sollte man es dennoch versuchen?Zitat:
zu D: die meisten Programmierer sind schon etwas "eigen" ;-) - da sehe ich wenig Chancen
Rewards kann man sich ja überlegen ala: "Teil des Contao Alliance Teams (Erweiterungen)" oder so - im Sinne des OpenSource Gedankens.
Wie auch immer: "Just my two cents" ...
Und wenn man zusätzliche Anreize bieten könnte?Zitat:
zu D: die meisten Programmierer sind schon etwas "eigen" ;-) - da sehe ich wenig Chancen
Stelle mir vor das man irgendwie anhand einer public voting/wishlist
oder auch einfach manuell zum Beispiel dann eine offizielle Aufgabe auf GitHub setzt:
Beispiel: Buchung/Reservierung Erweiterung der Contao Community Alliance
https://github.com/contao/community-...ooking-bundle/
Hier werden zuvor Ziele gesetzt, Entwickler gesucht/eingeladen bzw. jeder kann sich beteiligen.
Ziel ist immer, unabhängig von den jeweiligen Aufgaben,
eine ähnliche, zeitnahe Pflege hinsichtlich Contao Updates wie die Contao eigenen News/Events etc. Umsetzungen.
Weiterhin mit dem Ziel diejenigen Entwickler per Aufgabe zu bündeln die sich bereits mit den eigenen Erweiterungen zum Thema beschäftigt hatten.
Benefit(s):
Wie bereits oben beschrieben ala Rewards von "Teil der ..." im eigenen Repository ...
Oder noch mehr:
Ähnlich wie die Umsetzung der "Contao Marketing Suite".
Also grundsätzliche free functions und noch mehr Funktionen über eine kostenpflichtige Lizenzierung.
Wie die Einnahmen dann aufgeteilt werden könnten - lass ich mal zunächst offen.
Dennoch dann wohl möglicherweise mehr Zustimmung/Abrufe als "lonesome" Extension Entwickler erreichen würden ...
sorry, dass ich das so hart sagen muss - das halte ich für Naiv!Zitat:
Zitat von Franko
Die Realität sagt, sowas ist kein Selbstläufer.
Bei MM gibt es ein ähnliches Konzept - ABER! wenn es nicht einen Zampano gibt, der die verteilten Schäfchen regelmäßig! zusammentrommelt, Geld eintreibt, Werbung macht, Kommunikationslegasthenieen ausgleicht usw. dann-wird-das-nüscht!
noch kleine Ergänzung: bei MM habe ich durchaus finanzielle Mittel zur Verfügung, um die (Mit-)Arbeiten auch zu honorieren - aber selbst damit ist offensichtlich niemand willens oder in der Lage da mitzuarbeiten...Zitat:
Zitat von Franko
Kein Ding - Verstehe das :DZitat:
Zitat von zonky
Obwohl es ja nicht unüblich ist das sich mehrere Entwickler an einem (GitHub) Projekt/Extension beteiligen.
Sei es als ständige Contributors oder via PR's/Issues.
Empfinde ich in jedem Fall performanter hinsichtlich Aktualisierung/Pflege etc. als dies über inhaltlich identische aber separate Projekte zu bewerkstelligen ...
(Anmerkung: Wobei Vielfalt ansonsten nicht schlecht ist)
Naiv? Offenbar:
Thats the point ...Zitat:
Wenn ich mich richtig erinnere, gab es vor Jahren auch mal die Idee, vor dem Start der Entwicklung einer Erweiterung das mal kund zu tun um Parallelentwicklungen zu vermeiden oder Mitstreiter zu finden.
So richtig gefruchtet hat wohl nie...
Ergänzung zu RSCE:
Wie angesprochen m.M.n. eine elegante Lösung.
Evtl. könnte man dies weiter pushen zwecks easy Handling ala:
Add element generator #20 bzw.:
https://app.intco.it/rsce-visual-editor/index.html
Zu dem Editor habe ich kein Git oder Bitbucket gefunden...Zitat:
Zitat von Franko
Thema Finanzierung:
Was bisher ganz gut funktioniert hat, dass man Erweiterungen oder neuere Funktionen davon erst an einen Personenkreis gibt, die dafür etwas Geld locker machen - bei MM nennt sich das "early-adopter-Programm".
Das Konzept hat auch schon bei Erweiterungen von Fritz und David (Netzmacht) funktioniert.
Pferdefuß: man muss als Programmierer erstmal in Vorleistung gehen oder es gibt jemanden, der das Vorfinanziert und dann das Geld komplett/anteilig wieder einsammelt.
Die Verteilung ist mit PackDis! recht einfach geworden.
Man muss dabei aber beachten, auch Zeit bzw. Budget für Rechnungschreiben usw. einzuplanen - dadurch sollte man bei der Geldspritze nach unten ein Limit setzen z.B. 50€ oder 100€ (Netto)
Ich leider auch nicht.Zitat:
Zitat von zonky
Da es als Beispiel im GitHub Issue geführt wurde hab ich es hier nochmals verlinkt.
So was in der Art wäre eine hilfreiche, einfache RSCE Unterstützung für viele Nutzer ...
Äh, hast du einen Link dazu zum einlesen?Zitat:
Zitat von zonky
das ist ein Paketmanager von Chris, Nicky und David den man selbst hosten muss - der ist aber nicht frei verfügbar
Beispiel: https://docs.contao.org/manual/de/er.../#installation
Mit RSCE ist beim Einstieg doch der/die ein oder andere überfordert - siehe https://community.contao.org/de/show...l=1#post547300Zitat:
Zitat von Franko
Mit einer umfangreicheren Beispielsammlung könnte man da sicher was wuppen...
der Link führt auf ne FehlerseiteZitat:
Zitat von zonky
Gesendet von iPhone mit Tapatalk Pro
Der Link funktioniert.Zitat:
Zitat von designpilot
@DP: du muss auf den Link klicken und darfst den nicht abschreiben wie angezeigt ;-)Zitat:
Zitat von designpilot