Re: Optimierung Kunden-Feedback - Entwicklung
Verfasst: Do Mai 07, 2026 11:05 pm
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.
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.