Über Jahre hinweg hat die freie Software Gemeinschaft gepredigt, dass freie Software proprietärer Software überlegen ist, da die Bugtracker offen sind. Jeder Nutzer kann sich an der Weiterentwicklung freier Software beteiligen und mithelfen sie zu verbessern indem er Fehlerberichte einsendet. Ja die Entwickler freier Software nehmen sogar Wünsche an und warten nur darauf alles zu implementieren, was ein Nutzer als Wunsch äußert.
Wie sieht aber die Realität heute aus? Ist ein freier Bugtracker eine Hilfe für freie Software? Holen sich Entwickler Inspiration aus den Wünschen der Anwender? Gibt es bei der Entwicklung überhaupt Überschneidungen zwischen den Vorstellungen der Nutzer und der Entwickler?
Ich kann natürlich nicht für die gesamte freie Software Gemeinschaft schreiben und beziehe mich jetzt im weiteren auf meine Community also den KDE Plasma Workspaces. Persönlich bin ich Maintainer des Plasma Compositors und Window Managers mit aktuell > 400 offenen Fehlermeldungen und > 300 offenen Wünschen. Wöchentlich erhaltet unsere Komponente etwa 20 neue Bugs. Bei den Plasma Desktop Shells sieht es noch schlimmer aus mit > 1200 offenen Fehlermeldungen und > 1000 offenen Wünschen. Alle KDE Software zusammen hat mehr als 24.000 offene Fehlermeldungen und mehr als 17.000 offene Wünsche bei einer Änderungsrate von etwa 500 neuen Fehlermeldungen pro Woche und 50 neuen Wünschen pro Woche.
Als ich vor ein paar Jahren mit KDE Entwicklung angefangen hatte, lag KDE noch deutlich unter 20.000 offenen Bugs. Man müsste also annehmen dass die Qualität unglaublich sinkt wenn man den Zahlen glauben schenken würde. Jeder, der die Entwicklung von KDE Software über die letzten Jahre verfolgt hat, wird mir zustimmen dass die Qualität unglaublich gestiegen ist und nicht gesunken ist.
Was ist also die Erklärung für die steigende Anzahl Meldungen? Ganz einfach: der Bugtracker vermüllt! Kaum einer der neu gemeldeten Fehler sind zu gebrauchen. Nutzer sind nicht in der Lage korrekt zu suchen und melden wieder und wieder die gleichen Fehlermeldungen. Selbst wenn unser Dialog anzeigt, dass es schon mehr als 20 identische Crashreports gibt, wird ein neuer aufgemacht. Anderen Crashreports fehlt dann eine Anleitung sie zu reproduzieren womit eine Behebung unmöglich ist. Andere sind für komplett veraltete Software, wie sie von den Distributionen ausgeliefert werden. Wieder andere melden den Fehler und reagieren nicht auf Rückfragen. Oftmals reicht es nicht einfach nur einen Fehler zu melden, man muss mit den Entwicklern zusammenarbeiten um den Fehler zu erkennen. Wirklich gute und nützliche Meldungen sind leider die Ausnahme.
Für die Entwickler ergibt sich daraus natürlich ein Problem: wie findet man den nützlichen Report in all dem Müll? Und wie kann man den Bugtracker zur Koordination einsetzen? Ein Tool zum Verwalten der Aufgaben ist extrem wichtig und kann wirklich hilfreich sein und ich wünschte mir, ich hätte eins. Nur unser KDE Bugtracker ist es nicht. Was hilft mir ein Tool bei dem ich mit den Nutzern diskutieren muss, dass ich ihren Fehler nicht als wichtig ansehe? Oder ein Tool in dem ich stundenlang erst mal suchen muss bis ich einen Report finde, der genügend Informationen enthält um ihn zu beheben? Natürlich überhaupt nicht. Ich gehe nicht in den Bugtracker um einen Fehler zu suchen an dem ich jetzt arbeite. Über die letzte Woche habe ich viele Fehler behoben – kaum einer davon war im Bugtracker vermerkt. Die Existenz der Fehler war mir jedoch bekannt. Mein Bugtracker ist mein Kopf. Und das menschliche Gedächtnis skaliert nur sehr eingeschränkt.
Und wie sieht es mit den Wünschen aus? Gehen Entwickler in die Liste und picken sich eins davon aus und implementieren es? Auch hier ist die Realität, dass ich die Wünsche als komplette Müllhalde betrachte. Ändere ich einen Report von Fehler auf Wunsch ist es gleichbedeutend wie “> /dev/null”. Es gibt keine Wünsche der Nutzer, die sich mit meinen Entwicklungszielen überschneiden. Wenn ein neues Feature einen Wunsch erfüllt, so ist das reiner Zufall und nicht darauf zurückzuführen, dass Nutzer es als Wunsch geäußert haben. Dies führt natürlich zu einer weiteren Vermüllung des Bugtrackers: Wünsche, die implementiert werden, werden nicht auf geschlossen gesetzt. Und dass ein Nutzer kommt und es nachträglich macht, ist leider auch die Ausnahme.
Kein einziger Wunsch der Nutzer deckt sich mit den Entwicklungszielen, die ich habe. Nirgends gibt es einen Wunsch “KWin mit OpenGL ES/EGL” oder “Aufspaltung in mehrere Bibliotheken” oder “Unterstützung von Wayland”. Ein Nutzer kann nicht wissen wohin ein Projekt der Größe sich entwickelt und was die Ziele sind. Da Nutzer jeden Bugreport lesen und schreiben können (muss ja offen sein!) ist für mich der Bugtracker zur Planung völlig nutzlos. Ich kann mir nicht meine eigenen Bugs aufmachen, die nur von meinem Entwicklerteam gelesen und bearbeiten werden.
Dass Nutzer der freien Software durch das Melden von Fehlern und Wünschen helfen, ist für mich die größte Lüge der freien Software. Kein Fehler gemeldet von einem Nutzer hilft ihr, wenn es ihn mal gibt, geht er in der Menge von Müll einfach unter. Meldungen von Nutzern binden nur sinnlos Ressourcen der Entwickler, so verschwende ich wöchentlich etwa eine Stunde darauf immer und immer wider den gleichen Treiber Crash als Duplikat zu markieren. Neben all den anderen Meldungen die ich sinnlos beantworte. Ich mache dies (noch) um zumindest die Möglichkeit zu waren irgendwann einmal den Bugtracker noch sinnvoll zu benutzen und die Vermüllung einzudämmen.
Freie Software braucht Qualitätssicherung und auch Bugtracker – so wie jedes andere Projekt auch. Ein Bugtracker, der für jeden offen ist, kann aber keine Lösung mehr sein, dafür ist freie Software zu populär und Nutzer sind Nutzer und keine potentiellen Entwickler und Informatikstudenten mehr.
=-=-=-=-=
Powered by Blogilo
Das klingt alles nachvollziehbar und logisch. Dennoch würde ich nicht soweit gehen diese Kritik auf jede freie Software zu verallgemeinern. Kleinere Projekte, wie das damalige KDE, profitieren im höchsten Maße davon, dass sich jeder beteiligen kann, es müssen ja schließlich Menschen zum Projekt finden. Fraglich ist zudem, ob du bei einem geschlossenen Bugtracker damals zu KDE gefunden hättest.
Meiner Meinung nach hat das von dir beschriebene Problem nichts mit der allgemeinen Popularität freier Software zu tun, sondern vielmehr mit der Popularität der einzelnen Software. Ich wette, Microsoft hat bei seiner öffentlichen Betaversion ein ähnliches Problem, wie du bei KDE.
Ich würde jetzt gerne einen Lösungsansatz vorschlagen, aber leider fällt mir keiner ein. Hoffentlich hat einer eine zündende Idee, wie sich das in den Griff bekommen lässt.
Für kleine Projekte ist es sicherlich noch hilfreich. Jedoch kenne ich kaum noch welche. Die meiste Software, die wir heutzutage als freie Software einsetzen ist richtig groß.
Was Du hier anprangerst, geht ja mal garnicht! Ich habe auch schon Stunden damit verbracht, Bugreports (Nicht nur, aber oftmals für KDE) zu schreiben. So gut wie davon waren formal korrekt und brauchbar, einige davon sind immer noch nicht behoben, einige konnten in Zusammenarbeit mit den Entwicklern gelöst werden. Ich erstelle wenn nötig weiterhin Bugreports. Und ich bin kein Informatikstudent. Bugtracker sind eine extrem wichtige Schnittstelle zwischen Anwender und Entwickler. Nur weil viele Leute zu blöd sind, sie richtig zu benutzen, ist das doch nicht die Schuld der Bugtracker…..
Du meinst also, ich sollte weiterhin die Lüge unterstützen und nicht die offensichtliche Wahrheit aussprechen?
Kannst du als Nutzer das wirklich beurteilen?
Sicherlich ist es nicht die Schuld der Bugtracker, trotzdem macht es den Bugtracker unbrauchbar. Wenn alle Bugs gut wären, gäbe es keine Probleme. Wenn aber > 90 % einfach Müll ist (und das dürfte die aktuelle Quote bei KWin sein), dann ist es nicht zu gebrauchen und der gute Bugreport wird nicht mal mehr erkannt.
mir ist auch schon passiert, das ich einen Fehler entdeckt habe und diesen im bugtracker gemeldet habe. Später wurde er dann als Duplikat entlarvt. Mein Problem ist dabei wohl leider auch, das ich nicht sehr gut Englisch kann.
Mein Vorschlag, wäre, dass der Bugtracker die Fehler nicht mehr auf einer Webseite entgegen nimmt, sondern auf dem PC des Meldenden. Wenn man ein Programm im Bugtracking mod starten könnte, in einem Programm innehalten und in der Anwendung vielleicht mit Pfeilen und Schriftfeldern Anmerkungen machen kann, dann könnten die letztendlich übermittelten Fehler wesentlich detaillierter sein und vielleicht teilweies automatisch als Duplikat gewertet werden.
wir haben ein Tool das automatisch nach Duplikaten sucht: in jeder KDE Anwendung unter dem Hilfe Menü. Bei Crashers ist es sogar so genau, dass es einem mit 100 % Genauigkeit sagt, dass es ein Duplikat ist, trotzdem bekommen wir immer und immer wieder die gleichen (zum Teil schon längst behobenen) Crashers gemeldet. Ich bezweifle das weitere Automatismen das Problem beheben können.
Ich kann dir nur teilweise zustimmen. Ich habe schon bei mehreren großen Projekten Bugreports erstellt (Eclipse, OpenOffice und KDE), und die meisten davon wurden binnen kürzester Zeit behoben.
Interessanterweise sieht meine Bug-Report-Bilanz bei KDE ein bisschen anders aus (3 duplicates und 1 offener, der seit einem Jahr vor sich hin gammelt)
Die gefixten Bugs, die ich bei Eclipse erfasst habe, wurden alle innerhalb eines Monats behoben. Mein OpenOffice Bug wurde, soweit ich mich erinnere, auch innerhalb von drei Monaten behoben.
Was ist also beim KDE-Tracker so anders? Es könnte daran liegen, dass es die Möglichkeit der automatischen Bugreports gibt, die es jedem einfach machen einen Bugreport zu erstellen. Vielleicht sollte man diese von den manuell erfassten Bugreports unterscheiden. Denn der Müll, wie du ihn nennst, stammt wahrscheinlich zu 99% von DrKonqi (oder wie das Ding heisst)
Meine KDE Bugs die als DUPLICATES markiert sind, habe ich so erstellt. Der eine, der noch offen ist, wurde manuell, mit viel Liebe erfasst 😉
Du hast den Bug ja auch gesehen: https://bugs.kde.org/show_bug.cgi?id=232554
Wie wäre es also, wenn man in den Bugs ein Flag einführt, das anzeigt, dass der Bugreport von DrKonqi stammt, dann könnte man den “Müll” besser filtern.
Der Unterschied ist wahrscheinlich, dass Eclipse nur von erfahrenen Nutzern benutzt wird. Es ist eine andere Zielgruppe.
Selbst wenn alle Bugs von DrKonqi als solche markiert werden, löst es das Problem nicht, dass der Bugtracker vermüllt. Es ist nur eine Art es auszublenden – also ziemlich das selbe was ich beschrieben habe.
Man könnte einführen, dass mit jedem Releasezyklus (also halbjährlich), die Karten wieder neu gemischt werden, also alle Bugreports gelöscht werden, außer denjenigen, die die Entwickler als wichtig genug empfunden haben und explizit von ihnen sticky markiert wurden. Also Mut zur Lücke. Wenn ein Report, der dadurch verloren ging wirklich so wichtig war, dann wird es schon wieder auf den Tisch kommen.
Wäre eine Lösung ist aber den Nutzern gegenüber auch unfreundlich. KMail wird so weit ich weiß nun so eine Lösung gehen und alle Bugs zu KMail 1 einfach schließen.
dies war auch mein erster gedanke.. alle bugs die nicht von einem entwickler beobachtet und als halbwegs wichtig eingestuft wurden raus!
ich denke die anzahl an duplicates steigt nunmal auch gewaltig mit der anzahl an bugs (es wird auch für user unübersichtlich)
wenn ein reset hilft das system wieder benutzbar zu machen wird die userbase das verstehen!
darüber hinaus könnte man eine art sicherheitsroutine einführen sodass nur dann ein bug auch wirklich veröffentlicht wird wenn der user bereits 2 von entwicklern als valid eingestufte bugreports hat.. bis dahin sind die bugs als “waiting for approval” als “müll” ausgewiesen…
Zumindest im Einzelfall scheinen kleinere Wünsche doch nicht sinnlos zu sein. Ich hatte mir bspw. vor einiger Zeit gewünscht, dass man durch die Kategorien von Lancelot mit Bild hoch/runter navigieren kann. (So kann man das Plasmoid komplett mit einer Hand bedienen.) Ivan C. hat das gelesen, für gut befunden und implementiert. Zugegen: Die Anzahl der Bugs/Wünsche für Lancelot ist sehr übersichtlich.
So geht‘s mir beim Netzwerkmanager auch. Ich hab echt Respekt vor Lamarque V. Souza (oder wie der heißt :D) und seinem Team natürlich. So sitze ich z. B. im Zug mit dem Laptop und spiele am Netzwerkmanager-Plasmoid rum, und mir fällt auf „Hey, ich muss immer auf ‚Mehr anzeigen‘ klicken, damit ich die umgebenden WLANs seh, obwohl keine meiner gespeicherten vorhanden sind“. Wish abgesetzt und keine fünf Stunden später war auch schon das GIT-Commit drin. Oder „Warum hab ich am PC ne Checkbox ‚Drahtlosnetzwerke aktivieren‘, wenn ich eh kein WLAN hab?“ Wish abgesendet. Am nächsten Tag war‘s drin. Oder „Hey, bei der Energieverwaltung kannst die Benachrichtigungen gleich vom KCM aus aufrufen, jetzt wo die Netzwerkverwaltungsbenachrichtigungen tun, warum geht das hier nicht?“. Wish abgesendet. Fünf Stunden später sah ichs im Planet, dass es implementiert wurde. Ich hatte Netzworkmanager gehasst, aber langsam finde ich das Teil echt klasse. Ich würde mal nicht behaupten, dass diese ganzen Dinge – wenn sie zwar auch offensichtliche Nützlichkeiten sind – von vornherein auf dessen Entwicklungsplan standen.
*Thumbs up*
Liegt wohl daran, dass jeder seinen Rechner anders benutzt. Darum sieht jeder andere Sache und stößt auf andere Bugs; Bugs, die ein Entwickler, der ja auch nur bestimmte Benutzungsweisen im Kopf hat (wenn auch mehr als ein normaler User) nicht sieht.
Hallo, ich bin Fault-Coordinator in einem kommerziellen Telekommunikationsprojekt und für eine Abteilung mit ca. 100 Vollzeitentwicklern zuständig. Ich und meine Kollegen in anderen Abteilungen sortieren rigoros aus. Es gibt klare Richtlinien wie ein Fehler dokumentiert sein muss, welche Logs dabei sein müssen, etc. Ist das nicht der Fall wird einmal nachgefragt, danach wird der Fehler abgelehnt. Ähnliche oder gleiche Fehler werden zusammengelegt und nach der Korrektur en bloc zum Testen freigegeben. Die Fehler werden nach Dringlichkeit und Wichtigkeit gewichtet und dementsprechend den Ressourcen zugewiesen. Natürlich ist das nicht mit einem mehr oder weniger just for fun Projekt zu vergleichen – der Druck in meinen Projekten ist ziemlich hoch, der Kunde will Korrekturen und Releases sehen. Andererseits dürfte das Hauptproblem das gleiche sein: den Überblick bekommen und behalten.
genau so müsste es im Prinzip bei freien Projekten der gleichen Größe auch sein. Es bräuchte “Fault-Coordinatoren”.
Ich gebe euch vollkommen recht, aber einer gewissen Projekt-Größe kann man Bugs nicht mehr auf diese Art und Weise verwalten. Es gibt sehr gute Ansätze und Ideen, wie man solche Anfragen professionell managt und damit die Entwicklung entlastet.
Die Frage ist aber, habt ihr jemanden, der dieses “Bug-Management” übernehmen könnte? Soweit ich weiß mangelt es doch bei solch freiwilligen Projekten gerade daran, oder?
Bei freiwilligen Projekten mangelt es in der Regel an allem. Es gibt zwar einen Bugsquad, aber das Team kommt bei weitem nicht nach.
Also ich schaue gelegentlich (meist wenn eine neue Major-Version rauskommt) über sämtliche meiner noch offenen Wishes und Bugs und schau, ob die noch drin sind oder ob es mittlerweile (zufällig) gefixt wurde.
Leider krieg ich irgendwie vom Bugtracker keine E-Mails mehr, was das Verfolgen von Bugs erschwert, kp, warum.
Vielleicht bräuchte es einfach mehr nicht Entwickler, die dennoch mit der Materie vertraut sind und Bug Reports sortieren, als duplicate vermerken und somit ausmisten…
Ich versteh deinen Ärger aber sehr gut und habe mich als nicht Entwickler sondern als User gefragt, wie man derartige Massen an Reports verarbeiten möchte.
Nun es gibt das “BugSquad”. Das “Problem” dabei ist aber, dass sobald die Nicht-Entwickler so vertraut mit der Materie sind, dass sie verlässlich Bugs sortieren können, anfangen nicht mehr die Bugs zu sortieren, sondern zu entwickeln 😉
Um die oben bereits erwähnte Position eines Fault-Coordinator auszufüllen gibt es zwei Wege: entweder einen Unwissenden, der das Ganze rein formalorganisatorisch abwickelt oder aber einen Senior Expert, der einschätzen, analysieren, zuweisen,erklären, nachfragen und auch verantwortlich ablehnen kann. Ich erlebe beides, beim ersten Weg ist der FC völlig frei und lässt die Entwickler im Hintergrund analysieren, muss also sehr git wissen,wer was wie gut kann. Beim zweiten Weg werden die Entwickler entlastet und bekommen regelmässig fixfertig analysierte Probleme, das Management hat aber i.d.R. einen guten Entwickler von der Entwicklungsarbeit abziehen müssen.
Hi Martin! So hab ich das mit dem KDE Bugtracker auch erlebt. Ein weiterer Punkt der dazu kommt: Ich habe mich sehr um die Phonon Bugreports bemüht die reinkamen. Gefühlt waren 90% verkappte Support anfragen: falsche Konfiguration, Mixer aus, Anlage vergessen anzuschalten ;-), Treiber-Probleme, sonstiger Distri-Wahnsinn, … Ich habe kaum Zeit mit dem verbracht was mir Spass gemacht hat und zu viel auf den Bugtracker geachtet. Man kann hier vielleicht sogar folgern, dass der Bugtracker kontraproduktiv war.
Ganz anders sieht das aber, denke ich, bei Projekten aus die eigentlich nur von Entwicklern benutzt werden. Z.B. schreibe ich in letzter Zeit häufiger GCC Bug Reports. Die werden in Rekordzeit reprodiziert, assigned und teilweise dann sogar innerhalb von Tagen gefixt. Das macht Spass. Allerdings brauche ich im Schnitt mehr als einen ganzen Arbeitstag um so einen Report zu erstellen.
Im Kontrast dazu steht für mich ICC. Intel hat keinen offenen Bugtracker und sieht scheinbar auch nicht vor, dass nicht-zahlende Benutzer gute Bugreports liefern könnten. Das Ergebnis ist, dass ich um ICC Bugs rumprogrammiere und anderen Leuten mitteile, dass ICC eher mit Vorsicht zu genießen ist.
Vielleicht macht man wirklich besser zwei Bugtracker. Einen, auf den nur die Entwickler Zugriff haben (z.B. der Issue Tracker von Redmine — find ich super das Ding). Ein zweiter Tracker, der offen ist. Da muss sich dann eine Community bilden die diesen Reports nachgeht — ansonsten ist das nur ein frustrierte-User-stummschalten-Gerät was zu noch mehr Frust führt. Sowas wie die Bugsquad gemacht hat. Wenn die dann was substantielles zusammengetragen haben kann das dann in den geschlossenen Tracker aufgenommen werden.
Das kommt mir bekannt vor 🙂
Darüber hab ich auch schon nachgedacht. Das Problem ist halt, dass es eine Community braucht, die die Bugs sortiert und verschiebt. Ansonsten ist es halt echt nur ein User Stummschalten – was ja auch keine Lösung ist.
Vielleicht wäre es tatsächlich die Lösung, Distributionscommunities mit einzuschalten. Wenn ich bei Launchpad unterwegs bin und zufälligerweise auf einen Bug stoße, der mir als Duplikat vorkommt, markiere ich ihn nicht als solchen – ich bin ja kein Entwickler und könnte mich irren. Kommt aber in einem Forum eine Anfrage, die sich nicht durch Support beheben lässt und wie ein Bug aussieht, dann suche ich den entsprechenden Bugreport raus und verweise den Benutzer auf ihn, somit entsteht kein unnötiges Duplikat.
Idealerweise würde man also die potentiellen Bugreporter auf ein Distributionscommunity-Forum verweisen, wo dann Supporter und andere Nutzer eine Vorauswahl der Bugs vornehmen können. Dafür müsste man im Prinzip nur die automatischen Reportmechanismen von den Distributionen entsprechend anpassen lassen und ich denke, dass bald auch die nichtautomatischen Reports über die Communities laufen würden. Wäre übrigens auch für die Distributoren interessant, weil man so die Popularität der eigenen Foren steigern würde. Und noch ein Pluspunkt: Man könnte an lokale Communities (in Abhängigkeit von der Systemsprache) verweisen, womit auch Sprachprobleme behoben wären.
Hallo Martin, auch wenn ich nicht alles verstehe, was Du schreibst (ich kann mir einen Bugtracker nicht wirklich vorstellen), so gebe ich Dir im Ansatz völlig Recht: Die “Endkontrolle” muss effektiv sein und greifen. Aus meinem privaten Umfeld weiß ich, dass bei der Bitte um einen Rat meine Frage: “Ja, was hast Du denn vorher gemacht? Gab es eine Fehlermeldung?” den Bittenden in Verzweiflung stürzen kann. Ich selbst habe einmal XP unbrauchbar gemacht durch Installation einer Adobe-Software, die auf dem Papier absolut verträglich war – aber frage mich bitte nicht, was ich da eigentlich angestellt habe.
Meine Erfahrungen:
Ich teste gern die neuen Alpha- und Betaversionen von Ubuntu, und gerade Natty war ein echtes Abenteuer. Im Anfang habe ich mich bemüht, jeden Fehler an Launchpad weiterzumelden, habe dort ein Konto, es ist also erst einmal ganz einfach. Nur: Mein Englisch reicht nicht aus, um zu verstehen, was “die” von mir wollen. Manchmal bekam ich dann eMails. Ich begriff nicht: Ist das eine Eingangsbestätigung? Wollen sie mehr wissen? Sagen sie mir, dass noch 13 andere Tester das selbe Problem haben? Meinen sie, dass, wenn man den Link wxyz nutzt, dass man dann eine Lösung findet oder aber, dass es derselbe Fehler in anderem Gewande ist?
Bugtracks müssen muttersprachlich sein.
Wenn die Experten Fehlerberichte lesen, sollten sie in der Muttersprache des Anwenders reagieren. Wenn sie Fragen haben, die der Computer beantworten kann, weil es irgendwo eine Log-Datei gibt, dann schicke ich gern eine solche Datei weiter. Aber ich weiß nicht, wo sie liegt. Als Anwender bin ich auch ein “Computer-Idiot”.
Ich erlebte es einmal bei einem öffentlichen Beta-Test von Soft-Maker. Ich schrieb auf Deutsch, die reagierten auf Deutsch; so kommt etwas dabei raus. Ähnliches erlebte ich bei Wuala.
Fehlermelder brauchen die Geduld des Experten.
Du sprichst noch das Problem an, dass Die Ziele eines Entwicklers meilenweit weg liegen von denen der Nutzer und Fehlermelder. Und – das ist meiner Ansicht nach auch ein Anteil der Unity-Debatte – die Ziele potentieller Anwender unterscheiden sich sicherlich von denen, die ein System schon kennen und nutzen. Ich glaube, dass Entwickler immer so etwas wie eine Avantgarde sind, und ich dappel hinterher.
Die Linux-Community braucht – wie jeder größere Betrieb – organisierte Kommunikation; offen und frei reicht da nicht aus. Ich als Anwender bin interessiert an Berichten von Anwendern über das, womit Ihr Euch herumplagt. Solche Berichte verstehe ich jedoch nur dann, wenn sie in Alltagssprache formuliert sind.
Die Community braucht Übersetzer und organisierte Kommunikation.
Viele Grüße, Bostaurus
P.S. Ich setze mich in den letzten Wochen von meiner Linux-Einstiegsdroge Gnome ab in Richtung KDE. Tüftele mit Mint KDE, Kubuntu, Kanotix und einem älteren 3.5-Mandriva. Bugs habe ich keine zu berichten, obwohl ich beim Reinarbeiten, da nicht im Produktivsystem, rücksichtslos bin. Das alles passiert allerdings auch nach Arbeit und Familie nachts um 23:00 h oder so. Da weiß ich wirklich oft nicht mehr, was ich tat.
Ich bin strikt gegen muttersprachliche Bugreports. Das erhöht den Aufwand noch weiter als ihn zu reduzieren. Zu allen Problemen die wir schon haben, holen wir uns die Missverständnisse durch die Übersetzungen.
Ich ignoriere mehr oder weniger alle Bugreports, die nicht in Englisch sind, selbst wenn sie in Deutsch (also meiner Muttersprache) sind.
Das schätze ich anders ein, da die Entwickler untereinander viel eher wissen, wo Quellen für Missverständnisse liegen als dass ich ahne, dass ich mich bei der Beschreibung einer Beobachtung in Computerenglisch gerade sackblöd ausdrücke.
Ich kann Martin nur zustimmen. In internationalen Projekten hat sich Englisch als quasi Standard herausgebildet. Wenn ich bei meiner Arbeit muttersprachliche Fehlermeldungen akzeptieren müsste, wäre ich ein sprachliches Genie, das Japanisch, Chinesisch, Indisch, Polnisch, Finnisch, Kroatisch, Spanisch und Italienisch könnte. Oder aber wir hätten für jede Sprache einen native speaker, der sich dann wiederum mit den anderen Muttersprachlern in – ja was dann eigentlich – über die Fehler, duplicates, Korrekturen unterhalten muss. Das ist nicht machbar.
Vielmehr muss man den Bugreportern die Eingabe von Fehlerreports vereinfachen, z.B. durch Standards und andererseits muss man bie unverständlichen Fehlermeldungen nachfragen und klären (wollen). Das erfordert aber Zeit und Engagement, beides muss nicht da sein.
Standardisierung und (muttersprachliche) Abfragebögen – ich wehre mich überhaupt nicht gegen Vereinfachungen. Im Gegenteil: Im Verhältnis zu kommerziellen Betrieben ist der Druck im nichtgewerblichen Bereich, sparsam mit den Kräften umzugehen, wesentlich höher. Mir geht es darum: Übersetzt werden muss [fast] immer, das fängt ja schon an bei der Übertragung von Alltagsdeutsch in Computerdeutsch (lässt sich in jeden beliebigen Technik-Bereich beobachten [“Mein Auto tut so komisch,” sagt der Kunde zur KfZ-Meisterin und die muss dann weiterfragen]) an; Übersetzungen sind häufige Fehlerquellen, siehe internationale Verhandlungen. Also sollten Übersetzungen da geschehen, wo Fehler die geringsten Auswirkungen haben.
Insgesamt ist mir auch klar: Es sind meine Überlegungen. Martin und Du – Ihr habt die Erfahrungen.
wenn ich als Entwickler nicht weiß wovon der Anwender eigentlich spricht, da es völlig falsch übersetzt ist, kann man auch keine Missverständnisse mehr ausräumen.
Du beschreibst was ich denke. Danke
Aus genau diesem Grund habe ich ja vorgeschlagen, dass Bugs auf dem PC direkt erstellt werden statt auf einer Webseite.
Theoretisch könnten z.B. Englische Entwickler mir Deutschsprachigen so auch anfragen nach Log Dateien auf den Desktop zusenden und ich könnte einfach OK drücken und schon haben Entwickler alle nötigen Infos.
@userwünsche:
userwünsche sehen klarerweise oft anders aus als die der entwickler wenn eine software erstmal eine gewisse funktionalität erreicht hat.
(ich würde mir wünschen dass die “aero-snap” funktion ein wenig hübscher wäre – so mit transparentem background und so ^^)
klar interessiert dich das nicht, aber ist es deshalb unwichtig?
(zugegeben dieses bsp ist ziemlich unwichtig 😉 )
aber schliesslich sind es doch die user die eine software stark machen und verbreiten wenn sie damit zufrieden sind und diese als “ihre” software ansehen (was genau durch das eingehen auf deren anforderungen geschieht)
warum sind im bugtracker überhaupt wünsche zu finden?
wäre dafür nicht ein system wie http://forum.kde.org/brainstorm.php sinnvoller? (auch ubuntu.brainstorm wurde unglaublich gut angenommen von den usern und viele haben sich sehr sehr viel mühe beim formulieren ihrer ideen gegeben)
was haltest du von deartigen “wunschsammlungen” mit bewertungsmöglichkeiten?
werden diese von entwicklern wahrgenommen?
sind diese eine gute quelle für interessante featurevorschläge?
thx!
Letzte Woche implementiert
Ist es auch, deshalb wurde es ja eingeführt.
Kommt drauf an. Generell ist es dann schon mal vorgefiltert – nicht jeder Quatsch landet auf dem Schreibtisch der Entwickler. Dennoch heißt noch lange nicht, dass nur weil etwas viel Unterstützung hat, es auch sinnvoll ist oder überhaupt technisch umsetzbar.
🙂
dann findest du ja zum glück doch zeit für solche nebensächlichkeiten… freut mich natürlich genauso wie wenn ich deine bestrebungen und überlegungen zu wayland oder zu sinnvollen umstrukturierungen bei den libs usw. am blog lese…
stimmt.. nur dass die beliebtesten ideen dann erst wieder an den bug tracker übermittelt werden (und in dessen “müll” untergehen.. )
Ich sehe das gar nicht als Nebensächlichkeit an, sondern es war ein ziemlich wunder Punkt. Das war genau eins der Dinge die man als “Elegance” bezeichnen würde. Es hatte in der Implementierung immer noch eine Kleinigkeit gefehlt um das umzusetzen und diese Kleinigkeit haben wir von einem neuen Entwickler bekommen, also konnte ich es endlich richtig umsetzen.
Ich würd mal sagen, es kommt auch immer drauf an.
Für’n Eintrag „Schließenknopf in Fensterübersicht“ würd’ ich jetzt kein Brainstormeintrag machen, sondern kurz in den Bugtracker schmeißen.
Oder für „‚Drahtlosnetzwerke aktivieren‘-Knopf ausblenden, wenn keine entsprechende Hardware vorhanden ist“. Aber Martin hat ja schon häufig angedeutet, dass ihn die Wishes im Bugtracker ankotzen und er mehr Wert legt auf das, was im Brainstorming-Forum steht (soweit ich das richtig gedeutet habe).
Hi!
Hat der KDE-Bugtracker keine Möglichkeit, Fehler, die nach langer Zeit keine Reaktion des Reporters mehr erfahren haben, automatisch stillzulegen? Besonders auf Launchpad ist diese Funktion sehr hilfreich, damit konnte ich z.B. beim PackageKit Paket in Debian/Ubuntu die Fehlerzahl von ~80 auf nun ~14 bugs reduzieren.
Des Weiteren: Warum sind Feature-Requests im Bugtracker zu finden? IMHO gehören die da überhaupt nicht hin, ein Brainstorm-Tool wäre da glaube ich viel besser geeignet.
Es gibt ja auch ein Brainstorm-Tool und eigentlich sind die Wishlists nur noch gedacht um Ideen aus Brainstorm zu den Entwicklern zu transferieren. Trotzdem gibt es halt Nutzer, die Wünsche äußern (notfalls halt als Bug)
Die Idee mit dem automatischen Schliessen von Bugreports aufgrund von Inaktivität klingt doch eigentlich sehr gut. Habt ihr vor soetwas einzubauen? Das würde ja dann auch das Problem mit den Wünschen lösen. Die fliegen einfach nach einer Weile wieder raus – es sei denn sie sind so populär, dass sich regelmässig jemand findet der für Aktivität sorgt.
Eine Idee die mir beim Anschauen vom KDE Brainstorm gerade gekommen ist: Wie wäre es mit einer Funktion um über einen Bug abzustimmen? Zumindest die häufigen/lästigen Bugs hätten dann viele Stimmen und könnten von den Entwicklern somit einfach entdeckt werden.
Was ich auch noch loswerden muss: Martin, du wirkst total frustriert, so lässt sich doch keine Lösung finden. Schlaf ein oder zweimal drüber, dann sieht die Welt gleich wieder viel besser aus 😉
Also ich zumindest kenne die größten Probleme von KWin. Ich denke den anderen Entwicklern geht es auch so, dass sie ihr Projekt gut genug kennen um nicht auf Abstimmungen von Usern angewiesen zu sein. Und es hilft auch nichts, denn es berücksichtigt zum Beispiel nicht was technisch möglich ist. Übrigens bietet Bugzilla die Abstimmfunktionalität. Bei KWin führt ein Bug, der technisch nicht behoben werden kann.
Was denkst du denn wie viele Nächte ich schon drüber geschlafen habe? Das Problem ist ja nicht neu. Und nein, frustriert bin ich nicht. Es ist eher resignieren.
Hi Martin,
ich finde es toll mal so ein ehrliche Antwort von jemand zu bekommen ,der derart involviert in ein so großes Projekt ist.
Wenn ich dich richtig verstehe, ist das Problem das ihr zum einen zu viel Feedback bekommt und zweitens dieses oft fehlerhaft ist.
Letztendlich müsst ihr also große Mengen an Daten analysieren und bewerten.
Als erstes würde ich eine Möglichkeit schaffen, das angemeldete User Bugreports für gut befinden können. (So wie bei Facebook etc. wo man einen Button für “I like” hat.) Wenn jetzt Entwickler nach Bugs sucht, kann er einfach die Liste danach geordnet ansehen. So sollten doch schonmal die häufigsten Bugs beseitigt werden.
Dann wäre ein Algorithmus gut, der BEVOR ein Bugreport abgesendet wird überprüft, ob in letzter Zeit nicht ein ähnlicher aufgenommen wurde. Wenn ja wird der User darüber informiert und hat die Wahl seinen Bug dort anzuhängen oder einen neuen zu eröffnen.
Um letztendlich nicht völlig in Bugs zu ersticken, würde ich nach einem halben Jahr eine automatisierte Mail an den Bugreporter schicken. Darin steht dann, dass sein Bug noch nicht gefixt wurde und demnächst gelöscht wird. Wenn er das nicht möchte muss er ihn nochmal bestätigen. Ich schätze mal das bestimmt die Hälfte der Leute das nicht macht, da der Bug gar kein Bug war oder längst gefixt wurde.
Was hälst du davon ?
Mfg Mo3bius
bis auf die automatisierten Mails gibt es das schon alles – ohne sichtbaren Erfolg.
Ohne Rückmeldung kommt kein System aus. Selbst Diktaturen investieren Unmengen darin via Geheimdiensten. Resignierst wegen des “Verbraucherverhaltens” oder lassen sich in den Strukturen, in denen Du tätig bist, Deiner Ansicht nach nötige Änderungen nicht durchsetzen?
Userverhalten zu ändern halte ich für das Schwierigste. Wenn es eher “um eine oder mehrere Etagen höher” geht, machst Du im Augenblick alles richtig; Du sorgst für eine öffentliche Diskussion. Ich war mir bis vor ca. drei Stunden noch nicht einmal des Problems bewusst.
Hallo,
interessanter Blog-Eintrag.
Ich denke, dass man vielleicht zusehen sollte, dass man das Kommentieren von Bugs unterbindet bzw. dass ein Kommentar erst frei geschaltet werden muss. Oder das man den Bug-Tracker an sich öffentlich lässt, aber Kommentare zu einem Bug “geschlossen” sind, also nur für die KDE devs, Entwickler usw. sichtbar. Dann würde es wahrscheinlich nicht mehr zu solchen hitzigen Diskussionen wie hier kommen:
https://bugs.kde.org/show_bug.cgi?id=265051
Aber nebenbei will ich auch noch sagen, dass das wirklich ein extrem nerviger Bug ist und mich schon an den Rand der Verzweiflung getrieben hat. Habe zwar mittlerweile einen Workaround dazu gefunden, aber naja, es ist eben nur ein Workaround. 😉 Deswegen kann ich es ehrlich gesagt auch gar nicht so richtig fassen, wenn du schreibst:
> Kaum einer der neu gemeldeten Fehler sind zu gebrauchen.
Ich weiß ja nicht wie andere Bug-Reports aussehen, aber dieser ist nun wirklich eindeutig. Der Status des obigen Bugs ist aber immer noch “NEW”. Ich meine, ich kann es schon nachvollziehen, wenn sich einige Entwickler beleidigt (oder so) fühlen, wenn Anwender ankommen und nach dem Motto fragen: “Wann wird denn endlich dieser beschissene Bug geschlossen?”. Ich meine solche grundlegenden Funktionalitiäten wie der Betrieb von verschiedenen oder mehreren Monitoren sollte doch eigentlich funktionieren und keine Probleme bereiten, oder?
Aber darüber hinaus glaube ich auch eine Antwort dazu zu haben, warum die Zahl der Bug-Reports in den letzten Jahren so extrem zugenommen hat, während die Qualität und Stabilität mit jeder KDE-Version auch immer mehr zunimmt:
Liegt es nicht daran, dass gerade Canoncial mit Ubuntu Linux einen gewaltigen Schub gegeben hat und die Zahl der Linux-Nutzer in den letzten Jahren (extrem) zugenommen hat? Natürlich hat sich auch KDE und andere Desktops in den letzten Jahren extrem gut weiter entwickelt, was sicherlich auch ein Grund für die steigenden Nutzerzahl von Linux-Distris (insbesondere Ubuntu und dessen Derivaten) ist.
In der Tat etwas echauffiert die Diskussion. Wenn man aber mal die Zeitstempel anschaut weiss man auch warum. Da passierte mit einem TOP-Problem lange Zeit nichts. Das Problem war zwar nicht blockierend, aber doch seh nervig. Wenn dann die User, bei mir die Kunden, nicht auf dem aktuellen Stand der Untersuchungen gehalten werden, raucht es eben ein bisschen. Für mich ein schönes Beispiel für entweder mangelnde Priorisierung oder aber nicht publizierte Priorisierung. Das wirkt dann wie Willkür. Aber nichtsdestotrotz ist das Ganze eben ein Freiwilligenprojekt und die allermeisten Leute werden nicht dafür bezahlt. Damit ist das ganze zwar ärgerlich, aber auch nicht weiter verwunderlich. Es liesse sich wahrscheinlich viel durch bug-management machen, aber wer sollte das auch tun? Vor allem weil alle so gerne entwickeln 🙂
1. Es heißt Bugtracker-Lüge (http://de.wikipedia.org/wiki/Leerzeichen_in_Komposita)
2. In Ubuntu kann man (einfach, dalso für den “normalen” User) keinen Bug eingeben außerhalb von “ubuntu-bug”, einem Tool, das die einfachsten, schon x-mal geposteten Bugreports mal aussortiert, wenn sie die gleiche Signatur haben.
Wäre das nicht auch für KDE generell sinnvoll?
Das nächste mal blogge ich wieder auf Englisch und in planetkde. Da bekommt man wenigstens nicht so sinnlose Kommentare.
Hey Martin,
das würde ich sehr schade finden. Ich lese gerne in Deinem Blog, da es häufig doll technisch oder Deine kritische Sicht auf Dinge ist, die ich sonst so nie zu hören bekäme.
Danke dafür und bitte (ich schreie gerade nicht 😉 ) poste auch ab und an auf dem UU-Planet. Das bereichert ihn.
Bei Canonicals Launchpad wird stark mit Automatisierung gearbeitet und versucht dieses upstream/downstream-Problem irgendwie zu lösen. Ich glaube die setzen auch stark Bots und Textbausteine ein. Andere Methoden sind die nicht so technisch versierte Gemeinschaft zu motivieren https://wiki.ubuntu.com/5-A-Day Ich mag Bugzilla aber nicht, weil es etwas altbacken ist. Teilweise poppt der KDE Crash Dialog aber auch zu häufig auf. Bei Microsoft und Windows XP kommt dann gelegentlich nur so ein Dialog und je nach Laune drückt man auf Absenden ja oder nein. Wie er ausgelöst wird ist mir übrigens völlig unersichtlich und Changelogs von Windows Patches habe ich auch noch nie gelesen.
Why not make the bug submission thing submit to the distro instead of bugs.kde.org?
Then you would not get bugs related to distro patches, or out-of-date versions, and important bugs could get forwarded on to you.
(Entschuldigung; ich spreche keine Deutsch)
so instead of one dumping place we get 20. That really sounds like a general solution.
Danke für den Beitrag. Ich werde ihn mal Bookmarken, für spätere Verwendung.
Besonders interessant fand ich den Teil über die Benutzerwünsche. Es ist teilweise schon erschreckend, wie manche User ihre Wünsche und Vorstellungen geltend machen wollen.
Hallo Martin,
klar ist es demotivierend den ganze Tag größtenteils nur “Müll” zu sortieren. Andererseits seid “Ihr Entwickler” (meine dich nicht persönlich) selbst schuld, denn ich kann ich die stimmen noch hören die da rufen ” Meldet Fehler, meldet Fehler …”, nur dann wird freie Software besser und stabiler. Also, was machen die meisten …. die kritzeln alles hin und glauben die helfen dabei.
Für beide Seiten nicht erfüllend dieser Zustand, das kann jeder nachvollziehen.
Vielleicht sollten Bugtracker nur für Entwickler, Bastler bzw jene freigeschaltete User die nachweislich in der Lage sind einen Bugtracker vernünftig zu bedienen offen sein, für alle anderen ist der Laden zu!
Regeln kann man das in dem man ein Gremium bestehend aus betroffenen Entwickler ins Leben ruft und Turnusmäßig sich Leute anschaut, prüft und freischaltet bei denen man weiß das die den Bugtracker nicht zur Müllhalde machen.
Wer dennoch Wünsche, Ideen und anderes hat, kann sich auch direkt über entsprechende Listen, Foren etc wenden wo diese Gehör und ggf Berücksichtigung finden werden.
Nur so kann man der Lage Herr werden, anders wird das nichts.
Grüße aus dem Land’le
Sicher hast du recht. Aber teilweise sind die Entwickler auch Mitschuld. Hier mal ein paar Erfahrungen, wie auf Bugreports reagiert wird. Ich bin übrigens Programmierer und kann mich gut auf Englisch ausdrücken, daran kann es also nicht liegen.
Habe detaillierte Bugreports (auf englisch) geschrieben (nicht KDE) und bekam monatelang keine Antwort. Nach einem halben Jahr dann wurde gefragt, ob der Bug denn immer noch auftrete.
Habe in der Zwischenzeit ein anderes Programm verwendet und als test nochmals versucht. Ja, er war immer noch da, was ich gemeldet hatte und es ging wieder nichts mehr.
Ein anderes Mal melde ich einen Bug und als Antwort werde ich nach einem Detail gefragt, das bereits im Bugreport stand. Da hat jemand den Bugreport nicht sorgfältig gelesen.
Habe auch schon fixes und workarounds geliefert. Teilweise wurden sie sofort eingebaut, teilweise wurde darauf gar nicht geantwortet.
Dies nur ein paar Beispiele. Hatte viele ähnliche Reaktionen von Xorg, Gnu, Debian, Ubuntu und auch kleineren Projekten.
was du beschreibst, klingt für mich alles nach typischen Taktiken mit dem Problem der zu vielen Bugs umzugehen. Ich persönlich versuche jeden Bug zu lesen und Rückmeldung zu geben.
Für mich war der erwähnte Bug Nr. 265051 der letzte Sargnagel an KDE; mit Ubuntu Natty bin ich mit xubuntu unterwegs; und bisher sehr zufrieden.
Und die Lösung dafür besteht jetzt darin, den Bugtracker zu schließen?
“Kein einziger Wunsch der Nutzer deckt sich mit den Entwicklungszielen, die ich habe.”
Bin ich jetzt gnome gelandet?
es erscheint mir etwas irrational wegen einem bug den desktop zu wechseln. Wenn für dich xfce besser ist, dann ist das auch gut so.
bei angesprochenem bug bin ich doch sehr über die User überrascht. Fehler passieren – das ist normal. Zu erwarten, dass die Entwickler den eigenen Lieblingsbug sofort beheben ist etwas naiv. Schaue ich die Liste der Leute an, die in den Bug kommentiert haben, erkenne ich nur einen Entwickler und dessen zweiter Bildschirm war zu dem Zeitpunkt irgendwo im Container auf dem Atlantik. es hätte vllt. wirklich geholfen in dem report freundlich zu bleiben, so dass andere Entwickler ihn sich auch anschauen. Wir haben genügend offene Bugs um uns nicht anschimpfen zu lassen.
Mir ist jetzt nicht so ganz klar was du damit sagen willst. Ich vermute mal du meinst wir müssen alle Userwünsche implementieren, denn alles andere ist “gnome”. Ich empfehle dir mal Gedanken dazu zu machen warum Entwickler Nutzer mit solch einer Meinung ignorieren. Die gnome Entwickler sind da bereits bedeutend weiter.
Hallo Martin,
du hast in diesem Beitrag wieder sehr gut zum Ausdruck gebracht, dass es eben einen ganz großen Unterschied macht, ob man nun Anwender oder Entwickler ist. Ich bin Anwender.
Ein Anwender erwartet, dass alles läuft und wenn etwas nicht läuft, dass es eben gefixt wird. Und gerade wenn eine solche grundlegende Funktion wie die Verwendung von mehreren Bildschirmen nicht mehr einwandfrei funktioniert, dann darf niemand von einem Anwender erwarten, dass er ganz lieb und brav Wochen oder Monate wartet, bis es gefixt ist. Das ist eben die Diskrepanz zwischen Anwendern und Entwicklern. Ein Entwickler versteht (des öfteren) die Anwender nicht und ein Anwender versteht (in aller Regel) die Entwickler nicht.
Du und alle anderen KDE-Entwickler leisten hervorragende Arbeit und das auch noch in eurer Freizeit und größtenteils unentgeltlich bzw. nur mittels Spenden, aber trotzdem darf doch wohl Kritik erlaubt sein, oder?
Aber es ist natürlich auch klar, dass ihr euch beleidigt und/oder in eurer Ehre gekränkt fühlt, wenn Anwender aufgrund eines nervigen Bugs auf die Barrikaden gehen (wie es in dem angesprochenen Bug-Report passiert ist). Aber ich denke, dass ihr einfach über den Dingen stehen solltet und sich solche Sachen nicht zu Herzen nehmen solltet.
Um jetzt mal wieder zurück zum eigentlichen Thema zu kommen, denke ich, dass ihr den Bug-Tracker zumindest dahingehend verändern solltet, dass man keine Kommentare zu einem Bug-Report mehr öffentlich einsehen kann. Oder vielleicht wäre es auch besser, die Kommentarfunktion komplett zu deaktivieren. Wenn ein Entwickler Rückfragen zu dem Schreiber des Bug-Reports hat, dann kann die ganze Sache ja auch per email geschehen. Dadurch hättet ihr mehr Ruhe, weil nicht laufend jemand einen Bug kommentiert und z.B. nachfragt, wann denn dieser geschlossen wird.
angesichts der Tatsache, dass KDE nur einmal im Monat ein Release hat: ja da muss ein Anwender ganz lieb und brav Warten bis der Bug gefixt ist.
Konstruktive Kritik ist immer erlaubt und erwünscht. Destruktive Kritik hilft aber nicht weiter.
Ach mir sind solche Bugs egal. Am Ende schaden sich die Nutzer nur selbst, denn bei mir werden solche bugs dann schön ignoriert. Wenn ein User schreit, kann er sicher sein, dass ich nicht hinrenne und den Bug sofort behebe. Pech für die Nutzer – ihr Problem.
Hallo,
ich schrieb “vom letzten Sargnagel”. Es gibt noch so ein paar andere kleine Bugs die mich genervt haben; es liegt aber auch daran, dass ich Lotus Notes benutze und die “notification area” von KDE damit nicht zurechtkommt (vermutlich eher umgekehrt; aber Notes wird hier vermutlich niemals nicht gefixt werden).
Tools wie k3b oder kjots werde ich weiterhin benutzen, weil sie einfach unschlagbar sind … aber für die etlichen kleinen “Nervigkeiten” sehe ich es einfach nicht mehr ein, nach dem Login fast ne Minute zu warten, bis ich was tun kann (xubuntu ist da gefühlt dreimal so schnell).
Bezüglich des erwähnten Bugs:
– niemand erwartet, dass ein Bug sofort gefixt wird
– aber es nervt, wenn solche Bugs mit minor updates reinkommen … und dann scheinbar über Monate hinweg nichts passiert
Ansonsten verweise ich auf Kommentar #39 in diesem Bug … da ist ein User, der sich wirklich VIEL Mühe gibt, zur Qualität von KDE beizutragen. Sichtbare Ergebnisse für ihn … anscheinend 0. Und Du wunderst Dich noch, dass die Leute die Lust an KDE verlieren?
Mit meinem Hinweis auf gnome habe ich auf CADT angespielt:
http://www.jwz.org/doc/cadt.html
Früher war es für mich undenkbar KDE im gleichen Atemzug zu nennen.
Früher eben …
hab ich mich im bug geirrt oder wechselst du tatsächlich wegen einem nicht automatisch maximierendem panel den desktop?
da wärs doch einfacher gewesen ein kleines script zu schreiben, dass erkennt welcher monitor angesteckt ist und demensprechend die nötige .rc file ersetzt.. (oder irgendeinanderer workaround bis das gefixed ist)
falls du xrandr nutzt zb. könntest du dein problem mit einem einfache “cp” an der richtigen stelle im script in den griff kriegen…
http://flexible.xapient.net/?p=352
Ich habe eine Zeit lang auch mal Bugreports geschrieben(Weiß nicht mehr für welche Programme das war…). Habs dann aber sein gelassen, den wenn ich nach 4 Monaten angeschrieben werden von einem Entwickler, das er doch gerne mehr Infos oder ein Log dazu haben möchte, dann frage ich mich wie weit entfernt diese von der Realität sind!?! Das Problem sind nicht die Bugtracker an sich, sondern einfach die Tatsache das die Projekte einfach zu wenig Personal haben um diese zu verwalten! Das Ziel sollte es also vor allem sein mehr Leute für das Projekt zu gewinnen und mehr Leute an mit der Pflege der Bugtracker zu beauftragen!
Ich bin in meiner Freizeit ein bisschen in einem Subprojekt von Drupal: Views dabei. Wir hatten bisher ~13k Issues, dabei haben wir folgendes durchgesetzt:
* Issues “dürfen” nur erstellt werden, wenn genügend Informationen vorhanden sind. Sonst werden sie auf “postponed(needs more info)” gesetzt. Falls sie es nicht aktualisieren wird es als fixed angesehen.
Dies ist generell weniger das Problem, denn wenn es ein wirklicher Bug ist, wird der benutzer zurückkommen, falls nicht wird es nach einer bestimmten Zeit geschlossen.
* Ein Bug Squad Team hilft Issues zu “farmen”. Man kann Benutzer damit motivieren zu helfen, indem man ihnen aktiv sagt, … jede Zeit die du aufbringst, können wir direkt zu neuen Featuren/Bugs verwenden.
Natürlich ist es von Vorteil, dass Leute Drupal für ihre Arbeit verwenden und so motiviert sind und es andere Fehlerquellen gibt, die nicht so schlimm sind wie Grafikkarten.
Vielleicht kann man es schaffen soetwas wie ein Bug Squad Team zu haben. Wichtig ist: Es können normale Benutzer sein.
Hat KDE ja auch – auch mit regelmäßigen Aufrufen zu gezielten Bugdays. Aber ohne viel Erfolg – leider.
Dieser Artikel hat mich ehrlich gesagt etwas erschreckt. Es ist nicht einmal so sehr der Inhalt, das Problem kann ich durchaus nachvollziehen. Es ist vielmehr die Haltung, die darin zum Ausdruck kommt.
Das Problem ist meines Erachtens nicht, dass der Bugtracker zumüllt und Fehlerberichte nicht vollständig sind. Das sind auch Probleme, aber die liegen nicht im Kern dessen, was Du hier beschreibst. Der Kern scheint mir vielmehr zu sein, dass Du überhaupt kein Interesse an Rückmeldung hast. Du behebst die Fehler, die Dir selbst auffallen, und Du implementierst die Neuerungen, die Du für nützlich hältst. Mit anderen – Deinen – Worten: „Es gibt keine Wünsche der Nutzer, die sich mit meinen Entwicklungszielen überschneiden.“
Dieses Problem kann kein Bugtracker der Welt lösen. Ich kann mir durchaus vorstellen, dass bei relativ technischen Komponenten wie KWin die Berührungspunkte zwischen Anwendern und Entwicklern besonders niedrig sind. Aber dann musst Du einfach ehrlich genug sein und KWin generell aus dem KDE-Bugtracker nehmen. Feedback zu erlauben, dass man ohnehin nicht hören will, ist für beide Seiten frustierend.
Jenseits dessen finde ich es aber ziemlich forsch, Dein Problem gleich als „die Bugtracker Lüge“ der gesamten Open-Source-Welt zu bezeichnen. Es gibt viele Projekte, die durchaus für Bugreports dankbar sind. Manche sogar für Feature Requests (dazu würde ich meine eigenen zählen, auch wenn ich natürlich nicht alle Wünsche auch implementiere). Es gibt auch viele Projekte, bei denen das Bugtracking funktioniert. Und es gibt für einige der angesprochenen Schwierigkeiten auch durchaus technische Lösungsansätze (die “expiry” von unvollständigen Reports in Launchpad ist ja schon angesprochen worden).
Von daher: Mache Dein Problem nicht zu dem der anderen.
“Der Kern scheint mir vielmehr zu sein, dass Du überhaupt kein Interesse an Rückmeldung hast.”
Komisch, also ich konnte das aus dem Artikel nicht herauslesen. Ganz im Gegenteil hatte ich von Martin bisher immer das Gefühl gehabt dass er sehr wohl Interesse an Rückmeldungen hat. Er hat ja selbst gesagt dass er versucht sich jede Bug-Meldung anzusehen.
Dass er die Ideen und Wünsche der Nutzer nicht aufnehmen kann/will, ist eine Entscheidung die ihm frei steht. Ich kann mir sehr gut Vorstellen dass ihm von seiner spärlichen Freizeit, die er an der KDE-Entwicklung verbringt, keine Zeit für Wünsche der Nutzer übrig bleibt.
Ich finde hierbei kommt es sehr stark darauf an, wie gut der Bugtracker ist. Ich finde nicht, dass so etwas generell nicht funktionieren kann.
Hier muss ich auch nochmal auf das schon oft erwähnte Launchpad von Canonical hinweisen.
Hier macht es richtig Spaß Bugs zu reporten und auch(und das ist noch viel wichtiger) danach zu suchen. Die Suche für eventuell schon bestehende Bug-Reports ist dort einfach nur genial. Ich gebe einfach nur meinen Titel ein, den ich für diesen Bug wählen würde und Launchpad sucht danach automatisch nach eventuell schon bestehenden Bugs mit dem gleichen Inhalt. Man kommt überhaupt nicht um die Duplikatsuche herum, außer man ignoriert einfach böse die vorgeschlagenden Bugs.
Auch die automatischen BugReports, die Apport erstellt haben einen Namen, der dann in die Duplikatssuche wandert und dort findet die Erkennung dann den schon gemeldeten Bug(der logischerweise den exakt gleichen Titel hat) und man muss nur noch auf “ja den will ich auch melden” klicken. Das könnte sogar meine Freundin. Auch wenn Sie keine Bugs reportet. Und das bringt mich zu dem zweiten Thema.
Nicht alle Benutzer melden Bugs und “vermüllen” damit den Buggtracker. Ich habe die Erfahrung gemacht(natürlich nicht in so großen Projekten), dass nur einigermaßen versierte Anwender sich überhaupt die “Mühe” machen etwas zu reporten und dann meistens auch Antworten auf eventuelle Rückfragen geben können.
Also eventuell solltet Ihr einfach mal überprüfen, ob eure Bug/Wunsch Platform nicht einfach zu kompliziert ist und dann ggf. wechseln.
Launchpad ist übrigens AGPL und frei zum Download verfügbar:
https://dev.launchpad.net/
Grüße
Felix
alles was du aufzählst kann bugzilla natürlich auch – vieles sogar bedeutend besser und ich persönlich finde die Launchpad Suche eher eine Krankheit als ein nützliches Tool.
Viele Bug-Reports sind Müll. Stimmt, das ist ein Problem. Aber für den Grund, dass überhaupt so viele Bugs und Feature Requests geöffnet werden, habe ich eine ganz andere These.
“Jeder, der die Entwicklung von KDE Software über die letzten Jahre verfolgt hat, wird mir zustimmen dass die Qualität unglaublich gestiegen ist und nicht gesunken ist.”
Das kommt auf den Vergleichszeitpunkt an. Verglichen mit der KDE 4.0 ist die 4.6 hervorragend. Aber die Qualität aus meiner (Anwender)-Sicht ist noch Lichtjahre von der 3.5.10 entfernt. Mir sind stylisches Aussehen, 3D-Effekte und “revolutionäre” Bedienkonzepte nämlich völlig schnuppe. Eine Desktop-Umgebung hat IMHO den Anwender primär dabei zu unterstützen, die Programme zu starten und zu verwalten, wegen derer man den PC überhaupt anschaltet. Außerdem hat die Desktop-Umgebung wichtige Informationen (Systemauslastung, Uhrzeit, auf welcher Arbeitsfläche befinde ich mich gerade…) so bereitzustellen, dass man sie mit einem kurzen Blick “aus dem Augenwinkel” erfassen kann. Und schließlich muss sie sich so gut konfigurieren lassen, dass sie möglichst nicht im Weg ist. Form follows funktion nennt man sowas.
Ich bin seit KDE1.0 begeisterter KDE-Nutzer und bis einschließlich KDE3.5.10 wurde KDE mit jeder Release besser hinsichtlich meiner Anforderungen. Dann kam KDE4.0 und damit ein gewaltiger Schock. Ich habe mich zurückgehalten, aber ich kann die Leute verstehen, die seitdem frustriert die Bugtracker zuballern. Die Gnome-Leute werden mit der 3er Release wohl die gleiche Erfahrung machen müssen.
Andererseits kann ich Euch Entwickler auch verstehen, dass Ihr mal neue Sachen machen wollt. Aber die “alten” Nutzer, die Jahrelang zufrieden und deshalb still waren, sind dann eben nicht mehr ruhig, wenn neue Konzepte keinen erkennbaren Mehrwert haben. So gab es kürzlich im guten alten Usenet (dcouak) eine Diskusion zu Aktivitäten und der allgemeine Tenor war, dass sich niemand ein sinnvolles Anwendungsszenario dafür vorstellen konnte, da im Vergleich zu den klassischen Arbeitsflächen zu umständlich.
Jedenfalls macht mir die momentane Situation richtig Angst. KDE4 hat den Weg begonnen, der jetzt mit Gnome3 weitergegangen wird: weg von “form follows function” hin zu “Generation Facebook”. Möglicherweise werden dadurch einige neue Nutzer angezogen, aber dann müsste die KDE besser funktionieren als sie es jetzt tut (siehe den sehr ärgerlichen Multi-Monitor-Bug…). Nutzer, die eine Desktop-Umgebung nicht als Selbstzweck sehen, sondern mit dem PC arbeiten wollen und der hervorragenden Konfigurierbarkeit wegen auf Linux und KDE gesetzt haben, werden von diesem Trend verprellt. Dummerweise sehe ich die Fähigkeit, gute Bugreports zu erstellen und evtl. mit zu entwickeln, eher in der zweiten Gruppe…
Grüße
Matze
Die Anforderungen an eine Desktopumgebung haben sich klar verändert. Du bist seit KDE 1 dabei, ich selbst erst seit KDE 3 und Entwickler seit KDE 4. Ziele, Nutzer und Entwickler von KDE 1 entsprechen nicht mehr dem was man heute hat. Damit sollte man sich einfach abfinden. KDE öffnet sich genauso wie die anderen Desktops für den normalen Anwender, der nicht Informatik studiert hat. Wenn du weiterhin einen Desktop willst, der nur von Informatikern bedient werden kann (wie KDE 1), dann kann dir wohl weder KDE, noch GNOME noch XFCE noch Unity eine Heimat bieten.
Wir bekommen auch nicht Bugreports von verärgerten Altnutzern, sondern eher von den neuen “normalen” Nutzern.
“Die Anforderungen an eine Desktopumgebung haben sich klar verändert.”
Wenn das so klar ist, könntest Du das bitte mal kurz erläutern? Also die Fakten, die zu meinen oben beschriebenen Anforderungen NICHT passen?
“Wenn du weiterhin einen Desktop willst, der nur von Informatikern bedient werden kann (wie KDE 1), dann kann dir wohl weder KDE, noch GNOME noch XFCE noch Unity eine Heimat bieten.”
Also ich fand KDE1 im Vergleich zur 4 wesentlich intuitiver bedienbar. Die Aussage, dass der nur von Informatikern bedienbar war, ist schlicht Bullshit! Gut, die KDE1 konnte auch viel weniger. Aber mal einen Vergleich zur KDE3: Im Panel konnte man die Icons frei bewegen, in der 4 muss man mit Spacern arbeiten, wenn man die Icons aus Ergonomiegründen etwas gruppieren will. Also ein “Normalnutzer” wird DAS nicht so schnell begreifen. Es dauert außerdem länger. Und das ist der Trend, der mir nicht schmeckt. Um das selbe Ziel zu erreichen, braucht man mehr Mauswege, mehr Klicks, mehr Zeit.
Was ist den Deiner Meinung nach erforderlich, um mehr Normalnutzer zu ereichen?
Matze
Ja wenn man mal die Linux Installation geschafft hat, dann war es bestimmt benutzbar.
Ein Normalnutzer wird niemals auch nur denken, dass man die Icons verschieben können soll. Ein Normalnutzer denkt nicht so weit! Das was du dir als Normalnutzer vorstellst, sind Powernutzer, wie du. Und für dich haben wir immer noch eine Möglichkeit ohne den Normalnutzer zu verwirren. Außerdem konfiguriert man das Panel einmal. Ich kann dieses lächerliche Argument nicht mehr hören. Verbesserungen in der Benutzung sind wichtig, aber bitte dort wo es Nutzer gibt und nicht bei einer Tätigkeit die man einmal vllt. im halben Jahr ausführt. Egal wie gut man es macht, man wird es dann eh nicht wissen.
Hallo Martin,
schade, dass Du auf die Frage, was denn die “klar veränderten Anforderungen an einen Desktop” sind, nicht eingegangen bist. Das hätte mich wirklich interessiert.
“Und für dich haben wir immer noch eine Möglichkeit ohne den Normalnutzer zu verwirren.”
Was ist an “Knopf verschieben” im Kontextmenü verwirrend bzw. was ist an einem Kontextmenü an sich verwirrend?
“Außerdem konfiguriert man das Panel einmal.”
Das stimmt allerdings. Das war auch nur ein Beispiel von IMHO vielen Kleinigkeiten, die in der 4er unergonomischer geworden sind bzw. mehr Mauswege und Klicks erfordern, jeweils verglichen mit 3.5.
“Ich kann dieses lächerliche Argument nicht mehr hören.”
Vielleicht mag Dir das lächerlich erscheinen. Aber “Poweruser”, wie ich es wohl bin, waren bislang Eure treue Nutzerbasis. Ich habe drei “Normalnutzern” KDE3 installiert und die waren damit glücklich, bis der Support für die Distribution ausgelaufen ist. Von sich aus hätten die das nie probiert. Aber das KDE-Projekt hat mich als Multiplikator momentan verloren und die drei besagten Leute arbeiten jetzt mit Gnome2.
Jedenfalls könnte ich solchen Leuten den Sinn und Zweck von “Aktivitäten” nicht beibringen. Den habe ich ja selbst nicht durchschaut, aber ich bin ja auch alt und reaktionär…
Wie Ihr eine größere Nutzerbasis erreichen wollt, ist mir allerdings schleierhaft. Der “Normalnutzer” wird niemals ohne Grund das auf seiner Kiste vorinstallierte Windows runterwerfen, warum auch?
Matze
@Mathias:
ich selbst habe auch als poweruser noch kein szenario erdacht in dem ich activities brauchen würde und nutze dieses feature daher einfach nicht (nachdem man einzelne desktops mit eigenen widgetssets und backgrounds zupflastern kann reicht mir das konzept der multiple desktops vollauf)
zum glück ist das feature aber sehr einfach zu ignorieren und stört überhaupt nicht… genauso wird es “solchen Leuten” wohl egal sein können dass ihre software mehr kann als sie benötigen.
die panel konfiguration finde ich im übrigen sehr gut gelöst und keinen deut schlechter als die von kde 3.5 (den ich auch sehr geschätzt habe, aber keine träne nachweine)