Christian, you pose the issue that if we assign trust based on historical performance and skill set of the reporters that we will overlook bug reports by others.
and then you say that we need to find triagers, because that's the only solution. well, good freakin' luck. to state it bluntly: i hope you can find a large chunk of money that someone is willing spend not on new development, not on marketing, not on visual appearance and not even on fixing bugs but on reading, verifying and categorizing bugs in kde. let me pause for a moment while i laugh my ass off.
professional bug triage efforts do not come from the "volunteer" part of the community. we've pretty much proven that much. we're good at fixing bugs, we're good at finding bugs ... we suck at categorizing and organizing them.
continue to scream at the wind all you want, this is what we know based on repeated trials. so as to avoid the foolishness of ignoring data and repeating mistakes, i'm suggesting we need to improve the software we use to work with bug reports and change the processes by which we gather bugs. tom alber's thoughts on this are therefore, imho, much more useful.
now, if in your project it's mostly random users that bring the bugs in, then the software ought to let you note that. hell, you could simply read that "low trust level" list of bugs first. so rather than standing in your way, my suggested change actually makes it easier for you to find the demographic you are looking for too!
when it comes to kicker, kscd, kjots, etc... i can tell you it's exactly the opposite as kprinter, however.
and i'd like to see a lot more triaging happen within the OS vendors (most of whom are linux distributions) and have their bug reports float to the top since they are likely better researched, the result of user feedback, and often contain patches.
think about it.
Subscribe to:
Post Comments (Atom)
2 comments:
Mozilla seems to do all right, and I don't believe they have any paid workers doing bug triage (though I could be wrong).
It's very simple. Bug triaging takes a lot of time, effort and work and it is not very interesting unless some bugs are related to the more interesting work. It's a lot of dedicated work. That's the nature of open source development. So, the options are:
1. Try and encourage more people to do bug triaging and help out. That's already failed, as you've pointed out.
2. Spend some very unrealistic money that KDE doesn't have (venture capital money?) on employing people as full/part-time bug triagers and busters. That depends on how much money is riding on KDE out in the world for it to be realistic (like the Linux kernel), and at the moment, it just isn't.
3. Use the what computers and software are good at and make the software do the hard work. Outline a better bug tracking system, what you want out of it and try and make it more user centric so users can give much better feedback. Bugzilla is good at what it does, but it is time to look at the limitations.
Of the options, 3 is the most realistic. Also, as you've hinted, badger the living daylights out of other vendors, like Linspire and Xandros (and possibly even Suse), to get more involved with KDE and share the bugs and problems they have had. I would try and stress that point to Linspire, possibly at that Sandiego get-together. It's not doing KDE any good, and it's definitely not doing them any good because they're not finding out about KDE software, problems, pitfalls and gaining knowledge. I don't seen any Linspire or Xandros e-mail addresses around KDE and in bugzilla, and that's bad. They're effectively trying to do closed source development in-house, but using open source software and with limited resources. They simply cannot survive like that. KDE needs them, and they need KDE.
Post a Comment