Bug Tracking und transparenter Entwicklungsprozess
-
Hallo zusammen,
gibt es für CT eigentlich einen öffentlichen Bugtracker? Wir würden den einen oder anderen Bug melden und ich fände es etwas unbefriedigend, das per Mail an die support-Mailadresse zu senden. Im Forum gibt es auch keine eindeutige Kategorie dafür.
Ein Bugtracker hat halt den Vorteil, dass man sieht, ob man der einzige ist, der das Problem hat, und dass man auch einschätzen kann, wie bald das Thema bearbeitet wird.
Darüber hinaus, aber in eine ähnliche Richtung gehend, habe ich mich auch schon oft gefragt, wie die Developer-Teams bei CT intern arbeiten. Gibt es ein gewichtetes Backlog und eine Sprintplanung, oder ein Kanban-Board? Wie weit im Voraus werden Releases geplant? Läuft das alles über Jira oder eine ähnliche Plattform?
Es wäre für die Anwender natürlich sehr interessant zu sehen, welche Fixes & Features jeweils für das nächste und das übernächste (...) Release geplant sind. Das würde den Entwicklungsprozess nach außen hin transparenter machen. Natürlich gibt es im Forum die "Featurewünsche", aber hier werden von CT-Mitarbeitern eben doch meist keine sehr konkreten Aussagen darüber gemacht, ob und wann so ein Feature denn nun wirklich umgesetzt wird (Beispiele: End-to-End-verschlüsselte Kommunikation im CT-Chat, Sprachnachrichten in der App...). Wenn man die Position eines solchen Features im Backlog sehen könnte, oder wenn man sehen würde, dass es (noch) gar nicht den Sprung ins Backlog geschafft hat, dann wäre man in manchen Fällen etwas schlauer.
Beide Ideen könnten mit einer öffentlichen Jira-Instanz oder etwas vergleichbarem umgesetzt werden - und die Anwender könnten voll partizipieren und insbesondere die Release-Planung mit einsehen.
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
Viele Grüße!
Stefan -
@schwest sagte in Bug Tracking und transparenter Entwicklungsprozess:
Im Forum gibt es auch keine eindeutige Kategorie dafür.
Die gab es jahrelang, ist dann aber abgeschaltet worden, um die Bugs zu bündeln und nicht auf mehreren Kanälen empfangen zu müssen.
eine Sprintplanung
Ja, aber das können die Mitarbeiter sicherlich konkreter beantworten.
-
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!
