Optimierung Kunden-Feedback - Entwicklung

[ChristophR]

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.

[openWB]

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)?

Man kann nun 2 Punkte auswählen.


Zu 2.
Deine Befürchtung teile ich.

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

Problem ist das sehr oft Dinge in künftigen Versionen eben gefixt sind.
Davon ab bieten wir grundsätzlich Support für ältere Versionen, aber ausschließlich kostenpflichtig (aus obigem Grund).

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

Da sind wir uns bereits ziemlich einig.

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

Das kann und soll durchaus getrennt werden, sowohl in Beschreibung als auch in den Personen.

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

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.

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

Jop.

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

Eher würde das dann ein Punkt in GH Projects sein (Roadmap). Je nach Punkt kann der da ggf. ja durchaus länger draufstehen.

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

Ja, das ist darstellbar.

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

Erstellen kann erstmal jeder GH Nutzer sowohl ein Issue als auch eine Discussion. Moderatoren können dort dann mehr.

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

- Die Community-Moderatoren brauchen daher auch gewisse Rechte in Github.

Das ist kein Problem.

Wie Eingangs erwähnt, 2 Foren halte ich für nicht sinnig, stelle ich aber natürlich gerne zur Diskussion. Weiteres Feedback willkommen

[seaspotter]

Wie Eingangs erwähnt, 2 Foren halte ich für nicht sinnig, stelle ich aber natürlich gerne zur Diskussion. Weiteres Feedback willkommen

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.

[Elchkopp]

Wie Eingangs erwähnt, 2 Foren halte ich für nicht sinnig, stelle ich aber natürlich gerne zur Diskussion. Weiteres Feedback willkommen

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.

….oder postet sogar in beide Foren. Passiert ja selbst in einem Forum, dass derselbe Beitrag mehrfach geschrieben wird.

Stimme Euch daher ebenfalls zu.

[openWB]

Bitte einmal eine PN wer am Meeting heute um 17:30 teilnehmen möchte.

[openWB]

Im Meeting herrschte grundsätzlich Einigung darüber das eine Änderung erforderlich ist und der gemachte Vorschlag Anklang findet.
Detailoptimierungen wurden ebenso schon mit angesprochen.

Künftig wird die Entwicklung nur noch in Github Issues und Pull Requests aktiv sein.
Github Projects wird als Roadmap genutzt.
Stetiges Wissen wandert ins Wiki.

Bei welchem Punkt noch Uneinigkeit bzw. Bedenken herrscht ist Forum vs. GitHub Discussions.

Technisch erfüllt beides seinen Zweck. GitHub Discussions lässt sich nochmal schöner an Isses binden und wer dort gepostet hat, kann auch direkt ein Issue erstellen.
Ein Forum sieht weniger technisch aus und senkt gefühlt die Hürde.

Wir haben beschlossen dies nun nochmal final zur Abstimmung zu stellen, danach geht es an die Umsetzung.
Die Abstimmung ist hier:
viewtopic.php?t=12256

[openWB]

Davon losgelöst, Mitarbeit im Wiki vereinfachen war ebenso ein Punkt.

Hier gibt es die erste Änderung.

Die Registrierung ist nun generell öffentlich:
https://wiki.openwb.de/doku.php?id=start&do=register

Ein kleiner Artikel wie man vorgeht gibt es hier:
https://wiki.openwb.de/doku.php?id=open ... itarbeiten

Edit:
Die Registrierung ist vorübergehend wieder deaktiviert. Viel zu viel Spam.
Da müssen wir nochmal überlegen.
Bis dahin mit usernamen und email per PN melden.

[aiole]

Moin,
wäre es möglich, eine GH-discussions-Struktur zu schaffen, die halbwegs endkundentauglich ist?

Unabhängig von der unbedingten Notwendigkeit, coding, DEV und issues auf GH zu optimieren (Labels usw.), um die Softwarequalität weiter zu steigern, hat das aktuelle Forum mit seinen Supportern für die Endkunden seit 2018 Erhebliches geleistet - ich denke auch sehr stark wegen der niedrigen Einstiegshürde.
Leider werden dort >95% Probleme besprochen, aber das liegt in der Natur der Sache. Dennoch werden diese dort in der Mehrzahl auch gelöst und freut letztlich die Kunden, was das eigentliche Ziel ist.

Wenn es gelingt, dies ähnlich auf GH (mit issue-Verzahnung) einzurichten (Anmeldung/Login sind Standard), ist die Plattform letztlich egal und kann auf GH weitergehen. Dazu aber bitte unbedingt auch auf "normale" Endkunden blicken - es gibt Leute, die schrecken vor dem Wort "discussions" zurück, weil allein das nicht ihre Sprache ist.

Und wenn ich EVCC auf GH sehe, so sind dort deutlich mehr Nerds und DIY-Leute unterwegs als openWB mit seiner Kundschaft bedient. Dazu zählen auch Firmen, denen das letzte Freak-thema völlig egal ist und stattdessen Stabilität und Support brauchen.
Deshalb besseres GH mit unserem DEV-Team und ich hoffe, das es möglich wird -> anwenderfreundliche GH-Diskussionen (statt discussions ) samt Issue-Kopplung.

Schönen Feiertag!

ps
nur eines von vielen Bsp., worüber viele happy sind - schnelle Hilfe Dank simpler Fragestellung. Ich hoffe, das geht auf GH genauso.
viewtopic.php?p=143446#p143446

[openWB]

wäre es möglich, eine GH-discussions-Struktur zu schaffen, die halbwegs endkundentauglich ist?

Das habe ich schonmal angestoßen:
viewtopic.php?t=12258

Unabhängig von der unbedingten Notwendigkeit, coding, DEV und issues auf GH zu optimieren (Labels usw.), um die Softwarequalität weiter zu steigern, hat das aktuelle Forum mit seinen Supportern für die Endkunden seit 2018 Erhebliches geleistet - ich denke auch sehr stark wegen der niedrigen Einstiegshürde.
Leider werden dort >95% Probleme besprochen, aber das liegt in der Natur der Sache. Dennoch werden diese dort in der Mehrzahl auch gelöst und freut letztlich die Kunden, was das eigentliche Ziel ist.

Das soll natürlich auch künftig so bleiben. Der Ort wird sich gemäß der Abstimmung nur ändern.

[Ihaglc]

Gibt es denn schon einen Plan/Vorstellung, was mit den bisher erstellten Daten in phpBB passieren soll?

Werden diese in Github Discussions / Discourse dann übernommen?
Oder haben wir dann 2 temp. Diskussionsforen?

Das würde ich dann nicht haben wollen.