NEWS
Core-Entwicklung zu schnell?
-
@apollon77 wo gibt es denn kurz Protokolle zu den Dev-Treffen? Ich nehme dort nie teil weil ich kein Entwickler bin aber ich finde einige Themen schon für alle relevant und deshalb würden mich dort die Ergebnisse interessieren wie dort entschieden wurde...
P. S. Die Entwicklung vom js-controller hat schon ggü den ersten js-controller Versionen deutlich fahrt aufgenommen. Für mich als Nicht-Entwickler meist nicht relevant, bis auf die letzen Versionen, die doch viel Zeit gekostet haben durch die "Zwangsumstellung" auf userdata und die zugemüllten Log-Dateien.
Im Nachhinein bin ich froh über die Umstellung, da ich in diesem Zuge mal wieder aufgeräumt und neu strukturiert habe.
Man merkt schon, dass eine Menge Arbeit in der Entwickklung vom js-controller steckt, die Du und die anderen dort investieren, deshalb mein großer Dank. Ohne ioBroker wäre meine Automation nicht mehr vorstellbar.@cash sagte in Core-Entwicklung zu schnell?:
wo gibt es denn kurz Protokolle zu den Dev-Treffen?
Bitte benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Immer Daten sichern! -
@apollon77 wo gibt es denn kurz Protokolle zu den Dev-Treffen? Ich nehme dort nie teil weil ich kein Entwickler bin aber ich finde einige Themen schon für alle relevant und deshalb würden mich dort die Ergebnisse interessieren wie dort entschieden wurde...
P. S. Die Entwicklung vom js-controller hat schon ggü den ersten js-controller Versionen deutlich fahrt aufgenommen. Für mich als Nicht-Entwickler meist nicht relevant, bis auf die letzen Versionen, die doch viel Zeit gekostet haben durch die "Zwangsumstellung" auf userdata und die zugemüllten Log-Dateien.
Im Nachhinein bin ich froh über die Umstellung, da ich in diesem Zuge mal wieder aufgeräumt und neu strukturiert habe.
Man merkt schon, dass eine Menge Arbeit in der Entwickklung vom js-controller steckt, die Du und die anderen dort investieren, deshalb mein großer Dank. Ohne ioBroker wäre meine Automation nicht mehr vorstellbar. -
@cash sagte in Core-Entwicklung zu schnell?:
wo gibt es denn kurz Protokolle zu den Dev-Treffen?
@sigi234 ich kann ja blind sein aber ich finde dort kein Protokoll. Z. B. Dezembertreffen dort gab es ein Thema: Roles und typeDetector - "Welche neuen Rollen und ggf Gerätetypen haben wir eingeführt?"
Aber im dem Thread steht nicht was es nun gab oder nicht...
Oder der User e.s. fragt ob ein Thema angesprochen wurde. Antwort: "Ja. Lösung ist angedacht"
Unter Kurz-Protokoll verstehe ich etwas anderes...
-
@sigi234 ich kann ja blind sein aber ich finde dort kein Protokoll. Z. B. Dezembertreffen dort gab es ein Thema: Roles und typeDetector - "Welche neuen Rollen und ggf Gerätetypen haben wir eingeführt?"
Aber im dem Thread steht nicht was es nun gab oder nicht...
Oder der User e.s. fragt ob ein Thema angesprochen wurde. Antwort: "Ja. Lösung ist angedacht"
Unter Kurz-Protokoll verstehe ich etwas anderes...
@cash sagte in Core-Entwicklung zu schnell?:
Aber im dem Thread steht nicht was es nun gab oder nicht...
Letzte neue Typen gab es im Juni oder Juli ... wir haben das aber als eines der "immer auf der Agenda Themen". Von daher: Ja hätte ein "nichts neues" Klarheit gebracht ... @ldittmar
Oder der User e.s. fragt ob ein Thema angesprochen wurde. Antwort: "Ja. Lösung ist angedacht"
Wenn etwas "Zu kurz" ist -wie oben geschrieben - einfach im Thread Fragen und wir ergänzen das fehlende.
-
@sigi234 ich kann ja blind sein aber ich finde dort kein Protokoll. Z. B. Dezembertreffen dort gab es ein Thema: Roles und typeDetector - "Welche neuen Rollen und ggf Gerätetypen haben wir eingeführt?"
Aber im dem Thread steht nicht was es nun gab oder nicht...
Oder der User e.s. fragt ob ein Thema angesprochen wurde. Antwort: "Ja. Lösung ist angedacht"
Unter Kurz-Protokoll verstehe ich etwas anderes...
@cash sagte in Core-Entwicklung zu schnell?:
@sigi234 ich kann ja blind sein aber ich finde dort kein Protokoll. Z. B. Dezembertreffen dort gab es ein Thema: Roles und typeDetector - "Welche neuen Rollen und ggf Gerätetypen haben wir eingeführt?"
Aber im dem Thread steht nicht was es nun gab oder nicht...@ldittmar sagte in Meeting für ioBroker Core/Dev/Admin 15.12.21 20:30:
Alles was im Meeting besprochen wurde, wird hier unterhalb der Themen, stichpunktweise dokumentiert.
-
Ich stell jetzt mal ganz Provokant eine Frage:
Wie viel Zeit, in welchem Intervall, soll/muss man als (Adapter) Entwickler den Investieren um auf dem Laufenden zu bleiben?Das würde mich brennend interessieren.
Die Frage von @Eisbaeeer warum das Adapter Gerüst so Komplex ist, ist schon berechtigt. @AlCalzone Antwortet darauf das es doch gar nicht Komplex ist, aber er Arbeitet auch Ständig damit und hat es zum Teil mit entwickelt. Logisch das er das anders sieht.
Aber jemand der nur von zeit zu Zeit mal einen Adapter Entwickelt oder ganz neu ist, dem erschließt sich das nicht.Versucht doch mal die Sichtweise derer an zu nehmen die nicht so Tief im ganzen Stecken und schmettert nicht gleich alles ab.
Die Dev Meeting Protokolle geben meistens nicht mal ein Bruchteil der Informationen wieder, die im Meeting tatsächlich besprochen wurden. Das ist gut um zumindest zu sehen worüber gesprochen wurde, nicht aber um an Detail Informationen zu kommen.
Auch die Changelogs sind nur bedingt als Informationsquelle zu sehen. Oft fehlt der Kontext zu einem Eintrag und man hat gar keine Vorstellung davon was sich geändert hat oder welche Auswirkungen es hat.
In einigen fällen würde es ausreichen wenn die Einträge Ausführlicher wären, nur reicht das eben nicht immer um zu verstehen was genau ein Change eigentlich bedeutet.Hier Übrigens mal was Positives dazu: Die Qualität der Changelogs hat sich deutlich verbessert.
Gefühlt geht die ganze Diskussion hier schon wieder nur um die Doku, aber das hat mit der Eingangsfrage nur zum Teil zu Tun.
Es betrifft die Kommunikation genau so wie die Entscheidungsfindung. @apollon77 hat schon recht das es bei einigen Themen den versuch gab das ganze zu Klären bevor man etwas umgesetzt hat.Das Dev Meeting ist meiner Meinung nach keine gute Umgebung um ein bestimmtes Thema zu Diskutieren, aber durchaus geeignet um eine Entscheidung zu treffen nachdem Diskutiert wurde.
Eigentlich wäre das Forum ein geeigneter Platz um zu Diskutieren, wenn die Diskussionen denn Zielgerichtet Verlaufen würden. Leider driften die fast immer ab und niemand sammelt am Ende die Themen bezogenen Ergebnisse zusammen.
Mal ganz davon abgesehen das die Beteiligung oft gering ist, am Ende ist es immer die selbe Handvoll Personen.Und daran sollten wir Arbeiten!
@apollon77 sagte in Core-Entwicklung zu schnell?:
Das ist ein schönes Beispiel. Ja gibt es - seit fast 2 Jahren mit js-controller 2.2.8 (2020-01-24), steht im Changelog
Darüber hinaus findet sich aber kein Hinweis darauf und genau deswegen hab ich es als Beispiel genommen. Ich müsste jetzt also alle Changelogs von Anfang an lesen um zu sehen das diese Funktion hinzugefügt wurde. Das ist absurd.
@apollon77 sagte in Core-Entwicklung zu schnell?:
Ja und auch ich kann dir diese Garantie nicht geben. Genauso wenig hast Du eine Garantie das Nodejs 18 nicht nen Breaking change enthält der dir alles kaputt macht oder eine deiner Libraries in einer neuen Version alles umstellt. Sorry, that's (Developer) Life ...
Genau das ist doch der Punkt, deine Aussage klang wie eine Garantie wenn man es nur richtig macht. Und damit hast du auch gleich Inkludiert das die Pflege eines Adapters dann nicht Zeitaufwändig ist.
Und damit kommen wir wieder zum Ausgangspunkt: Wieso Entwickler lieber keine neuen Adapter mehr erstellen, weil sie davon aus gehen das es immer (wieder) Aufwändiger wird sie zu erstellen und zu Pflegen.Irgendjemand hat das hier im Thema schon angesprochen, es wäre Sinnvoll den Aufwand zu reduzieren. Diverse Tools versuchen das, aber diese Tools verursachen auch erstmal wieder Aufwand weil man sich einarbeiten muss.
Ganz davon abgesehen das es mit den Tools auch Probleme geben kann, die einen Nerven kosten und man sich dann Entscheidet ohne zu Arbeiten.Beim Release Script hatte ich so einen Fall, es war für mich nicht Nutzbar. Die Fehlermeldung ergab keinen Sinn und irgendwann nach Stunden ging mir die Lust aus mich damit zu beschäftigen, also bin ich den weg zu Fuß gegangen.
Nach ein paar Wochen wollte ich es dann doch schaffen mit dem Release Script zu Arbeiten und hab das Problem nach weiteren Stunden zusammen mit @AlCalzone auch gefunden.Aber ich will mir nicht jedesmal so viel Zeit nehmen müssen wenn ich ein neues Tool nutzen möchte.
@apollon77 sagte in Core-Entwicklung zu schnell?:
Wir sind auf einem guten Weg und das sollten wir auch bewusst sagen und "feiern"!
Auf jeden Fall. Besonders das Feiern, den wenn wir etwas Feiern wird auch Kommuniziert was gefeiert wird.
Trotzdem sollte das nicht als Ablenkung genutzt werden.
Dann geb ich auch mal noch meine Sichtweise dazu.
Ich fand „Entwicklung geht zu schnell“ für mich sehr treffend.
Es geht mir weniger um den js-controller und ggf. die deprecations aus der neuen Version, die sind zwar auch nerven, aber sehe eher das ganze drumherum was sich mal schnell ändert.Zum einen gibt es die Änderungen die außerhalb von ioBroker stattfinden:
- nodejs,
- 3rd-party API,
- die Geräte selbst (neue Funktionen, neue Gerätespektrum,…)
- … usw.
Teilweise gibt es nicht einmal eine offizielle Doku um etwas aufzubauen und man weiß auch nicht so recht was man da an dependencies einbindet.
Zum anderen sind es die Dinge in ioBroker selbst:
- Umstellung auf compact mode,
- template/create adapter (mit den best practices), was man dann auch nachziehen möchte
- neue Funktionsaufrufe (auch teilweise als Ersatz was man vorher im Adapter hatte)
- admin Umstellungen
- neue Parameter in io-package
- … usw
- und auch die richtige Definition der Objekte ;-) (wobei das eher ein Adapterfehler aus der Vergangenheit ist)
Für mich ist es ein Hobby und hauptberuflich bin ich kein Entwickler, bin also nicht mit allen Tricks und best practices in JS bewandert. Aber man lernt dazu. Also ist es Spaß an der Freude, das etwas läuft und auch anderen dienlich ist.
Die neuen Tools und auch Testautomatisierung kann ich nur unterstützen. Ich bin ein großer Fan von automatisierten Tests und Konsistenzprüfungen. Da hätte ich den Wunsch, daß sich hier bei den Integrationstests noch einiges tut. Gerade wenn man einen mockserver anwirft, der mit dem Adapter echte Daten austauscht.
@jey-cee
Die Frage nach dem Zeitaufwand für die Adapterentwicklung und Maintenance ist wirklich berechtigt.
Meine obigen Aspekte sind natürlich auch mit dem Verfolgen des Forums oder nun der Entwicklerseite machbar. Wendet man aber nicht die Zeit auf, dann wird man quasi kalt erwischt und es ist für einen selbst hektisch und gefühlt zu schnell.
D.h. zu der eigentlichen Entwicklung oder den Adapter auf Stand zu halten kommt ein nicht unwesentlicher Teil sich in die Dinge zu vertiefen.
Parallel möchte man aber auch gern andere neue Dinge/Adapter/Vis ausprobieren.Am Ende fehlt irgendwie die Zeit.
Und ja, auch ich habe mir schon des öfteren gesagt, daß ich keinen weiteren Adapter entwickeln sollte, da es doch recht viel Zeit in Anspruch nimmt.
Die Doku wird besser, aber auch die richtige Info finden ist immer noch eine Herausforderung. Immerhin gibt es nach dem aufmerksamen Lesen diese Threads einige neue Anlaufstellen, die ich vorher nicht kannt. In Vergangeheit war in der Tat eher „wie wurde es in einem anderen Adapter gelöst“ zielführender.
Ein Hinweis zur Doku, vielfach reflektiert die Doku den Zustand als solches, was aber eine sinnvolle Verwendung oder best practice ist, ist meist nicht der Fokus, aber genau das hilft meist erst recht weiter für das Verständnis.Gruß
KlausAdapterüberblick: Profil Github;
Wenn der Adapter gefällt und nützlich ist, bitte ins Repo gehen und Star setzen. Danke
Ein Aufruf: video
-
Dann geb ich auch mal noch meine Sichtweise dazu.
Ich fand „Entwicklung geht zu schnell“ für mich sehr treffend.
Es geht mir weniger um den js-controller und ggf. die deprecations aus der neuen Version, die sind zwar auch nerven, aber sehe eher das ganze drumherum was sich mal schnell ändert.Zum einen gibt es die Änderungen die außerhalb von ioBroker stattfinden:
- nodejs,
- 3rd-party API,
- die Geräte selbst (neue Funktionen, neue Gerätespektrum,…)
- … usw.
Teilweise gibt es nicht einmal eine offizielle Doku um etwas aufzubauen und man weiß auch nicht so recht was man da an dependencies einbindet.
Zum anderen sind es die Dinge in ioBroker selbst:
- Umstellung auf compact mode,
- template/create adapter (mit den best practices), was man dann auch nachziehen möchte
- neue Funktionsaufrufe (auch teilweise als Ersatz was man vorher im Adapter hatte)
- admin Umstellungen
- neue Parameter in io-package
- … usw
- und auch die richtige Definition der Objekte ;-) (wobei das eher ein Adapterfehler aus der Vergangenheit ist)
Für mich ist es ein Hobby und hauptberuflich bin ich kein Entwickler, bin also nicht mit allen Tricks und best practices in JS bewandert. Aber man lernt dazu. Also ist es Spaß an der Freude, das etwas läuft und auch anderen dienlich ist.
Die neuen Tools und auch Testautomatisierung kann ich nur unterstützen. Ich bin ein großer Fan von automatisierten Tests und Konsistenzprüfungen. Da hätte ich den Wunsch, daß sich hier bei den Integrationstests noch einiges tut. Gerade wenn man einen mockserver anwirft, der mit dem Adapter echte Daten austauscht.
@jey-cee
Die Frage nach dem Zeitaufwand für die Adapterentwicklung und Maintenance ist wirklich berechtigt.
Meine obigen Aspekte sind natürlich auch mit dem Verfolgen des Forums oder nun der Entwicklerseite machbar. Wendet man aber nicht die Zeit auf, dann wird man quasi kalt erwischt und es ist für einen selbst hektisch und gefühlt zu schnell.
D.h. zu der eigentlichen Entwicklung oder den Adapter auf Stand zu halten kommt ein nicht unwesentlicher Teil sich in die Dinge zu vertiefen.
Parallel möchte man aber auch gern andere neue Dinge/Adapter/Vis ausprobieren.Am Ende fehlt irgendwie die Zeit.
Und ja, auch ich habe mir schon des öfteren gesagt, daß ich keinen weiteren Adapter entwickeln sollte, da es doch recht viel Zeit in Anspruch nimmt.
Die Doku wird besser, aber auch die richtige Info finden ist immer noch eine Herausforderung. Immerhin gibt es nach dem aufmerksamen Lesen diese Threads einige neue Anlaufstellen, die ich vorher nicht kannt. In Vergangeheit war in der Tat eher „wie wurde es in einem anderen Adapter gelöst“ zielführender.
Ein Hinweis zur Doku, vielfach reflektiert die Doku den Zustand als solches, was aber eine sinnvolle Verwendung oder best practice ist, ist meist nicht der Fokus, aber genau das hilft meist erst recht weiter für das Verständnis.Gruß
Klaus@foxthefox sagte in Core-Entwicklung zu schnell?:
Ich bin ein großer Fan von automatisierten Tests und Konsistenzprüfungen. Da hätte ich den Wunsch, daß sich hier bei den Integrationstests noch einiges tut. Gerade wenn man einen mockserver anwirft, der mit dem Adapter echte Daten austauscht.
Ich hab das in ein paar meiner Adapter drin (und auch ein paar Core-Adapter haben das recht viel wie sql/influxDB und History, auch MQTT, ical ...), teilweise sehr "exzesiv" ... und ehrlich: Der Aufwand das mit einer sinnvollen Abdeckung hinzubekommen war dabei mindestens so groß wie es den Adapter und die Lib zusammen zu schreiben :-) Den Aufwand sind nur wenige Entwickler bereit zu investieren. Auch weil ggf der Aufwand das ausgewählte Device oder den Service zu Mocken sehr schwierig (bis teilweise unmöglich). technisch möglich ist fast alles was mocking angeht ... HTTP sehr easy, aber auch Serialport und andere Network-Protokolle gehen ... man geht aber je nach Protokoll sehr tief runter und muss sich in vieles einarbeiten was sonst zB eine Lib die man nutzt für einen wegkapselt :-)
Rein faktisch kannst Du das alles mit dem testing Framewerk (sowohl alt wie auch neu) alles machen, wobei wir noch wenige Adapter haben die mit dem neuen Framework hier umfangreiche Tests gebaut haben.
-
@foxthefox sagte in Core-Entwicklung zu schnell?:
Ich bin ein großer Fan von automatisierten Tests und Konsistenzprüfungen. Da hätte ich den Wunsch, daß sich hier bei den Integrationstests noch einiges tut. Gerade wenn man einen mockserver anwirft, der mit dem Adapter echte Daten austauscht.
Ich hab das in ein paar meiner Adapter drin (und auch ein paar Core-Adapter haben das recht viel wie sql/influxDB und History, auch MQTT, ical ...), teilweise sehr "exzesiv" ... und ehrlich: Der Aufwand das mit einer sinnvollen Abdeckung hinzubekommen war dabei mindestens so groß wie es den Adapter und die Lib zusammen zu schreiben :-) Den Aufwand sind nur wenige Entwickler bereit zu investieren. Auch weil ggf der Aufwand das ausgewählte Device oder den Service zu Mocken sehr schwierig (bis teilweise unmöglich). technisch möglich ist fast alles was mocking angeht ... HTTP sehr easy, aber auch Serialport und andere Network-Protokolle gehen ... man geht aber je nach Protokoll sehr tief runter und muss sich in vieles einarbeiten was sonst zB eine Lib die man nutzt für einen wegkapselt :-)
Rein faktisch kannst Du das alles mit dem testing Framewerk (sowohl alt wie auch neu) alles machen, wobei wir noch wenige Adapter haben die mit dem neuen Framework hier umfangreiche Tests gebaut haben.
@apollon77 sagte in Core-Entwicklung zu schnell?:
@foxthefox sagte in Core-Entwicklung zu schnell?:
Ich bin ein großer Fan von automatisierten Tests und Konsistenzprüfungen. Da hätte ich den Wunsch, daß sich hier bei den Integrationstests noch einiges tut. Gerade wenn man einen mockserver anwirft, der mit dem Adapter echte Daten austauscht.
Ich hab das in ein paar meiner Adapter drin (und auch ein paar Core-Adapter haben das recht viel wie sql/influxDB und History, auch MQTT, ical ...), teilweise sehr "exzesiv" ... und ehrlich: Der Aufwand das mit einer sinnvollen Abdeckung hinzubekommen war dabei mindestens so groß wie es den Adapter und die Lib zusammen zu schreiben :-) Den Aufwand sind nur wenige Entwickler bereit zu investieren. Auch weil ggf der Aufwand das ausgewählte Device oder den Service zu Mocken sehr schwierig (bis teilweise unmöglich). technisch möglich ist fast alles was mocking angeht ... HTTP sehr easy, aber auch Serialport und andere Network-Protokolle gehen ... man geht aber je nach Protokoll sehr tief runter und muss sich in vieles einarbeiten was sonst zB eine Lib die man nutzt für einen wegkapselt :-)
Rein faktisch kannst Du das alles mit dem testing Framewerk (sowohl alt wie auch neu) alles machen, wobei wir noch wenige Adapter haben die mit dem neuen Framework hier umfangreiche Tests gebaut haben.
Ich mach es ja im neuen Framework auch schon mit dem fritzdect und musiccast :blush:
Ja, die wenigsten nutzen es überhaupt und noch weniger nutzen wahrscheinlich das Framework aus dem template.
Und ja, das ist aufwendig, aber hat sich bei meinen beiden Adaptern gelohnt. Man injiziert die unbekannten Antworten und der Adapter spuckt die gleichen Fehler in der eigenen Umgebung aus.
Wahrscheinlich wär es damals das Beste gewesen im neuen Framework die alten Tests zu belassen, aber die Möglichkeit hatte ich damals nicht erkannt (und man will ja auch auf Stand sein.)
-
Dann geb ich auch mal noch meine Sichtweise dazu.
Ich fand „Entwicklung geht zu schnell“ für mich sehr treffend.
Es geht mir weniger um den js-controller und ggf. die deprecations aus der neuen Version, die sind zwar auch nerven, aber sehe eher das ganze drumherum was sich mal schnell ändert.Zum einen gibt es die Änderungen die außerhalb von ioBroker stattfinden:
- nodejs,
- 3rd-party API,
- die Geräte selbst (neue Funktionen, neue Gerätespektrum,…)
- … usw.
Teilweise gibt es nicht einmal eine offizielle Doku um etwas aufzubauen und man weiß auch nicht so recht was man da an dependencies einbindet.
Zum anderen sind es die Dinge in ioBroker selbst:
- Umstellung auf compact mode,
- template/create adapter (mit den best practices), was man dann auch nachziehen möchte
- neue Funktionsaufrufe (auch teilweise als Ersatz was man vorher im Adapter hatte)
- admin Umstellungen
- neue Parameter in io-package
- … usw
- und auch die richtige Definition der Objekte ;-) (wobei das eher ein Adapterfehler aus der Vergangenheit ist)
Für mich ist es ein Hobby und hauptberuflich bin ich kein Entwickler, bin also nicht mit allen Tricks und best practices in JS bewandert. Aber man lernt dazu. Also ist es Spaß an der Freude, das etwas läuft und auch anderen dienlich ist.
Die neuen Tools und auch Testautomatisierung kann ich nur unterstützen. Ich bin ein großer Fan von automatisierten Tests und Konsistenzprüfungen. Da hätte ich den Wunsch, daß sich hier bei den Integrationstests noch einiges tut. Gerade wenn man einen mockserver anwirft, der mit dem Adapter echte Daten austauscht.
@jey-cee
Die Frage nach dem Zeitaufwand für die Adapterentwicklung und Maintenance ist wirklich berechtigt.
Meine obigen Aspekte sind natürlich auch mit dem Verfolgen des Forums oder nun der Entwicklerseite machbar. Wendet man aber nicht die Zeit auf, dann wird man quasi kalt erwischt und es ist für einen selbst hektisch und gefühlt zu schnell.
D.h. zu der eigentlichen Entwicklung oder den Adapter auf Stand zu halten kommt ein nicht unwesentlicher Teil sich in die Dinge zu vertiefen.
Parallel möchte man aber auch gern andere neue Dinge/Adapter/Vis ausprobieren.Am Ende fehlt irgendwie die Zeit.
Und ja, auch ich habe mir schon des öfteren gesagt, daß ich keinen weiteren Adapter entwickeln sollte, da es doch recht viel Zeit in Anspruch nimmt.
Die Doku wird besser, aber auch die richtige Info finden ist immer noch eine Herausforderung. Immerhin gibt es nach dem aufmerksamen Lesen diese Threads einige neue Anlaufstellen, die ich vorher nicht kannt. In Vergangeheit war in der Tat eher „wie wurde es in einem anderen Adapter gelöst“ zielführender.
Ein Hinweis zur Doku, vielfach reflektiert die Doku den Zustand als solches, was aber eine sinnvolle Verwendung oder best practice ist, ist meist nicht der Fokus, aber genau das hilft meist erst recht weiter für das Verständnis.Gruß
Klaus@foxthefox sagte in Core-Entwicklung zu schnell?:
Ein Hinweis zur Doku, vielfach reflektiert die Doku den Zustand als solches, was aber eine sinnvolle Verwendung oder best practice ist, ist meist nicht der Fokus, aber genau das hilft meist erst recht weiter für das Verständnis.
Du kannst dir ja mal das aktuelle rohe Gerüst anschauen und uns gerne Issues erfassen, wenn dir das etwas fehlt.
Genau eine solche Doku wie du sie wünschst scheint mir absolut wichtig und zentral. Aber es ist auch wichtig, dass wir Feedback wie deines (auf dem richtigen Weg) erhalten und als Basis für die Aktualisierung verwenden.
-
@foxthefox sagte in Core-Entwicklung zu schnell?:
Ein Hinweis zur Doku, vielfach reflektiert die Doku den Zustand als solches, was aber eine sinnvolle Verwendung oder best practice ist, ist meist nicht der Fokus, aber genau das hilft meist erst recht weiter für das Verständnis.
Du kannst dir ja mal das aktuelle rohe Gerüst anschauen und uns gerne Issues erfassen, wenn dir das etwas fehlt.
Genau eine solche Doku wie du sie wünschst scheint mir absolut wichtig und zentral. Aber es ist auch wichtig, dass wir Feedback wie deines (auf dem richtigen Weg) erhalten und als Basis für die Aktualisierung verwenden.
@unclesam sagte in Core-Entwicklung zu schnell?:
@foxthefox sagte in Core-Entwicklung zu schnell?:
Ein Hinweis zur Doku, vielfach reflektiert die Doku den Zustand als solches, was aber eine sinnvolle Verwendung oder best practice ist, ist meist nicht der Fokus, aber genau das hilft meist erst recht weiter für das Verständnis.
Du kannst dir ja mal das aktuelle rohe Gerüst anschauen und uns gerne Issues erfassen, wenn dir das etwas fehlt.
Genau eine solche Doku wie du sie wünschst scheint mir absolut wichtig und zentral. Aber es ist auch wichtig, dass wir Feedback wie deines (auf dem richtigen Weg) erhalten und als Basis für die Aktualisierung verwenden.
Da steuere ich doch gern ein paar Ideen (issues) bei.
Support us
669
Online32.5k
Benutzer81.6k
Themen1.3m
Beiträge