Bug Tracking und transparenter Entwicklungsprozess
-
Habe gerade erst dieser Tage dem Support das gleiche vorgeschlagen.
Ich denke, es braucht kein Jira oder Git dafür. Eine neue Kategorie in diesem Forum würde meines Erachtens völlig genügen. Das würde es uns allen erlauben, bereits bekannte Probleme nicht doppelt und dreifach zu berichten (eine Repro ist ja manchmal auch nicht ganz einfach zu erstellen). Und eine Bestätigung für einen Bug Report durch einen oder mehrere andere Benutzer wäre ja evtl. durchaus auch für CT interessant.
-
@thommyb sagte in Bug Tracking und transparenter Entwicklungsprozess:
Eine neue Kategorie in diesem Forum
Wie gesagt, die gab es über 10 Jahre und hat sich wohl nicht bewährt.
-
@thommyb sagte in Bug Tracking und transparenter Entwicklungsprozess:
Ich denke, es braucht kein Jira oder Git dafür. Eine neue Kategorie in diesem Forum würde meines Erachtens völlig genügen.
Eine Jira-Instanz (oder GitHub Issues oder sonst etwas vergleichbares) aufsetzen ist ja schätzungsweise auch kein großes Ding. Wenn man bedenkt, wie groß ChurchTools mittlerweile ist, finde ich es eher verwunderlich, dass es keinen öffentlichen Bugtracker gibt. Der Vorteil eines solchen Systems ist, dass man Tickets komfortabel bewerten, schätzen, gewichten, priorisieren und Releases zuordnen kann, bei voller Transparenz für die Anwender, die zudem wertvolle fehlende Informationen beisteuern können.
Ich bin mir sicher, dass die Fehler, die ich melden will, schon von mindestens 20 Anwendern vor mir bemerkt worden sind. Mache ich mir jetzt die Arbeit, den Fehler erneut detailliert zu dokumentieren und per Mail dem Support zu berichten? Um dann mit 95%iger Wahrscheinlichkeit die Antwort zu bekommen: "Ist schon bekannt!"... da fehlt mir ein wenig die Motivation, weil ich denke, dass es überflüssige Arbeit ist. Ich würde also erstmal per Mail anfragen, ob das Problem schon dokumentiert ist, ob es Workarounds gibt, ob es von der Andoid-Version abhängen kann, wann es beseitigt wird, und so weiter.
Das macht allen Beteiligten Mehrarbeit: den Anwendern, aber auch dem Support, denn die bekommen alles 10mal erzählt und müssen das dann alles selber verdichten und danach die (ungeduldigen? ;-)) Anfragen vieler Anwender einzeln beantworten. Aber was schreibe ich so viel - ich brauche ja eigentlich nicht Sinn und Zweck eines Bugtrackers zu erklären
Natürlich kann man so etwas auch in einem Forum irgendwie abbilden. Aber warum das dritt- oder viertbeste Werkzeug nutzen, wenn man auch das beste einsetzen kann? Wenn das mit dem Forum nicht so richtig funktioniert hat, dann wundert mich das nicht besonders. In einem Forum kann man texten und voten, aber mehr halt nicht.
-
@schwest sagte in Bug Tracking und transparenter Entwicklungsprozess:
Eine Jira-Instanz (oder GitHub Issues oder sonst etwas vergleichbares) aufsetzen ist ja schätzungsweise auch kein großes Ding.
Zum einen sprichst du mir aus der Seele ... Aber:
- Wir dürfen hier nicht bei der Lösung beginnen, sondern sollte das Problem anschauen.
- In den Feature-Wünschen gibt es Lösungsvorschläge, manche sind so, dass man aus dem Lösungsvorschlag das Problem extrahieren muss. Viele behandeln ein Partikularproblem, dessen Lösung man erst in Strategien und Konzepte gießen muss, wenn man CT nicht ins Chaos treiben will.
- in den Feature-Wünschen gibt es auch viele Doubletten, die es nicht gäbe, wenn man vorher sucht und verwandte Themen durch weiteres Kommentieren und Voten wieder hervorbringt.
Ein Ticket-System bringt gegenüber dem Forum in der Tat den Mehrwert von Management und Tracking Features. Solche Ticket-Systeme funktionieren dann gut, wenn alle Beteiligten ein Grundverständnis von Entwicklungsprozessen haben. Wenn das Grundverständnis nicht da ist, verpufft auch ein Ticket-System. Leider ist das - mit Verlaub gesagt - nicht durchgängig der Fall (man sieht das dann an Worten wie "ich bin ja nur ein dummer Anwender ... "
Würde mich echt interessieren wer von uns CT-Anwendern ein Gemeindeinternes Helpdesk oder Ticket-System betreibt ...Ich habe schon Verständnis dafür, dass CTI nicht alle ihre Planungen offen legt. Ich gehe aber davon aus, dass sie schon einen definierten Entwicklungsprozess haben (das Wort Sprint kommt da öfter mal vor :-).
M.E. sollte man zunächst einen Prozess definieren, wie aus der Userschaft Anforderungen formuliert, bewertet, abgestimmt (das voten halte ich nicht für wirklich zielführend) und dann qualifiziert eingespeist werden können.
Was hab ich da mal gelesen? "sch***" Prozess digitalisiert, hat man einen "digitalisierten sch*** Prozess)
so weit mal, ist eh schon zu lang
-
@bwl21 Zunächst einmal geht es darum, eine zusätzliche Ecke für Fehlerberichte zu haben. Das ist ja nochmal was anderes als Feature Wünsche oder auch allgemeine "Wie mach ich das"-Fragen. Für diese beiden gibt es bereits eine Kategorie in diesem Forum. Ob man Features und Bugs noch bzw. stattdessen woanders tracken sollte, ist meines Erachtens eine ganz andere und davon losgelöste Frage.
-
@bwl21 sagte in Bug Tracking und transparenter Entwicklungsprozess:
Ich habe schon Verständnis dafür, dass CTI nicht alle ihre Planungen offen legt. Ich gehe aber davon aus, dass sie schon einen definierten Entwicklungsprozess haben (...)
Ja, ich möchte auch gar nicht an den Prozessen rumzerren - denn die existieren ja mit Sicherheit.
Es ist mehr das Thema "Transparenz". Ich gehe mit 95%iger Sicherheit davon aus, dass es einen Bugtracker gibt für CT und die CT-App (ganz einfach weil es im Grunde fast nicht sein kann, dass ein SW-Projekt dieser Größe ohne ein solches Tool gewartet und weiterentwickelt wird). Aber eben anscheinend nur intern, in den Support- und Entwicklerteams. Was spräche dagegen, die Einträge öffentlich zu machen, als Listing mit der Überschrift "Bekannte Probleme"? Als Anwender könnte man dann da reinschauen und sehen, ob das eigene Problem dort schon gelistet und ausreichend beschrieben ist. Und wenn es auch keine interaktive Lösung sein sollte, weil viele Anwender nicht softwareentwicklungsaffin sind - man könnte dann zusätzliche Infos ja immer noch per Mail senden. Aber halt nur zusätzliche, nicht die komplette Fehlerbeschreibung immer und immer wieder.
Aber was tippen wir hier so viel: das sind ja alles nur Mutmaßungen... meine Hoffnung war, dass jemand, der selber in einem dieser Teams mitarbeitet, kurz Auskunft geben kann. Meine Frage war schon primär an die CT-Developer, -Product Owner oder wen es da sonst noch geben mag gerichtet. Vielleicht meldet sich ja noch jemand
-
@thommyb @schwest Wenn ich einen Fehler finde, dann dokumentiere ich ein bisschen und schicke die E-Mail ab, also nicht nur "so ein Mist" und auch keine lange Abhandlung.
In gefühlt 8 von 10 Fällen bin ich der erste, der den Fehler meldet und es kommt noch eine kluge Verständnisfrage - ansonsten halt "ist bekannt, wird gelöst, bitte Geduld".@andy
Leider muss ich selber tracken, was noch offen ist, da wäre es nett, wenn jede neue Anfrage eine Inzidenz-Nummer in der Antwort-E-Mail hätte, auf die man sich beziehen kann oder nach der man im eigenen Postfach suchen kann. Hatte schon mal 4 oder 5 Themen beim Support offen ... und die Übersicht verloren.@jziegeler Da ist noch Luft nach oben!
-
@schwest sagte in Bug Tracking und transparenter Entwicklungsprozess:
Ich bin mir sicher, dass die Fehler, die ich melden will, schon von mindestens 20 Anwendern vor mir bemerkt worden sind. Mache ich mir jetzt die Arbeit, den Fehler erneut detailliert zu dokumentieren und per Mail dem Support zu berichten? Um dann mit 95%iger Wahrscheinlichkeit die Antwort zu bekommen: "Ist schon bekannt!"... da fehlt mir ein wenig die Motivation, weil ich denke, dass es überflüssige Arbeit ist.
Ich sehe das genau so, und möchte das Thema Bug Tracking erneut aufgreifen.
Wenn ihr denen, die ein Bug Tracking Tool zum aktiven ehrenamtlichen Mitarbeiten (als Tester) nutzen würden, nicht zutraut, dass sie zuerst suchen und dann vernünftig dokumentierte Issues formulieren, dann schneidet ihr euch ins eigene Fleisch mit unnötigen und wiederholten Supportanfragen zum gleichen Thema. So ein Zugang zu eurem (von eurer Code Basis separierten) Issue Tracker könnte z.B. über github account erfolgen - damit reduziert sich der Benutzerkreis auf die eher programmieraffinen Benutzer, die dann auch einen Mehrwert für euren Entwicklungsprozess bringen.
Natürlich wäre es noch zweckmäßiger, wenn man auf Antrag Zugang zu eurem Code mitsamt Issue Tracker bekommen könnte, um aktiv mitzuarbeiten. Aber damit kommen dann Self-Hoster und Forks wieder ins Spiel, daher lassen ich diesen Gedanken besser gleich wieder fallen.
Ein Bug Tracking System für registrierte Endbenutzer halte ich aber für unabdingbar und effizienzsteigernd. -
@schwest sagte in Bug Tracking und transparenter Entwicklungsprozess:
Diese Fragen bzw. Vorschläge wollte ich hier mal loswerden - vielleicht gibt's ja auch das eine oder andere schon und ich hab es nur nicht gefunden. Freue mich über jede Info zu diesen spannenden Themen
Leider gibt es keinen öffentlichen Bugtracker oder Roadmap. Das Entwicklerteam arbeitet intern mit solchen Tools, aber Prozesse und Pläne werden nicht transparent geteilt.
-
Wäre ich auch voll dafür. Meinetwegen müsste der auch gar nicht komplett öffentlich sein, sondern an Leute weitergegeben werden, die halt eine gewisse Anzahl Bugs reporten oder bei denen das Verständnis für so ein System erkannt wird.
Ich könnte z.B. nicht mehr sagen, ob ich Bugs nicht mehrfach reportet habe, weil ich bei der Menge an Reports einfach den Überblick verliere und manchmal Monate später wieder auf ein Problem stoße und nicht weiß, ob das zwischenzeitlich schonmal behoben wurde und erneut auftritt oder ob dies noch nicht behoben wurde. -
@Pat-Cummins Das ist so nicht korrekt. Wir stellen unsere Roadmap schon seit einigen Jahren in einem Livestream vor und haben diese Seite, die wir regelmäßig aktualisieren: https://church.tools/de/roadmap/
Was korrekt ist: Wir haben keinen öffentlichen Bugtracker. ChurchTools ist aber auch keine Open Source Lösung.
