Sehe ich auch so: Das Errorlog ist definitiv kein Entwicklerwerkzeug!
Dein Blogbeitrag lässt eine Erklärung vermissen, wieso man denn Fehlerspeicher eigentlich nicht zur Qualitätssicherung benutzen sollte. Du eröffnest mit einer Anekdote, wonach Kollegen mit der Auswertung des Fehlerspeichers überfordert gewesen seien, und infolgedessen hätten die zahlreichen Fehler wohl auch nicht zur Ergreifung sinnvoller QS-Maßnahmen geführt. So eine Situation liefert viele Ansatzpunkte, die man hätte kritisch hinterfragen können: War das Personal ausreichen geschult? Gab es evtl. eine toxische Fehler-Eingeständnis-Kultur? War das das Problem schlicht ein Ergebnis stiefmütterlichen Managements? Da hätte man sicher Interessantes zu berichten gehabt. Solche oder ähnliche Aspekte greifst du leider gar nicht auf. Stattdessen berichtest du von einer Scheinlösung des Konflikts: Ihr hättet den Fehlerspeicher vollkommen aufgegeben. Das heißt leider noch nicht, dass keine Fehler mehr auftreten, nur dass man sie nicht mehr sehen kann. Das verschlechert die Lage aller Beteiligten und ist damit Teil des Porblems, nicht Teil der Lösung.
Ja, man muss dem Besucher erklären daß jeder seiner Zugriffe geloggt wird.
Nein, man muss seine NuterInnen darüber aufklären, welche ihrer personenbezogenen Daten für welche Zwecke verwendet werden. Bei einem Fehlerspeicher gibt es erst mal keine größere Not überhaupt etwas Personenbezogenes zu speichern. Natürlich gibt es Ausnahmen davon, bspw. wenn ein Fehler im Bezahlprozess eines Online-Shops auftritt. Dann ist es in beidseitigem Interesse, dass der Fall lückenlos aufgeklärt werden kann, dafür ist es erforderlich zunächst das Einverständnis des Kunden bzw. der Kundin einzuholen.