Core-Entwicklung zu schnell?
-
Ich sehe mich auch als beta tester und ich lese sehr viel, besonders ist es derzeit wirklich wichtig im discord channel zu lauschen. Oder auch mal ein thread im forum zu lesen der nicht unbedingt auf den ersten blick mit den eigenen Interessen konfirm zu sein scheint.
Und dabei fällt es eben auf, alle meckern über Kommunikation aber kaum einer schafft es einen Beitrag über seinem eigenen zu lesen. Sicherlich hat man nicht immer die Zeit alles zu lesen und wenn man dies zu sehr macht, dann kann einen das alles auch krank machen.
Also sehe ich es auch so, daß dies zentraler gemacht werden muss. Wichtig für mich sind immer die Infos aus den dev treffen. Super, diese werden jetzt auch im Blog veröffentlicht. Eine super Idee, leider brauchte ich ewig um diesen Blog zu finden, die Info dazu genauso.
Das ist auch wieder ein Beispiel dafür.Bei mir liegt es klar daran das ich nur mobil im forum und discord unterwegs bin, nie aber auf die iobroker Homepage gehe. Es gibt doch genug Möglichkeiten durch Ankündigung usw diese auch dort sinnvoll zu platzieren.
@mickym
Sorry, ohne dir jetzt zu nahe zu treten, aber bei dir lese ich immer nur, früher war alles besser. Dann lass dein System eingefroren und sei glücklich.
Mqtt ist ein uraltes System und ist meines Erachtens sowieso schon nicht mehr wirklich sinnvoll. Ich habe meine esps alle mqtt befreit und auf native api umgestellt.
Und wenn es jetzt ein bisschen wie Äpfel mit birnen vergleichen ist. Wenn dein Chef, deine Frau oder die Politik eine neue Regelung herausgibt, gehst du dann auch sofort auf Konfrontation und sagst: nööö, das habe ich schon immer so gemacht.
Egal ob es vorher falsch war, nur eben nicht reguliert?Ich habe mich immer aufgeregt weil meine Geräte nicht als Geräte erkannt werden. Nachdem ich mich mit dem Thema Rollen usw beschäftigt habe, weiß ich erst wie schwierig dies ist.
Nun muss ich alle Fehler beseitigen, die in den Adaptern sind und verlinke alle states auf die richtige rolle, Funktion, Einheit usw. mit linkeddevice und alias.
Dies ist sehr aufwendig und nervt mich auch, aber ich möchte gerne ein sauberes System haben was später überall schnell kompatibel ist.Und das ist eben manchmal eben auch Aufgabe des users selbst. Sicherlich könnte ich auch weiter die devs nerven, aber man merkt aus so das viele auf der kippe sind aufzugeben. Deswegen spare ich mir dies, obwohl es nicht wirklich zielführend für alle ist.
Ich glaube viele haben auch nicht mitbekommen, daß einige Adapter auch schnell und unkompliziert "gerettet" wurden. Gerade zum neuen js Controller gab es einige Adapter die nicht mehr gingen. Schnell wurden diese zum Community Adapter und ein oder mehrere devs versuchten diesen wieder zum laufen zu bringen.
Also so schnell stirbt kein Adapter, weil es eben ein wir gibt. Wer Probleme hat, sollte sich nur in der richtigen Form daran wenden.Eine Sache die mich dahingehend selbst stört, viele schwierige Fragen werden schlecht oder gar nicht beantwortet und andere zum 3000. Mal.
Aber dies ist leider ein Problem was gefühlt überall so ist und es keine Lösung für gibt.
Da diejenigen die diese beantworten könnten blockiert sind mit Spam der leseunwilligen.
Sorry, der Satz ist jetzt hart und wird einige aufstoßen lassen, aber es ist so. Und leider hilft auch da die beste Doku nichts. -
@e-s
ich würde gerne auch noch einmal etwas (mehr) dazu aus meiner Sicht schreiben.Hier sind zwei (für mich) sehr wichtige Informationen.
Zum einen die Anfrage von @mickym zu MQTT.
(speziell gehört das in einen eigenen Thread, aber) Allgemein möchte ich dazu, und zu der AussageEtwas was bisher lief später verbieten geht nicht.
(Sinngemäß - ich find es gerade nicht mehr)Auch bei den Adaptern läuft manchmal etwas "plötzlich" nicht mehr, weil der Hersteller etwas geändert hat.
z.B. der Harmony-Adapter. Dort (und eben auch bei anderen Adaptern) wurden undokumentierte Funktionen verwendet, die anschließend wegen möglicher Sicherheitslücken geschlossen wurden.
Einige Adapter funktionieren (aus meiner nicht Dev-Sicht) nur weil da etwas "gehackt" wurde.
Wenn dann so "eine Lücke" geschlossen wird -warum auch immer- klappt das bisherige Vorgehen nicht mehr.und genau so ist es mit ioBroker.
Ich schätze das Wissen und die Meinung von @mickym zu node-red sehr und MQTT ist wirklich ein Sonderfall.
Es ist ein altes Protokoll aber in meinen Augen lange noch nicht veraltet und kommt auch noch außer bei den ESP sehr häufig vor.
Aber auch wenn es unbequem ist, sollte eine Lösung möglich sein. Die allerdings ggf. anders aussieht als das bisher genutzte.Ähnliches gilt für die Strukturierung der Objekte.
Auch das ergibt in meinen Augen einen Sinn und beschert uns im Moment Mehrarbeit.
(Auch ich nutze noch Verzeichnisse aus der Vor-0_Userdata-Zeit, zum Glück alles einzeln manuell erzeugt und daher mit Objekten)
der zweite Punkt ist:
@e-s sagte in Core-Entwicklung zu schnell?:
Viele schwierige Fragen werden schlecht oder gar nicht beantwortet und andere zum 3000. Mal.
diesen Schuh ziehe ich mir mal an.
Mir geht es wie ein Mix aus @Thomas-Braun und @Eisbaeeer.
Ich habe früher die (User-) Dokus in Form des Github Wikis, und der ersten und dritten Wordpress Version nahezu allein geschrieben, auch die aktuelle Doku hatte ich mit viel Elan begonnen.
Vorher hatte ich keinerlei Berührungspunkte mit GitHub oder Wordpress.
Ich habe mich da jeweils eingearbeitet und dann Schritt für Schritt das Können und Wissen ausgebaut.
Das jetzige Framework ist jedoch für mich zu komplex. die Struktur hat eine hervorragende Idee, weil damit die automatisierte Erstellung in mehreren Sprachen ermöglicht wird.
Leider muss ich mich da jedesmal wieder neu einarbeiten wenn ich da nicht nahezu täglich mit arbeite.
Da schreibe ich lieber den selben Text mehrfach im Forum. (Wobei das Forum für mich die wichtigste Quelle für Informationen ist, was in der Doku für Einsteiger nicht passt)
Auch hier muss ich leider feststellen, dass die heutige automatisierte Doku wieder an einigen Stellen Gefahr läuft für Einsteiger unverständlich zu werden. Zu allem Überfluss wurden auch noch Artikel von mir anscheinend mit automatisierten (technischen) Beschreibungen ersetzt.Allerdings kann und will ich im Forum auch nur die Fragen beantworten, bei denen ich wirklich weiß was ich schreibe. Und das ist zwar einiges, aber da ich kein Entwickler bin und auch nicht alle Systeme besitze, halt nicht alles.
Manchmal versuche ich noch die Fragen etwas einzugrenzen um anderen Helfenden alle notwendigen Informationen zu verschaffen.
Aber dadurch werden einige Frage halt 3000 mal und ander gar nicht beantwortet
-
Was ich mir wünschen würde ist ein zentrales Eingangsdokument für meine Entwicklerfragen. Da muss am Anfang gar nicht soviel drinnstehen. Wichtig wäre nur, dass die Infos aktuell sind. Das können auch Links ins Forum, Github oder npm sein. Die Form wäre mir da gar nicht so wichtig, nur aktuell sollten die Infos halt möglichst sein. Was meine ich z.B.: wenn ein Dev mit einem Adapter startet, dann schau Dir ioBroker.example an, dann verwende für das Grundgerüst möglichst immer ioBroker.create-adapter. Wenn Du tiefer einsteigen willst, dann schau Dir iobroker.adapter-react an. So in der Art und das für möglichst viele dev-Themen fände ich super.
-
@carsten04 sagte in Core-Entwicklung zu schnell?:
Was ich mir wünschen würde ist ein zentrales Eingangsdokument für meine Entwicklerfragen.
Unser Ziel ist es, dass iobroker.dev genau dieser Einstiegspunkt wird. Wenn euch etwas fehlt, dann bitte Issue erfassen.
Die Entwickler-Doku wird im Verlauf des nächsten Jahres als GitHub Pages neu aufgebaut: https://iobroker.github.io/dev-docs/. Und auch hier: bitte Issue erfassen, wenn ihr Ideen habt.
Und ich bin jetzt mal so frech: wer an diesen Orten (und allen anderen "globalen" Repos) keine Issues erfasst und nicht in den Entwickler-Meetings und/oder auf Discord/Telegram im Entwickler-Chat mitredet, soll sich hier bitte zurückhalten mit Kritik(*). Wir haben Kanäle, wo man Fragen stellen kann und Kritik anbringen kann, die müssen aber auch genutzt werden!
@apollon77 und alle anderen, die sich angesprochen fühlen: sorry wenn ich immer negativ schreibe, das positive geht so schnell vergessen! Ich glaube mit (guter, konstruktiver) Kritik können wir wachsen. Und ja: es ist sehr erfreulich, zu sehen wie viele Fortschritte wir in den letzen Jahren gemacht haben, weiter so!
(*) Damit meine ich Entwickler. Das Feedback der anderen Power-User hier ist natürlich sehr willkommen, eure Stimmen sind genauso wichtig, auch wenn ihr nicht (aktiv) auf unseren anderen Kanälen unterwegs seid.
-
@homoran
Ich war früher mal in einigen Enigma2 Foren sehr aktiv, teils als mod, habe auch sehr viele Dokus erstellt. Gelesen wurden diese nur von wenigen.
Das war früher so und wird auch immer so bleiben. So sind die User eben. Kommen nur dann aus den löchern wenn es Probleme gibt, wollen dann sofort die Lösung auf dem silbertablett und lesen selbst die Antworten nicht welche auf ihre eigenen Fragen kamen.
Das kann man dann auch nicht verbessern, zumindest wüsste ich nicht wie.Das einzige was vielleicht sinnvoll wäre, das Leute wie @apollon77 sich mit den kleineren Problemen zurückhalten und dies eben den aktiven aber nicht allwissenden beantworten lassen. Um eben mehr Zeit für komplizierte Probleme zu haben.
Also so nach dem Motto, first Level Support für die aktiven User, 2. Level dann für Profis oder so.
Wie oben schon geschrieben, ist auch für mich das forum die erste Anlaufstelle, dort müsste alles sinnvoll und einfach verlinkt sein.
Die iobroker Seite selbst schaut man sich glaube ich nur einmal am anfang an, danach nie wieder. Deswegen würde man auch nichts mitbekommen wenn es neue Sachen gibt und dies dort publiziert wird. -
@e-s sagte in Core-Entwicklung zu schnell?:
Wie oben schon geschrieben, ist auch für mich das forum die erste Anlaufstelle, dort müsste alles sinnvoll und einfach verlinkt sein.
richtig! und dafür braucht es aber eine (vollständige und verständliche) Doku, damit man was zum Verlinken hat
-
@skokarl Wie meine Vor-Antworter bereits gesagt haben ist das kein "riesen Issue" aktuell, dennoch müssen wir es als Open-Source-Projekt schaffen auch solche Themen offen und transparent zu diskutieren.
Im Gegensatz zu den anderen Systemen ist bei ioBroker alles weniger zentral gesteuert, was aber andere Herausforderungen mit sich bringt. Aber mit anderen Ansätzen kommen auch wieder andere Challenges ...
-
@homoran sagte in Core-Entwicklung zu schnell?:
Es ist ein altes Protokoll aber in meinen Augen lange noch nicht veraltet und kommt auch noch außer bei den ESP sehr häufig vor.
MQTT ist DAS iot Protokoll und wird es auch bleiben. Es ist zum Defaktor Standard geworden ... von daher ist das Thema speziell, aber relevant ... Aber ja ein anderer Thread
-
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.
-
@jey-cee sagte in Core-Entwicklung zu schnell?:
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.
-
@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.
-
@jey-cee sagte in Core-Entwicklung zu schnell?:
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.
-
@jey-cee sagte in Core-Entwicklung zu schnell?:
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
-
@oliverio sagte in Core-Entwicklung zu schnell?:
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
-
@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 -
@oliverio sagte in Core-Entwicklung zu schnell?:
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. -
@jey-cee sagte in Core-Entwicklung zu schnell?:
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.
@jey-cee sagte in Core-Entwicklung zu schnell?:
@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.
-
@oliverio sagte in Core-Entwicklung zu schnell?:
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 ...@oliverio sagte in Core-Entwicklung zu schnell?:
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.
-
@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. -
@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.
