![]() Registered Member ![]()
|
After revisiting my aging list of (still) open KDE bugs/wishes (some of which remain UNCONFIRMED in the bug database after years) and after attempting to voice related concerns as a user within a bug thread and being swiftly chastised for it, I've concluded that there seems to be a serious problem with the KDE support model. There are countless bugs/feature requests in the system that linger indefinitely with developers taking no apparent interest in resolving them.
One perceived attitude (perhaps only by me) from developers (and God love them for all their efforts), is the notion that if you really want it fixed, fix it yourself. We'll fix what we want when we can. Problem IMO is that it's exactly this attitude (perceived or real) and, more importantly, a closely related inattention to the finer detail in KDE (and other OSS projects) that, not only leaves familiar users frustrated, but firmly re-enforces the perception among many outsiders of Linux/KDE as seriously UNPOLISHED and a non-contender. KDE has set the Linux desktop standard from the beginning, yet many prominent distributions have either shifted from KDE to GNOME or simply not adopted KDE as their default desktop. Maybe it's the user experience, not only with the product itself, but with the support model. Being totally unfamiliar with GNOME, I have no idea. But there's something. We KDE zealots tend to pound our chests and grunt heartily at our accomplishments and deceive ourselves into believing our own propaganda - that ours is the biggest, baddest and bestest of them all. All the while ignoring the very real fact that the average computer user has absolutely no clue as to what KDE is, and many who have experienced it (and other Linux desktops) quickly run back to familiar Windows territory for the very reasons I'm espousing here. Perhaps what the KDE support/bug management model needs is a Usability Committee of its own to which bugs/feature requests can be submitted and weighed in the context of the much broader user experience (usability and polish) AND who would campaign heavily and appropriately for resolution from developers. The present model seems to leave priority assessment and bug assignment to the development community itself mainly, with minor influence from users through a voting mechanism. I'm arguing that this isn't really working well. At least as it relates to tying up loose ends and addressing overall usability. And I'm not talking about obscure bugs/feature requests either, that few users would even notice. I'm really talking about those that would seriously influence KDE usability and presentation as a quality, highly polished product that tends toward the users' needs and away from the techies. Of course, it's quite possible that my lack of understanding (as a mere user) of the KDE support model has misled me. Perhaps this very committee already exists. If so, it's not evident to me. And I know I'm not the only one who has reported valid bugs/wishes that would tie up loose ends and bring real polish to the product, yet which go completely unattended for years. Here are a couple simple examples (probably not the best). I'm sure there are countless others. KWalletManager: A very good idea/product. Integrated tightly and nicely into KDE. Yet IMO it's very hard for non-techies to manage and understand. It allows one, for example, to exclude web sites from inclusion in the wallet, but provides no clear means to reverse that decision later. A minor problem for a techie who can Google/grep/find/awk their way to a solution. A HUGE problem for Grandma. At least two bugs have been open on this issue for nigh on three years now. Yet the bugs are still unassigned - and it's still broken. KMail: Sending email from outside KMail (e.g. from konqueror, digikam, etc.) provides no progress bar. Consequently, it's highly possible for messages in progress to be inadvertently interrupted by user logout, shutdown, etc. Especially for slow Internet connections. Again - open for many years with absolutely no attention or apparent interest from developers. I understand fully that there is a never ending flood of bug fix and enhancement needs keeping developers ever so busy (and generally with no compensation other than their own personal gratification) and that most developers genuinely want to address user concerns and they strive heavily toward that goal. Yet, if often seems - the hurrier we go, the behinder we get. And we never seem to break through the "perpetual beta" perception complex. Maybe we need a serious review and restructure of the existing KDE support model.
Last edited by fcwells59 on Sun Dec 07, 2008 9:46 pm, edited 1 time in total.
fcwells59, proud to be a member of KDE forums since 2008-Dec.
|
![]() Mentor ![]()
|
One problem is that there are too many bug reports. A good new idea are the Bug days from the Bug squad on techbase.kde.org. On a day, or sometimes a week, all bugs should be further investigated and categorized. After this, it is easier for the devs to handle them. Some bugs do not occur on all machines and are depending on distros or other conditions. Because KDE is a community project, the user should also help in further investigating the bugs and help for example on the bug days.
For example now it is feature freeze and we devs are heavily working on bug fixing. But there are many bugs which arise from the latest feature implementations. It could also be that bugs.kde.org is not optimal. But changing such a central component could always be a risk. Cheers, m ![]() [size=x-small]code | [url=cia.vc/stats/author/msoeken]cia.vc[/url] | [url=kde.org/support]donating KDE[/url] | [url=tinyurl.com/cto4ns]wishlist[/url][/size] |
![]() Registered Member ![]()
|
No doubt devs are working as feverishly to address the relentless flow of bugs and feature requests as time will allow. My hat is off to ALL developers who volunteer their time and skills to the KDE community. KDE obviously doesn't exist without them. And quite an accomplishment it is and has always been.
But, that's really not my point. Although, you do bring up a good point of your own - that there are too many bug reports. My question is - who's reviewing them, categorizing and prioritizing them, and ensuring that they receive appropriate attention? I'm not suggesting that nobody is, just posing the question. And is the current model yielding the desired results? From my view, as a very long time and highly committed KDE user, focus isn't entirely where it should be under the current model. How else do you explain bugs/wishes lingering in the system for years without ANY attention at all from devs. Not even an acknowledgment back to the reporter. Instead, Nada! Nill! Nothing! And I'm sure it's not for lack of interest from developers in general. I'm saying that the desire may be there, but the model isn't supporting it as well as it should. I'm also not suggesting that the current model is entirely broken. Rather, I think what I'm suggesting is the creation, within the existing support structure, of a Usability body whose sole purpose is to receive/monitor those bugs/requests related specifically to usability and general product polish, continuity and *reception/perception*; to weigh their merits and influence prioritization and the assignment of resources; and to ensure timely resolution. In essence, to help bring focus specifically to these areas. IMO, KDE seems always just on the edge of a fantastic breakthrough, but never actually achieves it. KDE is an awesome community project with a huge community following, but I'm afraid without some changes it'll remain just that indefinitely, never really breaking into the mainstream.
fcwells59, proud to be a member of KDE forums since 2008-Dec.
|
![]() Registered Member ![]()
|
Opensource is usually about 'put your money where your mouth is'
So if you would like to see a better bug handling, you could startup a sort of project that reviews bugs on bugs.kde.org, and addresses them.
Riinse, proud to be a member of KDE forums since 2008-Oct.
|
![]() Registered Member ![]()
|
I could. And I'm not opposed to being an active contributor to such a project. But, such an effort will take a commitment from the larger KDE support community as well, mainly because it can't happen from without. Gotta happen from within.
Also, at the risk of initiating a totally unrelated and heated exchange over how the Open Source model works, doesn't work or should work (which is definitely NOT my intent), the "put your money where your mouth is" interpretation (while prevalent) IMO is inaccurate and definitely does the movement an injustice. It basically demands that only viable contributors have a voice. I hope that's not where KDE is going. ![]() The intent of this thread is simply to open up discussion on the topic and feel out the community. Maybe, in the end, I'll do exactly as you suggest.
fcwells59, proud to be a member of KDE forums since 2008-Dec.
|
![]() Registered Member ![]()
|
(Repost from Developer Forum)
After revisiting my aging list of (still) open KDE bugs/wishes (some of which remain UNCONFIRMED in the bug database after years) and after attempting to voice related concerns as a user within a bug thread and being swiftly chastised for it, I've concluded that there seems to be a serious problem with the KDE support model. There are countless bugs/feature requests in the system that linger indefinitely with developers taking no apparent interest in resolving them. One perceived attitude (perhaps only by me) from developers (and God love them for all their efforts), is the notion that if you really want it fixed, fix it yourself. We'll fix what we want when we can. Problem IMO is that it's exactly this attitude (perceived or real) and, more importantly, a closely related inattention to the finer detail in KDE (and other OSS projects) that, not only leaves familiar users frustrated, but firmly re-enforces the perception among many outsiders of Linux/KDE as seriously UNPOLISHED and a non-contender. KDE has set the Linux desktop standard from the beginning, yet many prominent distributions have either shifted from KDE to GNOME or simply not adopted KDE as their default desktop. Maybe it's the user experience, not only with the product itself, but with the support model. Being totally unfamiliar with GNOME, I have no idea. But there's something. We KDE zealots tend to pound our chests and grunt heartily at our accomplishments and deceive ourselves into believing our own propaganda - that ours is the biggest, baddest and bestest of them all. All the while ignoring the very real fact that the average computer user has absolutely no clue as to what KDE is, and many who have experienced it (and other Linux desktops) quickly run back to familiar Windows territory for the very reasons I'm espousing here. Perhaps what the KDE support/bug management model needs is a Usability Committee of its own to which bugs/feature requests can be submitted and weighed in the context of the much broader user experience (usability and polish) AND who would campaign heavily and appropriately for resolution from developers. The present model seems to leave priority assessment and bug assignment to the development community itself mainly, with minor influence from users through a voting mechanism. I'm arguing that this isn't really working well. At least as it relates to tying up loose ends and addressing overall usability. And I'm not talking about obscure bugs/feature requests either, that few users would even notice. I'm really talking about those that would seriously influence KDE usability and presentation as a quality, highly polished product that tends toward the users' needs and away from the techies. Of course, it's quite possible that my lack of understanding (as a mere user) of the KDE support model has misled me. Perhaps this very committee already exists. If so, it's not evident to me. And I know I'm not the only one who has reported valid bugs/wishes that would tie up loose ends and bring real polish to the product, yet which go completely unattended for years. Here are a couple simple examples (probably not the best). I'm sure there are countless others. KWalletManager: A very good idea/product. Integrated tightly and nicely into KDE. Yet IMO it's very hard for non-techies to manage and understand. It allows one, for example, to exclude web sites from inclusion in the wallet, but provides no clear means to reverse that decision later. A minor problem for a techie who can Google/grep/find/awk their way to a solution. A HUGE problem for Grandma. At least two bugs have been open on this issue for nigh on three years now. Yet the bugs are still unassigned - and it's still broken. KMail: Sending email from outside KMail (e.g. from konqueror, digikam, etc.) provides no progress bar. Consequently, it's highly possible for messages in progress to be inadvertently interrupted by user logout, shutdown, etc. Especially for slow Internet connections. Again - open for many years with absolutely no attention or apparent interest from developers. I understand fully that there is a never ending flood of bug fix and enhancement needs keeping developers ever so busy (and generally with no compensation other than their own personal gratification) and that most developers genuinely want to address user concerns and they strive heavily toward that goal. Yet, if often seems - the hurrier we go, the behinder we get. And we never seem to break through the "perpetual beta" perception complex. Maybe we need a serious review and restructure of the existing KDE support model.
fcwells59, proud to be a member of KDE forums since 2008-Dec.
|
![]() Registered Member ![]()
|
While I hope to get some active discussion from developers on this, I also want to include users in the dialog. Thus, I'm moving this thread to the Users forum.
fcwells59, proud to be a member of KDE forums since 2008-Dec.
|
![]() KDE Developer ![]()
|
On average there are more bugs and wishes being opened than closed every single day. As there is just not enough developer time to fix or implement them all of course some reports will never be closed.
As a Free Software team KDE faces the exact same problems as all others: Not enough developers. |
![]() Administrator ![]()
|
@fcwells59: Instead of reposting in the Users forum, perhaps you could just PM a Super Moderator / Administrator and ask them to move the thread nicely. We don't bite
![]()
Last edited by bcooksley on Mon Dec 08, 2008 12:08 pm, edited 1 time in total.
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
![]() KDE Developer ![]()
|
anda_skoa, proud to be a member of KDE forums since 2008-Oct.
|
![]() Mentor ![]()
|
Yes, this was the project I mentioned in my first reply. But there are perhaps two problems. The Bugsquad team seems not to be known so good, though there are news in the dot often. And the other thing is the responsibility of the users. I could imaging that there were many discussions, but it has to be more easy to report a bug for a user. If you browse through bko, there are many bugs which are nearly useless because of lack of informations. And I think it would be great if there were more users active in helping the Bugsquad team. You do not need much technical skills for that, just a little bit of time to read some bug reports, check and try to reproduce them on your system and categorize them on techbase.kde.org. This would be a lot of help. ![]() [size=x-small]code | [url=cia.vc/stats/author/msoeken]cia.vc[/url] | [url=kde.org/support]donating KDE[/url] | [url=tinyurl.com/cto4ns]wishlist[/url][/size] |
![]() Registered Member ![]()
|
bcooksley - Thanks for merging these threads.
![]() anda_skoa & moeken - The bug squad approach is a good one that should continue. But it's ad-hoc and infrequent. And, as such, IMO doesn't really draw and hold proper attention to KDE usability, reception and perception.
fcwells59, proud to be a member of KDE forums since 2008-Dec.
|
![]() Registered Member ![]()
|
thx a lot for the hint with the bug squad.. next bug day i'm on board...
Kubuntu 12.04 x64 | KDE SC 4.8
Nvidia 8800 GTS | Core2Duo E6600 | 4 GB RAM |
![]() Registered Member ![]()
|
Every day is a bug day! You can participate any time. It could get some more publicity. Let's see... / |
![]() Registered Member ![]()
|
It's all about putting priorities onto issues. Not everything can be fixed but if there are things that affect a large scale of users, then it's very likely that a developer will fix it if he/she knows about it.
My proposal; try to grep those things out that have a high priority, attach a proposal to the bugreport how that can be improved (if that's not already the case) and let developers know about them. The later could be done by e.g. writing a mail to the KDE usuability mailinglist. |
Registered users: Bing [Bot], Evergrowing, Google [Bot]