NEWS

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.

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.

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.

sigi234

Mal ganz davon abgesehen das die Beteiligung oft gering ist, am Ende ist es immer die selbe Handvoll Personen.
Und daran sollten wir Arbeiten!

Na ja, weil viele User nicht wissen das sie auch am DEV - Meeting teilnehmen können.

Jey Cee

@sigi234 mir ging es speziell um die Diskussion Außerhalb der Dev Meetings. Da wo sich dann eben auch user beteiligen können.

Übrigens finde ich es ganz gut wenn nicht jeder User in das Dev Meeting kommt. Da geht es ja darum das sich die Entwickler austauschen.

apollon77

Da geht es ja darum das sich die Entwickler austauschen.

Ja das war vllt mal ein Einstiegsgedanke - ich glaube wir sind hier aber schon ein paar Schritte weiter ...

Aber auch Power User sind sehr sinnvoll oder andere die den Entwicklungs- und Testprozess unterstützen wollen. @sigi234 ist einer der immer bei neuen Controller Versionen oder anderen dingen fast der erste ist der testet. @Feuersturm ist beim testing und Issue management vom Admin und anderen Adapters und natürlich macht es großen Sinn das auch solche User mit dabei sind - und jeder der etwas beitragen will oder Informationen bekommen will was so kommt ist aus meiner Sicht immer herzlich eingeladen!

Ich glaube nicht das mehr Zuhörer hier probleme bereiten ... Und ja - die inhaltliche Zielsetzung ändert sich dadurch natürlich nicht. Aber mehr Zuhörer bzw bei Zielgerichteten Themen auch Mitredner aus der Community schadet uns alles nicht.

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.

Nur um das klar zu stellen: Hab ich nicht. Das war zumindest seit ich dabei bin schon immer so und ich habe es akzeptiert. Ich versuche lediglich, Dinge einfacher zu machen und zu zentralisieren:

"neues" Testing ohne Kopie des kompletten Frameworks in jedem Adapter
Einbindung des Controllers mittels adapter-core, anstatt Kopie des "wo ist controller?"-Codes in jedem Adapter
Adapter creator
Release Script
Typdefinitionen, die dich anmeckern falls du die API falsch nutzt

AlCalzone

Schau dir mal den Link hier an https://www.iobroker.net/#de/documentation (welche übrigens von https://iobroker.com/ aus überhaupt nicht verlinkt ist).

Öhh, www.iobroker.net ist die Startseite! Die verlinkt zur Doku:

iobroker.com kannte ich bis heute übrigens gar nicht

Homoran

@alcalzone sagte in Core-Entwicklung zu schnell?:

iobroker.com kannte ich bis heute übrigens gar nicht

Das ist die Seite der GmbH und für kommerzielle Kunden.
Da sollte IMHO auch gar nichts zur Entwicklung zu sehen sein

Homoran

Ich wollte nur auf die Fallen hinweisen, in die Neu-Nutzer reinfallen können.

OK - Das ist sinnvoll.
(es gibt noch einige andere iobroker.xxx)
Ein Hinweis (Link) auf Forum, .net, oder anders herum auf .com auf den diversen Seiten wäre da sicher hilfreich.

Asgothian

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!

Kommunikation geht in beide Richtungen. Ich halte es für falsch zu kritisieren das die Core Entwickler nicht hinreichend kommunizieren. In vielen Bereichen fehlen da auch die Partner mit denen die Kommunikation in Form einer Diskussion wirklich stattfinden kann. Auch kann ich Dir nicht zustimmen das das Forum ein geeigneter Platz für eine Diskussion ist. Das ist es meiner Meinung nach aus verschiedenen Gründen (von denen Du bereits 2 genannt hast) nicht:

Diskussionen bleiben oft nicht Zielgerichtet
Sie werden nicht ordentlich "moderiert" (eine Aufgabe die in diesem Fall nicht die Foren Moderatoren haben sollten, sondern derjenige der die Diskussion angestossen hat)
Es werden selten Ergebnisse, noch seltener Zwischenergebnisse der Diskussion festgehalten
Die Diskussionen laufen zeitlich und inhaltlich auseinander
Das zeitliche auseinanderlaufen führt ggf. dazu das Meinungen nicht artikuliert werden wenn die Diskussion scheinbar schon über den Punkt hinaus gekommen ist.

Letztendlich sehe ich das Dev Meeting als eines der wenigen Events wo wirklich gut "diskutiert" werden kann. Das kostet im Zweifelsfall Zeit, gibt aber in Gegenzug meiner Meinung nach eine bessere Rückkopplung als eine Forumsdiskussion.

