Ein paar Hinweise von mir:
1. Umfrage:
Das sind ja eigentlich 2 Umfragen, die man nicht gleichzeitig beide beantworten kann. Wenn man mitteilt, ob einem der Termin passt, kann man gar nicht mehr beantworten, ob man Änderungen wünscht oder nicht. (Vielleicht heißt das aber auch automatisch, dass man sich Änderungen wünscht, sonst würde man ja nicht am Termin teilnehmen wollen)?
2. Grundsatzfrage Forum vs. Github:
Als ich mit openWB angefangen habe, hatte ich noch nichts mit Github zu tun.
Das war für mich ein Tool für Programmierer, es ist ja auch sehr stark darauf ausgerichtet, die Weiterentwicklung des Codes zu unterstützen.
Zu dem Zeitpunkt hätte mich das Nichtvorhandensein eines Forums schon davon abgebracht, wäre nie auf die Idee gekommen dort meine ersten Fragen zu stellen (selbst wenn es Disscussions gegeben hätte).
Das Forum sollte daher nach meiner Meinung unbedingt bestehen bleiben und sollte nicht vollständig in Github überführt werden.
Die Umstellung auf eine andere Forumsplattform kann gerne erfolgen, spätestens seit ich versucht hatte, hier eine Tabelle in einem Beitrag zu erstellen, spricht viel dafür. In Github geht das übrigens einfach aus Excel mit Copy-Paste, wenn das die neue Forumssoftware dann auch kann, wäre das ganz nett. (Aber hier etwas OT)
3. Entlastung des Developments:
Dass das Development entlastet werden soll, ihre kostbare Zeit nicht mit durchwühlen der Forumsbeiträge zu vergeuden, kann ich grundsätzlich verstehen.
Dafür wäre nach meinem Verständnis aber mehr nötig:
- Der Support unterstützt momentan offiziell keine Problemen mit Nicht-Release Versionen. Das müsste abgeschafft werden, sonst wird sich die Entlastung wohl nicht einstellen.
- Dann sollte eine harte Trennung eingeführt werden, damit das Development gar nicht mehr im Forum unterstützt. Eine (pflaumweiche) Regelung wie jetzt, nur im Feedbackthread ist nicht logisch und im echten Leben auch nicht konsequent einzuhalten.
- Eine Unterscheidung von Development (echte Umsetzung im Code) und der Produktentwicklung (woran soll gearbeitet werden und wie soll es genau umgesetzt werden). Mein deutsches Wort "Entwicklung" umfasst irgendwie beides, daher muss man das mal klar trennen. Hier sind die gleichen Personen z.T. in beide Aufgaben involviert, daher ist diese Trennung nicht an Personen, sondern an Themen festzumachen.
- Development-Themen werden nicht im Forum, sondern nur in Github behandelt. Hierfür halte ich es schon für sinnvoll, discussions in Github einzuführen. Der Workflow wäre dann, die Details einer Umsetzung mit dem Development in discussions zu diskutieren, die Umsetzung erfolgt dann in PRs und wenn es Fehler oder Fehlverhalten gibt, gehören sie in die Issues, die dann wieder durch PRs gelöst werden können. Hieraus kann man schon erkennen, dass ich die Erwartungshaltung habe, dass das Development in discussions "mitspielt", hier aber nur Diskussionen zugelassen werden, die auch wirklich mit dem Development geführt werden müssen.
- Im Forum wird im Feedbackthread nur noch über Meinungen und Wünsche zu den Umsetzungen der entsprechenden Version diskutiert. Sobald es sich um einen Fehler handelt, wird dieser in Github Issues überführt. Um dies nicht jedem User zuzumuten, könnte die Überführung der qualifizierten Meldung eines "Nicht-Github-Users" im Forum durch einen Moderator erfolgen, der dann das Issue quasi im Auftrag des Users erstellt und in seinem Beitrag verlinkt. Wenn der User dann dort weitere Rückmeldung zu geben möchte, wird er damit automatisch langsam an die Arbeitsweise in Github herangeführt.
- Im Forum erfolgt, wie bisher auch der Community-Support, der unter bestimmten Voraussetzungen dann an den Support verweist, wenn dies möglich/nötig ist.
- Im Forum wird auch über Feature Request diskutiert. Hierfür muss sich zwingend die Produktentwicklung an dieser Diskussion beteiligen, damit klar wird, ob es sich überhaupt um einen realistischen Feature Request handelt, in den es sich lohnt, weitere Energie zu stecken. Wenn er dort ausdiskutiert wurde, wird er in eine discussion in Github überführt, wo dann ggf. die technischen Details der Umsetzung mit dem Development besprochen werden können, mit der Umsetzung als PR wird diese dann dort geschlossen, so dass Github stets aufgeräumt bleibt (In der idealen Welt wenigstens).
- Github Power-User können Fehler und Fehlverhalten direkt als issues melden. Cool wäre ja, wenn man dabei die betroffene Version auswählen könnte, da sie in Github ja irgendwie bekannt sein müsste? Die Community-Moderatoren schließen dann aber direkte Meldungen, in denen Logs fehlen oder die doppelt sind, damit sich damit nicht das Development rumschlagen muss.
- Die discussions in Github sollten in meiner Welt aber nicht dort von Github Power-Usern angelegt werden, wenn sie nicht vorher im Forum diskutiert wurden, da sonst das Development ggf. wieder einen Mehraufwand erbt. Die (Community-)Moderatoren müssten in solchen Fällen also ggf. auch mal eine discussion ins Forum verschieben und diese in Github dann mit Verweis auf die nötige, vorgelagerte Diskussion im Forum schließen können.
- Es beginnen daher viele Github Beiträge mit einem Link auf den zugehörigen Forums-Beitrag, einige Forums-Beiträge auch mit einem Verweis auf einen Github-Eintrag. Wenn in discussions oben eine Info oben stehen würde, dass diese zuerst im Forum besprochen werden sollen und in issues, dass stets Logfiles und Details zur Umgebung angegeben werden sollen, wäre das sehr hilfreich.
- Die Community-Moderatoren brauchen daher auch gewisse Rechte in Github.
Ich bedauere, dass ich vermutlich nicht die Zeit finden werde, als Community-Moderator mitzuwirken, da ich bereits jetzt viel Freizeit hier im Forum verbringe und arbeitstechnisch sehr ausgelastet bin.
Optimierung Kunden-Feedback - Entwicklung
-
ChristophR
- Beiträge: 1685
- Registriert: So Okt 30, 2022 8:07 am
- Has thanked: 133 times
- Been thanked: 201 times
Re: Optimierung Kunden-Feedback - Entwicklung
openWB Series 2 Standard+, SW-Version 2
SolarEdge SE10K-RWS, BYD LVS 8, 16,8 kWp.
CUPRA Born
SolarEdge SE10K-RWS, BYD LVS 8, 16,8 kWp.
CUPRA Born
-
openWB
- Site Admin
- Beiträge: 10323
- Registriert: So Okt 07, 2018 1:50 pm
- Has thanked: 188 times
- Been thanked: 431 times
Re: Optimierung Kunden-Feedback - Entwicklung
Man kann nun 2 Punkte auswählen.1. Umfrage:
Das sind ja eigentlich 2 Umfragen, die man nicht gleichzeitig beide beantworten kann. Wenn man mitteilt, ob einem der Termin passt, kann man gar nicht mehr beantworten, ob man Änderungen wünscht oder nicht. (Vielleicht heißt das aber auch automatisch, dass man sich Änderungen wünscht, sonst würde man ja nicht am Termin teilnehmen wollen)?
Zu 2.
Deine Befürchtung teile ich.
Problem ist das sehr oft Dinge in künftigen Versionen eben gefixt sind.- Der Support unterstützt momentan offiziell keine Problemen mit Nicht-Release Versionen. Das müsste abgeschafft werden, sonst wird sich die Entlastung wohl nicht einstellen.
Davon ab bieten wir grundsätzlich Support für ältere Versionen, aber ausschließlich kostenpflichtig (aus obigem Grund).
Da sind wir uns bereits ziemlich einig.- Dann sollte eine harte Trennung eingeführt werden, damit das Development gar nicht mehr im Forum unterstützt. Eine (pflaumweiche) Regelung wie jetzt, nur im Feedbackthread ist nicht logisch und im echten Leben auch nicht konsequent einzuhalten.
Das kann und soll durchaus getrennt werden, sowohl in Beschreibung als auch in den Personen.- Eine Unterscheidung von Development (echte Umsetzung im Code) und der Produktentwicklung (woran soll gearbeitet werden und wie soll es genau umgesetzt werden). Mein deutsches Wort "Entwicklung" umfasst irgendwie beides, daher muss man das mal klar trennen. Hier sind die gleichen Personen z.T. in beide Aufgaben involviert, daher ist diese Trennung nicht an Personen, sondern an Themen festzumachen.
2 Stellen, also ein Forum und Discussions halte ich für schwierig. Wenn es ein separates Forum geben soll ist das Community only. Wenn es Rückfragen bei Problemen gibt würden die direkt im Issue behandelt werden.- Development-Themen werden nicht im Forum, sondern nur in Github behandelt. Hierfür halte ich es schon für sinnvoll, discussions in Github einzuführen. Der Workflow wäre dann, die Details einer Umsetzung mit dem Development in discussions zu diskutieren, die Umsetzung erfolgt dann in PRs und wenn es Fehler oder Fehlverhalten gibt, gehören sie in die Issues, die dann wieder durch PRs gelöst werden können. Hieraus kann man schon erkennen, dass ich die Erwartungshaltung habe, dass das Development in discussions "mitspielt", hier aber nur Diskussionen zugelassen werden, die auch wirklich mit dem Development geführt werden müssen.
Jop.- Im Forum wird im Feedbackthread nur noch über Meinungen und Wünsche zu den Umsetzungen der entsprechenden Version diskutiert. Sobald es sich um einen Fehler handelt, wird dieser in Github Issues überführt. Um dies nicht jedem User zuzumuten, könnte die Überführung der qualifizierten Meldung eines "Nicht-Github-Users" im Forum durch einen Moderator erfolgen, der dann das Issue quasi im Auftrag des Users erstellt und in seinem Beitrag verlinkt. Wenn der User dann dort weitere Rückmeldung zu geben möchte, wird er damit automatisch langsam an die Arbeitsweise in Github herangeführt.
- Im Forum erfolgt, wie bisher auch der Community-Support, der unter bestimmten Voraussetzungen dann an den Support verweist, wenn dies möglich/nötig ist.
Eher würde das dann ein Punkt in GH Projects sein (Roadmap). Je nach Punkt kann der da ggf. ja durchaus länger draufstehen.- Im Forum wird auch über Feature Request diskutiert. Hierfür muss sich zwingend die Produktentwicklung an dieser Diskussion beteiligen, damit klar wird, ob es sich überhaupt um einen realistischen Feature Request handelt, in den es sich lohnt, weitere Energie zu stecken. Wenn er dort ausdiskutiert wurde, wird er in eine discussion in Github überführt, wo dann ggf. die technischen Details der Umsetzung mit dem Development besprochen werden können, mit der Umsetzung als PR wird diese dann dort geschlossen, so dass Github stets aufgeräumt bleibt (In der idealen Welt wenigstens).
Ja, das ist darstellbar.- Github Power-User können Fehler und Fehlverhalten direkt als issues melden. Cool wäre ja, wenn man dabei die betroffene Version auswählen könnte, da sie in Github ja irgendwie bekannt sein müsste? Die Community-Moderatoren schließen dann aber direkte Meldungen, in denen Logs fehlen oder die doppelt sind, damit sich damit nicht das Development rumschlagen muss.
Erstellen kann erstmal jeder GH Nutzer sowohl ein Issue als auch eine Discussion. Moderatoren können dort dann mehr.- Die discussions in Github sollten in meiner Welt aber nicht dort von Github Power-Usern angelegt werden, wenn sie nicht vorher im Forum diskutiert wurden, da sonst das Development ggf. wieder einen Mehraufwand erbt. Die (Community-)Moderatoren müssten in solchen Fällen also ggf. auch mal eine discussion ins Forum verschieben und diese in Github dann mit Verweis auf die nötige, vorgelagerte Diskussion im Forum schließen können.
Das halte ich für nicht zielführend und aufwendig sauber nachzuhalten. Auch schließt du dann Forenschreiber aus wenn etwas nach GH rüber wandert.- Es beginnen daher viele Github Beiträge mit einem Link auf den zugehörigen Forums-Beitrag, einige Forums-Beiträge auch mit einem Verweis auf einen Github-Eintrag. Wenn in discussions oben eine Info oben stehen würde, dass diese zuerst im Forum besprochen werden sollen und in issues, dass stets Logfiles und Details zur Umgebung angegeben werden sollen, wäre das sehr hilfreich.
Das ist kein Problem.- Die Community-Moderatoren brauchen daher auch gewisse Rechte in Github.
Wie Eingangs erwähnt, 2 Foren halte ich für nicht sinnig, stelle ich aber natürlich gerne zur Diskussion. Weiteres Feedback willkommen
Supportanfragen bitte NICHT per PN stellen.
Hardwareprobleme bitte über die Funktion Debug Daten senden mitteilen oder per Mail an support@openwb.de
Hardwareprobleme bitte über die Funktion Debug Daten senden mitteilen oder per Mail an support@openwb.de
-
seaspotter
- Beiträge: 779
- Registriert: Do Mär 03, 2022 8:09 pm
- Has thanked: 187 times
- Been thanked: 162 times
Re: Optimierung Kunden-Feedback - Entwicklung
Stimme ich absolut zu, das ist absolut nicht sinnvoll, "niemand" weiß so recht wo es nun hingehört und bringt nur mehr Verwirrung und Supportaufwand.openWB hat geschrieben: Fr Mai 08, 2026 5:06 am Wie Eingangs erwähnt, 2 Foren halte ich für nicht sinnig, stelle ich aber natürlich gerne zur Diskussion. Weiteres Feedback willkommen
15,36 kWp mit Sungrow SH10RT V112 (via LAN), 12,8 kWh Sungrow SBR128 und SMA STP6.0-3AV-40
2x OpenWB Series2 custom – 11 kW und 22kW
IDM Aero SLM Wärmepumpe
Renault Megane E-Tech EV60 - VW ID3 Pro S
2x OpenWB Series2 custom – 11 kW und 22kW
IDM Aero SLM Wärmepumpe
Renault Megane E-Tech EV60 - VW ID3 Pro S
-
Elchkopp
- Beiträge: 922
- Registriert: Fr Feb 04, 2022 6:19 pm
- Has thanked: 26 times
- Been thanked: 83 times
Re: Optimierung Kunden-Feedback - Entwicklung
….oder postet sogar in beide Foren. Passiert ja selbst in einem Forum, dass derselbe Beitrag mehrfach geschrieben wird.seaspotter hat geschrieben: Fr Mai 08, 2026 5:09 amStimme ich absolut zu, das ist absolut nicht sinnvoll, "niemand" weiß so recht wo es nun hingehört und bringt nur mehr Verwirrung und Supportaufwand.openWB hat geschrieben: Fr Mai 08, 2026 5:06 am Wie Eingangs erwähnt, 2 Foren halte ich für nicht sinnig, stelle ich aber natürlich gerne zur Diskussion. Weiteres Feedback willkommen
Stimme Euch daher ebenfalls zu.