Am Mit, 2002-03-06 um 19.31 schrieb Bernhard Walle:
Hallo,
On Wed, 06 Mar 2002 at 19:12 (+0100), Hartmut Meyer wrote:
Am Dienstag, 5. März 2002 10:32 schrieb Falk Sauer:
Das da wahrscheinlich ein sofortiges Veto aus der Marketing Ecke kommt ist mir klar,
Ja? Mir nicht. Was sollte das Marketing dagegen haben?
Man könnte der Meinung sein, dass es besser ist, Bugs zu verschweigen. Kann ich nur bestätigen, dieser Eindruck ist bei SuSE nicht ganz von der Hand zu weisen und passt auch sonst recht gut zum sonstigen Bild von SuSE, von dem man den Eindruck haben kann, dass es nicht gerade durch Transparenz gekennzeichnet ist.
Funktioniert aber im Linux-Umfeld sowieso kaum, also kann man es gleich bleiben lassen. IMHO, funktioniert es auch im Linuxumfeld, da viele Dinge (z.B. Bug/Feature, Kompetenz/Naivität) subjektiv sind und auch im Linuxumfeld viele Dinge politisch motiviert sind.
Wenn es ein Veto gibt, dann von den Entwicklern: das Problem ist, dass ein öffentlich zugängliches Bugzilla durch unqualifizierte Bugreports zugemüllt würde. Im Moment übt feedback@suse.de da ganz klar auch eine Filter-Funktion aus. Gleichzeitig schilderst Du aber in einer anderen Mail, dass feedback überlastet sei - Mir würde das zu denken geben.
Aus meiner Sicht als Aussenstehender hat sich feedback schon desöfteren als nicht funktionierend und uneffektiv erwiesen.
Dem könnte man dadurch begegnen, dass Beiträge von Nicht-SuSE-Mitarbeitern (oder Beta-Testern etc.) zuerst vorgefiltert werden, bevor Sie ins Bugtracking wandern. Hmm, ...
Oder gleich read-only. Jedenfalls könnte man dann, wenn man einen Bug meldet, diesen verfolgen und ist sich sicher, dass nicht alles nach /dev/null wandert (wobei ich jetzt keinesfalls behaupten möchte, dass dem so sei). Ich glaube, das eigentliche Problem liegt wo anders: Durch ein Bugtrackingsystem werden Fehler, Kompetenzen und Unternehmensstrukturen
1. Die Schwelle, etwas in ein Bugtrackingsystem zu stellen, liegt deutlich höher als die eine Email zu schreiben. 2. Vernünftig konfigurierte Bug-Trackingsysteme sind in Kategorien unterteilt, die intern in verschiedene Mail-Verteiler umgesetzt werden. D.h. allein dadurch reduziert sich der auf Mitarbeiter aufprallende Mail-Traffic ganz erheblich. Anstatt, dass 5 Mitarbeiter feedback durchforsten müssen (und möglicherweise einiges unter den Tisch fällt), verteilt sich der Mail-Traffic dann automatisch auf kleinere Gruppen. Klar, wenn diese Verteiler dann direkt zu den Entwicklern gehen, erhöht sich deren Traffic. Nur ändert das nichts an den Problemen der Anwender mit den Produkten/Verantwortlichkeiten der Entwickler. 3. Bugtracking-Systeme sind in der Regel durchsuchbar und helfen dadurch unnötige Bugreports zu vermeiden transparent und dokumentierbar. Möglicherweise liegt das nicht im Interesse aller Beteiligten :) Ralf