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