Eine Doku ist auch eine Art von Kommunikation - eine die extrem wichtig ist und über die viele Probleme die bei den Adapterenwicklern aktuell vorherrschen eliminiert werden können. Daher halte ich die Fokussierung auf diesen Teil auch nicht für so falsch.

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

Genau das ist ein wunderbares Beispiel. Eine Dokumentation wo diese Funktionalität (ausserhalb des Changelog) beschrieben ist sollte für jeden Entwickler der Anlaufpunkt Nummer 1 sein. Dieser fehlt leider, so das die meisten Entwickler auf Seitenkanäle umschwenken - mal mehr mal weniger erfolgreich.

Am Ende sollte die besagte Doku dann auch eine der Grundlagen sein auf der Diskussionen um Erweiterungen / Änderungen stattfinden - sie definiert einen Wissensstand der von jedem Teilnehmer an der Diskussion vorausgesetzt werden kann - auch ein Detail wessen fehlen sich bei bestehenden Diskussionen durchaus als störend bemerkbar macht.

Um auf das Beispiel der mit den letzten Änderungen aufgekommenen code-seitigen Überprüfung von bereits bestehenden Regeln zurück zu kommen - in einem idealen Projekt wären besagte Regeln bereits seit längerem in der Dokumentation für jeden verfügbar, so das eine Dokumentation darüber bei welcher davon in welcher Form durch den Code eine Einhaltung erzwungen wird deutlich einfacher hätte geschehen können. Dann wäre das Problem mit dem MQTT Adapter ggf. sogar im Vorfeld aufgefallen.

A.

apollon77

Aus einem Post weiter oben hab ich entnommen, das die Dev-Doku von den Entwicklern erstellt wird. Entwickler sind die, die beim Dev-Meeting teilnehmen.
Alle anderen "Entwickler" sind Power-User, alle die nicht entwickeln sind User??

Warum sollten wir hier so ein Korsett an Rollen anlegen? ioBroker ist ein Open Source und Community Projekt. Ja in der Realität gibt es viele User und einige davon machen mehr und sind auch in der Community zB im Forum sichtbarer. Und es gibt User die das System sehr gut kennen bzw auch hier und da ausreizen. Einige davon gelten ohne exakte Definition als "Power User" und ja das ist subjektiv und am Ende in meinen Augen auch egal ... Wer teil der Community ist und sein will und aktiv sein will ist eingeladen bei allem zu unterstützen. Das ist ein Open Source projekt!!
jemand kann gut Dokus schreiben auch für nicht technische Dinge und will helfen ... gern. Jemand hat ein testsystem und kann/will so early tester sein ... welcome. Jemand frickelt sich gern in probleme rein und versucht Isues bei Adaptern nachzustellen um Reporoduction Steps zu liefern? Klar ...

welche übrigens von https://iobroker.com/ aus überhaupt nicht verlinkt ist

Die iobroker.com ist die "iobroker GmbH" und damit der "kommerziellere teil des ganzen. Vielen Dank für Das Feedback das hier ein Link zum Community projekt fehlt. Habe ich weitergegeben.

Jey Cee

@asgothian sagte in Core-Entwicklung zu schnell?:

Kommunikation geht in beide Richtungen. Ich halte es für falsch zu kritisieren das die Core Entwickler nicht hinreichend kommunizieren.

Es mag vielleicht nicht so rüber gekommen sein, aber ich Kritisiere die Kommunikation aller beteiligten. Ebenso die Mangelnde Disziplin.
Das hab ich vor kurzem hier im Forum auch mal ganz Klar so geschrieben bei einem Thema.

UncleSam

@e-s sagte in Core-Entwicklung zu schnell?:

Eine super Idee, leider brauchte ich ewig um diesen Blog zu finden, die Info dazu genauso.

Danke für das Feedback. Der Link zum Blog mit aktuellstem Artikel ist nun auch im Entwickler Portal verfügbar.

Homoran

@asgothian sagte in Core-Entwicklung zu schnell?:

Sie werden nicht ordentlich "moderiert" (eine Aufgabe die in diesem Fall nicht die Foren Moderatoren haben sollten, sondern derjenige der die Diskussion angestossen hat)

und genau deswegen (+die Punkte davor und danach) würde ich jetzt gerne empfehlen die Diskussion hier erst einmal zu beenden.
Nicht weil ich sie abwürgen möchte, dazu ist es viel zu wichtig, sondern damit nach den ersten (und wohl einhellig für alle die gleichen wichtigen) Punkte sinnvoll strukturiert und ein "Plan" für deren Umsetzung erstellt werdn müsste.

Bei der Doku als zentrale Ressource muss ich leider wieder "meckern"