Posted
by
michael
on Tuesday March 02, 2004 @04:30PM
from the quality-is-priority-1 dept.

Quique writes "The KDE Community is pleased to announce the launch of the Quality Team Project, a community of contributors who will serve as a gateway between developers and users in the KDE Project, and as a new way for people to begin contributing. KDE is a very attractive project, offering high quality software and is freely available. There is a lot of people who feel the urge to give something back, but stop in the middle of the way, frustrated by the steep learning curve. The aim of the project is to reduce these barriers by welcoming these potential contributors, and by offering documentation, support, and even guidance if requested. The objective is to support the new contributors, (programmers, documenters, testers, artists...). Have you ever wished to help KDE in some way, but never knew how? Keep reading!"

No, I think they should be called pet lamas. To ensure open-source quality.

I had this idea after reading Eric Raymond's "Luxury of Ignorance".

At absolute minimum all open-source projects should have (pet) lamas assigned to them, and a continuously rotating basis (to prevent tainting them with knowledge) and their whining should be taken as the word of authority...

Allow me to use Slashdot as an example. Wednesday nights = push development into production. Anyone on the slashteam want to tell me what regression testing tools and system testers they use? Sure, usually (not always) there isn't a crash-and-burn build, but occasionally there is annoyances and such that are just 'thrown into' the build that people didn't know was coming and other things.

Granted, this is Robs code, let him do what he wants with it, but with a 'QA' step it just makes for a better product.

QA is also something the US government requires for many things. Especially the military. If there is a good QA process in place that can help improve US government acceptance.

Being a 10 year veteran of QA/Testing and holding a CS degree, I have long wondered where QA would fit into OSS. And by "QA" I don't just mean testing, there is a lot more to it than that. Here are some topics that would need to be addressed:

What is the development process? Is it documented?

What types of estimation procedures do you do?

What is the SCM process? Is it documented?

What is the review/inspection process for all artifacts?

Are there software requirements? Are they inspected/reviewed?

Are there development plans/design docs? Are they inspected/reviewed?

Are there code reviews?

What are your defect escape rates?

What is your plan for alpha/beta testing?

What is your release schedule?

I think I could go on, but you get the idea. If you want solid, defect-finding, QA people who can improve your product, you'll be asked questions like these. If you just want someone who will run a few regression tests against your product before you put it on a website, then you are looking for some software testers. I am not saying that all of those things are necessary, but they might be. Maybe all of this stuff is archaic and applies only to the proprietary model, I don't know. I know that is what I have worked in for the last 10 years. I don't know if anyone has asked these questions of an OSS project, or done any research into if they need to be asked.

Bravo. As another long time veteran of Software QA and Change Management, I can say that I find both of those things lacking in most (not all) OSS projects that I've observed.

It has been my experience as well that people often confuse "testing for defects" with "quality assurance." The former is doing something to figure out if what you made (note the past tense) is ready for release. The latter is a process or set of processes that assures (or attempts to) that the output of your development cycle has quality. Testing is really only a phase of the entire quality assurance process.

I should point out that most of those topics are rather equivalent to just one:

Are we spending thirty times as many man-hours to develop this software as really required?

It's worse than that for FOSS, because the available total man-hours must be scaled by the funness of the task. Programming is more fun than debugging, which is itself more fun than reviewing requirement documents or measuring escaped defects. In paid work, testers are cheaper to hire than coders; but on a volunteer basis, testers can be harder to attract because the job is less emotionally rewarding.

But, always remember that in many Open Source efforts, the users are the testers. That's a valid viewpoint if something is free; Microsoft is excoriated when they periodically lure customers into paying to become testers, but the practice is more defensible when no money changes hands.

If you want solid, defect-finding, QA people who can improve your product, you'll be asked questions like these.

And yet, corporations that have an affirmative answer to everything you listed have still proven themselves fully capable of producing code that's absolute garbage. The public at large might not be aware of this, as the truely bad code dies before making it out the door. Someone who works in the industry will see veracity in the quote "Most software projects fail [ibm.com]".

Additionally, the themes of Superprogrammer vs The Horde" [indiana.edu] are relevant to understanding why. Having seen a few SEI CMM 5 shops in action, it's clear that to fill the man-hours for all the redudant tasks requires hiring a grade of developer that's frankly sub-par. Programming is the one field where a true 20x productivity differential between two professionals is unremarkable. It seems that the prominent Open Source projects have gotten more attention from generous SuperProgrammers than a typical commercial developement is able to attract.

But, always remember that in many Open Source efforts, the users are the testers. That's a valid viewpoint if something is free; Microsoft is excoriated when they periodically lure customers into paying to become testers, but the practice is more defensible when no money changes hands.

All of your points are of course valid - for the state of OSS today. I am more interested in the OSS of *tomorrow*. At least my hope for tomorrow - when OSS becomes more prevalent. How will QA/testing fit into OSS vs FOSS? When someone *IS* paying the bills, how will things change?

Additionally, the themes of Superprogrammer vs The Horde" are relevant to understanding why. Having seen a few SEI CMM 5 shops in action, it's clear that to fill the man-hours for all the redudant tasks requires hiring a grade of developer that's frankly sub-par. Programming is the one field where a true 20x productivity differential between two professionals is unremarkable. It seems that the prominent Open Source projects have gotten more attention from generous SuperProgrammers than a typical commercial developement is able to attract.

Of course. But those big projects have to ensure they can survive if their superstar programmer leaves. Or they do it because they are government regulated, or they are building software that could be life or death, and they can't afford to rely on someone's opinion. You have to remember that there is a LOT of software out there, it ain't all word processors and games. These are the applications where I question if open source is the way to go. I don't think it is the be-all-end-all of software development, just like being CMM level 5 isn't either. There is a reality out there, and I think Slashdot users could use a little check every now and then.

In general I'd say FOSS doesn't need any QA auditor role at all. That's for *large* corporations with huge projects and a bad tendency to push releases out to the buying public before they are ready... sort of a checks-and-balance system to mitigate management stupidity.

FOSS tend to be small groups, with small projects. And there is no insane pressure from management to let releases escape to early.

It would be nice to have some dedicated testers around to do smoke tests and general usablity tests. In general FOSS projects rely on the users to want to run the bleeding edge code and test that. But in my experience a group of good testers is the best bang for the buck beyond starting with great programmers.

To the specific points:

>What is the development process? Is it documented?The development process is pretty typical. Check out any successful project on SourceForge. No need for QA audit role. There's no management around to muck things up, the engineers are in charge.

> What types of estimation procedures do you do?Irrelevant. It gets done when it gets done. If you pay for the development one can do better... you can audit those circumstances, but in general, don't need QA audit role here.

> What is the SCM process? Is it documented?CVS or subversion and bugzilla or some such is typically the tool. Much of the SCM process probably depends on the distribution that actually packages the code. Might be Debian's release process. Anyway this is pretty well defined too...

> What is the review/inspection process for all artifacts?There are usually a few "stars" writing all the code. They can tell crap from not. And if it's crap it probably doesn't work, so no one is going to use it. So you find out one way or another. Reviews of code might help but in general it doesn't matter. If it works well, and the people maintaining it can read it, we're OK. The project will die its natural death otherwise (just like proprietary software... actually its death is usually prolonged too far...).

> Are there software requirements? Are they inspected/reviewed?What gets implemented is what the creator needs and sounds cool or seems OK and is contributed. Unless someone is paying, in which case this might be useful. But in general, no role for QA here.

> Are there development plans/design docs? Are they inspected/reviewed?Informal probably. Small team, might trade mockups of screens or working prototype code around. Back of the napkin kind of stuff. Probably works OK for most projects. Wouldn't fly a plane that way though:-)

> Are there code reviews?Hahah. And you and I both know they don't really matter anyway unless you're dealing with poor programming ability, in which case you're screwed anyway... what are you going to do, fire the volunteer programmer from his own project?

Code reviews don't find bugs. You might be able to get more conformity to the coding guidelines if any that way. But in general, many projects enforce their guidelines by having few people allowed to check in. And good programmers go with the flow as far as code formatting anyway.

> What are your defect escape rates?Escape rates? Must be some QA auditor speak. Does that mean bugs V&V didn't find before release? Anyway, Not interesting... If the stuff doesn't work people won't use it. It will die a natural death.

> What is your plan for alpha/beta testing?Release early, release often but maintain a good stable release if you're changing things rapidly. Don't need QA to tell us engineers how to do that.

lots of big oss projects suffer from poor developer doco, wildly-divergent coding standards and a lack of anything vaguely looking like project management. have you ever tried to bust into the mozilla code? it's easier to become a mason!

in the proprietary world of software, new hires get weeks of training to explain the ins and outs of the source tree, the preferred tools, the internal standards &c. this is done not just to get said hires up to speed and productive as quickly as possible but also to ensure that their contributions don't damage the conceptual integrity of the project.

Kind of an obvious statement don't you think? Every major OSS project that I know of does what they can with regards to QA and Testing. They all do alphas/betas and encourage users to test their products and report bugs.

Saying that QA/Testing is what OSS needs is a bit of naive statment, unless of course your talking about what KDE in particular is doing. But the way I read it is you were just trying to make some blanket statement about OSS software in genera

* The 5-10 second load-time for KDE appsThis is a legitimate problem, though getting much better. With prelinking, load times are closer to 2-3 seconds rather than 5-10.

* The 4 second load time just to open a folderDepends on the size of the folder. Normal-sized folders open pretty much instantly on my machine. Performance on large folders (/usr/bin with thousands of items) could be improved, though.

* The cramped and embarrassing K menu, with a 100 different groups and completely illogical redundancies like "Preferences," "System Settings," and "Control Center"Um, my stock Debian KMenu has a dozen folders. "Preferences" is gone in 3.2. There is a "settings" folder and a "system" folder, which is logical --- one is for preferences, the other is for system utilities. Kinda analagous to Windows's "Control Panel" and "Accessories/System Tools" And "Control Center" is an entry in "Settings"! Are you sure you're not mistaking the quick- access area at the top for default menu items? And the categories seem perfectly logical to me. "Graphics," "internet," "multimedia," etc. Sounds perfectly logical to me. Certainly, more logical than the Windows method of giving each company a top-level entry in the menu.

* The poor naming scheme that--despite close to five years of bitching--hasn't been changed in favor of something sane KDE will drop the 'k' when GNOME drops the 'g', Apple drops the 'i', and Microsoft drops the 'MS'. Remember, its "MS Word" not just "Word."

* The convoluted Control Center that is an example of poor interface design with 3,000 items and subitems, grouped together under a cursor that for some reason won't stop changing to the hand iconActually, having all preferences in one program seems a lot more easy to navigate for me than a folder full of applets, one for each task. Work is on-going to make KControl more logical (there was an OSNews entry recently) but the "centralized control" aspect will remain. And Microsoft does it too --- consider the Windows NT administration console.

* The fact that the cursor changes to a hand icon when it moves over taskbar buttons (cursor changes are confusing, disorienting, and annoying to newbies and power users alike) The cursor changes to know when you can click on something. And you pulled that "cursor changes are confusing" thing out of your ass. People manage to use Internet Explorer on a daily basis with the cursor changing over links. You just don't like it because its different from what you're used to.

* The fact that when you tell KDE to put application menus at the top like MacOS...which is faster than slowing the cursor and pinpointing a menu in a floating window like in WindowsWorks fine on my machine. I'm guessing that you're not running 3.2...

* The seeming need for every new version of KDE to add five more sidebars, buttons, and features to KPanel/Konquerer/anything else beginning with K, instead of cleaning the interface and making things fasterEvery release of KDE since 2.0 has gotten faster. Every release of KDE since 3.0 has become more streamlined.

I could go on and on. I don't get why it is so slow.KDE isn't slow. Its got slow load-times for applications, but everything else is fast. In terms of user responsiveness, I find KDE to be faster than XP. In terms of redraw, KDE is even faster than XP. For example, try opening up two IE windows to Slashdot, one on top of the other. Resizing the top window will cause the bottom window blank --- for several seconds if you do it at the right speed. On my KDE, Konqueror doesn't do that.

"* The poor naming scheme that--despite close to five years of bitching--hasn't been changed in favor of something saneKDE will drop the 'k' when GNOME drops the 'g', Apple drops the 'i', and Microsoft drops the 'MS'. Remember, its "MS Word" not just "Word.""

What poor naming scheme? When I open my menu I see items like Text Editor, Web Browser, Calculator, Image Viewer. They launch gedit, epiphany, gcalctool and eog, but the menu don't mention anything about the app names.In KDE, you see menu items like "

I've been waiting for this. Last time I filed a bug report with KDE I got some snotty reply from some programmer who said I was wrong (the bug got fixed in the next release and was listed in the changelog).

I've been waiting for this. Last time I filed a bug report with KDE I got some snotty reply from some programmer who said I was wrong (the bug got fixed in the next release and was listed in the changelog).

I don't know where you guys are coming from. I've submitted a few bugs to bugs.kde.org, and I've never gotten harsh feedback. Even once when I committed the death sin of accidentally posting a duplicate (bug that were already submitted, but I didn't notice), I was still treated kindly and pointed to the other bug where, in the comments, one of the core developers pasted in my somewhat different suggestion for a solution for the record.

It is my experience also from the IRC channel that the KDE developers are great guys and girls -- a few of them even hang out and help users with their stupid problems (ok, s/users/me/, s/their/my/;).

Personally I don't think it's so bad, but I think it should be changed to things like "K-Illistrator". Why? Let's see what these names sound like if you tried to pronounce them...

Koffice - A cough you get at the office?
Killustrator - Shows you how to kill trators?
Kougar - Another name for KMountainLion?
Kroupware - For when you need to collaborate when you have a bad cough. Especially if it's that Koffice you cought (see above).
Kallery - No idea. I can't think of a pun. It must be a bad name:)
KTetris - No puns here either.

you know, they don't sound so bad if you're not a native english speaker. and I'd suppose that in many languages the natural way to say these is to pronounce the K seperately. (koo office, koo illustrator)

It will never be taken seriously with a name like "KDE" and 100 apps all starting with "K."

KDE will never be taken seriously because its name is a TLA? I guess we'd better tell IBM, the FBI, the CIA, the DEA, CBS, the NFL and thousands of other organizations that they're doomed to failure because of their names.

Maybe they should all rename themselves with words with meanings [reference.com] like "One of a fabled race of dwarflike creatures who live underground and guard treasure hoards." Then they'll be taken seriously.

i still haven't got the newest KDE 3.2 to work on my RH 7.X boxes..There's a sourceforge project called KDE-Redhat that's supposed to fill the gap but...
it sure would be great if this new effort made it easy for lazy admins like me.

I got tired waiting for kde 3.2 rpms for Mandrake 9.2. they were not available in the Mandrake-club, despite numerous votes for it. (Rant : Made me wonder what is the point of paying money for the club & voting for RPMs../rant)

Anyways, downloaded Konstruct, told it where I want it to install, and
cd meta/everything; make installthat is it! The download/patch/compile/install went for 2 days!! And now I have a shiny kde 3.2 desktop to play around with.

This seems like it's follwing on ESR's remarks on CUPS the other day but it's not. They've put a lot of planning into this including how to maintain your own CVS and which part of KDE to target for improvement first (KDE PIM).
I'd like to see some of the numerous UI critics take part in this. You know, the ones who write scathing reviews of widgets and fonts like Eurgenia?

This seems like it's follwing on ESR's remarks on CUPS the other day but it's not.

The sad part about all this is that ESR will test only Gnome but will bash ALL open source environments, just as he tested only one distribution but bashed ALL Linux, also those distributions which have seamless CUPS configuration.

I certainly don't agree with much Eugenia sais, but at least she doesn't bash A for mistakes B made.

You're right but have you tried 3.2? Those issues are still there but certainly have been lessened a bit. Also, the speed, man:) Much faster than Gnome but still can't hold a candle to good old Fluxbox.

Just stating MY opinion, but i prefer KDE over GNOME. KDE is pretty stable, although i do still have problems with (seemingly) random crashes of Konqueror, etc. This program sounds like it will make already great software even better. Sort of like the customer comment card at resturants, although i dont think they read those.

If you know what application you want to work with, and what you want to do, check the KDE Quality Team HOWTO [kde.org] for tips and information about the task you want to perform. If you don't know yet, you mask the list for guidance, and read the Quality Team Tasks Page [kde.org] to find out what kind of activity you like best and the requirements to perform this task. Each activity has a different set of requirements. For instance, to be a KDE unstable tester, it is necessary to know how to compile KDE unstable [kde.org].

First of all, in my [somewhat limited] experience with QA, technical writing, and other non-development tasks, these people in general are not really friendly with mailing lists. That's a first turn off. I think an NNTP server would be a better solution. Second, this is targeted towards developers and extremely advanced users who will read all of the HOWTOs, rules, directions, etc. and memorize them to avoid getting flamed by others. Regular users don't do these things, they just click on pretty buttons.

I'm not saying this is wrong, it's just not for average joes out there.

ESR did bring up a lot of good points. However, I doubt this team will have too much to do with that. From the article, it seems to me that it's mostly focused at lowering the entry level requirements for working on the KDE project. They are trying to get people to write documentation, etc. But that doesn't mean that they will actually focus on ensuring that it will all be as simple to use as Windows.

As an open source author and member of a quality assurance team, experience tells me that the greatest effort will go into programming. QA teams generally have enough work to do just fixing bugs, writing documentation and testing releases ("important stuff"), that not enough time is left for making the user interface uniform or even intuitive. In this case, though they are asking users for direct input on the topic. That's a good sign.

The GNOME effort is directed solely at bugs. The KDE Quality Team is directed at bugs, documentation, usability, process, etc, etc. We're trying to go beyond the traditional Open Source mentality of "it doesn't crash so mark it 'release'".

The GNOME bugsquad works tightly with the usability, documentation, and accessibility teams to ensure that those issues are first priority issues for the community, and has for years. If you look through our recent 2.6.0 showstopper emails, the issues are mostly not crashes- they are usability issues, documentation and design issues, translation issues, and slightly further back accessibility issues. There are definitely crasher bugs on the list, of course, but we realize (anyone who is good at QA realizes) that those are only surface issues, and that other issues are just as important if not more so.

Anyway, it's great for KDE that they are doing this- if it works anywhere near as ours has, it will make KDE a much more formidable competitor. But please stop telling the world that this is something new and innovative in free software. That's just as misleading as MS talking about innovation.

The GNOME guys don't have their own "Quality" project like KDE has now, but they arrange "Love days". And actually, it's today [gnomedesktop.org]! So if you want to become a GNOME hacker, head on over to #gnome-love on irc.gnome.org.

What was that open source code auditting thing that DARPA set up, but noone showed up to do the gruntwork?

Sounds like KDE is looking for folks to come along and do all the thankless, boring shit. Spellchecking help files, testing obscure check boxes, applying different themes. Of course, all the cool design work and programming, and artistry, etc, will be done by the core team - who will, of course, accept all the credit.

Noone wants to do the monkey work. I don't want to test constantly, read bug reports, track down insignificant bugs in code thats unused 99.9% of the time. I only do so because it's my job.

Which is a shame for open source in general, because it's that QA step, all the thankless hours of gruntwork, that make the final product what it is.

That's really cold, man. You paint the KDE project as extremely elitist, when it is actually totally the opposite. KDE isn't some exclusive club of core people, any developers are welcome to join the project at any time, and have always been welcome.

Sounds like KDE is looking for folks to come along and do all the thankless, boring shit.

You have it totally backward, actually. The Quality Team project was intiated to include the large number of non-developer people who have been saying that they've always wanted to help KDE, but don't know how. KDE-QT provides a framework to actually include these interested and passionate contributors into our project.They asked for a project like this.

So you see the QT tasks as boring grunt-work. Fine, then maybe KDE-QT is not for you. But there are those who excel at this kind of thing, and actually enjoy it.

Thank you!!! That's exactly what I was trying to say. I am a novice programmer, and have little if any to offer to the KDE codebase. But, I would love to contribute and have extensive experience in things like customer service and communication. The KDE-QT is a FANTASTIC idea!

What nonsense. If you define quality as "doing what it is intended to do", open source is doing an excellent job. Just look at how many bugs and security leaks IS had and still has and how few Mozilla had. (I still have to witness a single Mozilla security hole that could be exploited with realistic chances success.) Just look at the great work the Apache-Team has done compared to IIS which it's many holes and bugs.

Look at how much more polished and usable Windows XP is than any OSS desktop.

Or OS/X. They took an OSS platform and layed a slick, highly integrated and very stylish UI on top of it. In about a quarter of the time that various linux desktop projects have been around. What's the difference?

Legions of grunts whos daily bread relied on toeing the company line, testing what they were told to test, documenting what they were told to document.

I wish this project all success, but I'm skeptical. Contributing programming or artistic skills for free makes sense. After all, programmers like programming, artists like drawing.

But noone likes doing gruntwork. Noone really dances on their way to work at McDonalds. We'll see in the end.

An aunt of mine was as veterinarian, she ran a small animal hospital. She'd have two or three high school girls apply to volunteer there each week, girls are goofy at the idea of hugging puppies.

They wouldn't show up again after the first time they had to do the actual work, say, clean up after a Great Dane with a case of diarreah.

Look at how much more polished and usable Windows XP is than any OSS desktop.
Or OS/X. They took an OSS platform and layed a slick, highly integrated and very stylish UI on top of it. In about a quarter of the time that various linux desktop projects have been around. What's the difference?

Marketing.

I HAVE tried WinXP and MacOSX and both leave a lot to be desired.

There is just no good substitute for multiple desktops with good session management like KDE has. Also Unix-style copy/paste is much faster and more comfortable than MacOS-style (which was copied by Windows) because you don't have to switch nearly as often between keyboard and mouse. Of course KDE supports both copy/paste schemes, so you are not forced to use Unix-style. Real 3-button support is another thing. For example I can open a folder in the filemanager in a new tab with the MMB, or I can jump to a position on a scrollbar with the MMB, or I can push back a window with the MMB.

But of course, marketing has told you that all those features are "for geeks" only and Windows/MacOS is the best there is - so often that people started to believe it. You don't even need examples, facts or reasons!

KDE doesn't have any usability problems, period. I've seen newbies pull hairs because of the numerous single-click/double-click inconsistencies in Windows (why do I have to single-click an icon on a toolbar but double-click an icon on the desktop? What moron invented that scheme?) which don't exist in KDE, at least not in the default configuration.

I have now presented 5 examples of KDE superiority (multiple desktops, session management, copy-paste, 3-mouse button support and single-click consistency), you have prestented nothing, zero, nada. Probably because you have never used KDE and have no idea what you are talking about.

What indeed is a problem is missing and incomplete documentation. Another is missing Win32 binary compatibility especially for games. That and that alone is keeping Linux/KDE off the masses desktops.

These are things that KDE does the way you like. They're not examples of KDE superiority. Don't make the mistake of claiming that everybody likes the same things you do. I've used KDE, and while it's a decent desktop, there's no way in hell I could say that it has no usability problems.

Example: The menus all have "More Programs" submenus. Why can't all the programs for a group be on the same level?

I have used KDE, so I do know what I'm talking about. I don't use Windows because of the marketing. I use it because right now, it's not practical for me to switch to Linux and KDE. I do agree that documentation and binary compatibility are problems, but they're hardly the only ones facing KDE.

There is just no good substitute for multiple desktops with good session management like KDE has.

Except that multiple desktops are highly confusing unless you are a power user and have mentally trained yourself to remember that there are programs open "somewhere else" in the computer. Even a power user like me gets confused with multiple desktops and has to scan each one. It requires holding a lot in your head, which is okay for a computer geek but not anybody else.

My mom, as an example, doesn't even understand *multiple windows* she closes windows before opening new ones.

KDE session management is terrible. Why? Because it only works with programs that are aware of it. Programs like gvim and Mozilla do not remember their state properly. So is a half-baked feature better than no feature at all? I would argue NO, because it will confuse the average computer user who doesn't understand why one program is memorized properly, but not another. They don't understand the mishmash of technology under the hood, and don't need to waste brain cells remembering which programs "work" and which don't.

Also Unix-style copy/paste is much faster and more comfortable than MacOS-style

X Windows has at least *TWO* clipboards, one cut/paste style, and the other done by clicking the middle mouse button. First, having two clipboards is confusing. Having a clipboard that works differently then the market leader (Windows) is confusing. Accidentally clicking the middle mouse button and pasting random stuff into your program is confusing.

This is another power-user-only feature. I see many people that have problems with two-button mice.

Maybe if there was a special "paste" button on the mouse, it could be a good feature, because then people could associate the button with pasting easier.

I personally accidentally hit the middle mouse button into my text programs (like mutt) once a week at least, I really hate that. Am I stupid? No, I just hit the wrong button, why should I now have to undelete the mail and cancel the printer job, and whatever else those keystrokes did!

But of course, marketing has told you that all those features are "for geeks" only and Windows/MacOS is the best there is - so often that people started to believe it. You don't even need examples, facts or reasons!

Have you ever sat down with someone to explain how the computer works? Someone who wants to get their job done? I guess not. I know people who don't use cut and paste at all, they just retype things. They don't mind, because it works for them. You are so beyond the average user and you don't realize it. What should they have to learn this, when it is possible to create a UI that they can use, AND the power users can use.

There are basic principles in designing things, from doorknobs to computer interfaces. One thing is to keep the interface as *simple* as possible, and make all the "modes" obvious. All the things you described are power user features because they require an extra mental model of how the computer works.

KDE doesn't have any usability problems, period.

You've got to be shitting me. Here's one: in Konquerer (which I'm using now), opening a new browser tab when the tab bar is full pushes old tabs out of sight. Where did they go? Did the computer eat them? Oh look.. a couple little arrows.. click on them, now the tabs have jumped around (bad UI design, never move a control element!) This has so many levels of confusion (beyond the confusion of tabs themselves).

Here's another one: my konqueror has three magnifying glasses at the top. If you squint you might realize one has little footprints, one has a "+", and one has a "-". Can you guess what they do based on my description? Why are they even *there*, I've never clicked on them. There are TWO printer icons. One has a printer, one has a printer and a square next to it. What do they do? Who knows and who cares! When I "print" a web page (maybe once a year), I

From your post, it seems you are a KDE fan and that is good, but don't bash others just because they don't choose to use that system. I don't use it because it so slooooooow and has an extremely cramped interface. Way too many buttons going on.

I used Windows for a long time, but then switched to Linux (Mandrake with KDE). I had no major problems whatsoever regarding usability - everything worked more or less like in Windows, but there were more nice things you could tweak and adjust. That's why I love KDE.

Now, for the first time, I admit, I had to use a Mac, with OS/X. I had a hard time. Everything was different - hell, there wasn't even a freaking right mouse button!

I don't know, we normally have 30-50 people at least drop by for GNOME bug day. It's not huge, but we've been proving for two years now that having a quality team can work and really improve the quality of the project, if the rest of the project takes it to heart. It's good to see KDE emulating us in that respect- I'm sure it'll keep us on our toes.:)

Of course, all the cool design work and programming, and artistry, etc, will be done by the core team - who will, of course, accept all the credit.

Okay, here's an idea. The KDE About dialog is already has a "fill-in-the-blank" API. Why not add a Quality Team field to it? Make this an official part of the libs, and you suddenly get an official suggestion to credit the quality people for your application.

Tom Smykowski: Well-well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?

I think this is exactly what open source needs. It's one thing for programmers, sysadmins and advanced users to contribute to open source projects, but there's often no easy way for the average user to help out.

With ideas like KDE Quality Team, the developers get to hear from the users and integrate features that they would like to see, as well as providing a means by which the average user can contribute. That's why Wikipedia works so well - it is possible for anybody to contribute. It's great to see the "anybody can contribute" idea extend to open source where up till now it's really only the advanced users who can contribute easily.

I think this is exactly what open source needs. It's one thing for programmers, sysadmins and advanced users to contribute to open source projects, but there's often no easy way for the average user to help out.

There's a reason for that: average users can find bugs, but cannot report them without having a programmer or an advanced user looking over their shoulder. An average user doesn't think through things logically enough to be able to isolate problems or to come up with the steps needed to consistently reproduced a bug.

You might say, "But the average user doesn't need to know those things! He just needs to report the bug and the programmers will research it and fix it." That's nonsense. A bug report from an average user (if he files one at all) is likely to be along the lines of "A program crashed when I clicked on a menu item." And when you ask for more details, he has forgotten which menu item he clicked on, he has forgotten the error message, he doesn't even know which version he was running. At best you might figure out which OS he uses, but that's it.

QA testing can be done by average users only if they are closely monitored by programmers or advanced users. There needs to be an advanced, knowledgable user present to watch the novice use the program and see how he uses the software. The KDE Quality Team might get some work done--for example, average users could easily locate and point out misspellings or other errors in the help files or dialog box messages--but don't think for a moment that KDE is tapping a great heretofore unused resource. The quality of the feedback generated by the KDE Quality Team will likely be low.

What we really need is to have local LUGs sponsor QA seminars. Get all the local geeks to bring a friend who has never used KDE. Sit them all down in front of a brand new installation of the latest KDE and ask them to perform simple tasks similar to what they would do at home using Windows. (Burn a CD, search the web, etc.) Watch them closely and take notes every time they find a bug or unexpected behavior. Compile that information and submit the necessary bug reports. Now that information will be truly useful.

Disclaimer: I could be wrong about everything. It's not likely, but it's happened before.

What you say makes sense, but if you read my article [newsforge.com] that I wrote to explain the effects of the project in more depth, you'll see that (hopefully) you're wrong.

The point of the project is not only to bring in this heretofore unused resource, and then train it, so that you get a growing number of people with little or no technical background becoming competent with things like Bugzilla, CVS, translation tools, promotion work, etc. These people can then act as a gateway between the developers and the users,

Personally I think this is a very good idea. My programming skills are limited to simple BASH scripts so Im no use to most devel teams. But I do have good documentation/bug hunting skills. I do this as part of my job. So it is a good oppurtunity for those who do want to give something back to the OSS community but fall short in the programming area. Good Idea KDE.

For fostering a community unlike any other. www.kde-look.org [kde-look.org] has been my first stop to see modern ideas on desktop design for years now. I am not nor have I ever been a KDE fanboy (I'm a Blackbox user) but they have managed to form a remarkable bond with the graphics design community (and the graphically inclined). They should be a model for more OSS projects and this is something we should look at as a community as a whole. There is more to good software then 1's and 0's.

I understand what your posting. But take a look at Kde-look [kde-look.org]. Its a very different thing, slightly OT, but its a working community site that *encourages* non-developer interaction, something I believe KDE has pioneered with some success here. Everyone has a bugzilla site (which can be pretty intimidating to newer users) but KDE has succeeded in fostering a peripherial community in kde-look and I think its an important and sometimes (often) over looked thing. We need to encourage more participation from the n

Did you read my link at all? We've been having online bug days and a bug channel for 2 1/2 years, where people get together on a daily basis to discuss bugs, help new bug volunteers, etc. And like I said, mozilla was doing it before GNOME was. Creating such a community is not new, and it's not rocket science.

This sounds like a good idea for an Open Source project. However, it's funny to me, because not long ago my boss was tossing around the idea of dividing the development group I work in into "The Stability Team" and "The Feature Team". Luckily the silliness of this sunk in and the idea floated away into Dumb Idea Heaven. We still joke about it though because nobody wants to get stuck with the crap job on the Stability Team, where you have to answer all the phone calls and fix the bugs in everyone else's code.

Yes it is crap for developers, but this initiative is for advanced users and not developers. Basicaly it tells users how to run the most recent and greatest KDE right out of CVS, and how to report bugs. From there they can do as always, run the most recent software just for the kick, and report the bugs they encounter. Or they can decide they want to do something good to pay back the KDE team for its hard work, and just try out every obscure feature and make sure it all works. Doesnt mean you have to code, it just mean you have to know how to use applications and think for yourself.

Well, I guess I'm asking for ideas here. In an open-source proj like this, you obviously want people to choose what they want to do or how they want to contribute. When you do that, one of the biggest problem is that, there are some parts of the project that everybody tries to avoid.

I've tried to manage a project, in a similar way, on a very small scale though (~30 people). Everybody wanted to own the coolest parts of the project. What I eventually ended up doing is tying cool parts with not-so-cool parts. So, if you choose the cool part, you automatically also own the corresponding not-so-cool part.

I'm looking for more ideas. May be some brainstorming would help here.

Reading through the site, I realize that two important elements of QA are missing. They won't be as fun to do, but it would be great if someone did them.

1) Requirements and specifications. Also known as what you need before you start coding. Otherwise known as the official arbiter of whether the program is doing what it is supposed to be doing.

This is thankless gruntwork, but it is very valuable. Some KDE apps already have some, but all need them. Take an email client for example. Go grab all the RFC's relevant to POP3, IMAP, etc, and distill them down into a set of requirements stating what the program is supposed to do. Open Source is informal enough that we could get away with combining requirements and specifications into one document.

2) Test procedures. Now take that requirements document and write a comprehensive test procedure. Include regression testing. Now anyone can take this procedure and simply execute it to find out if the program follows its requirements. If a step fails, log a detailed bug that states which requirement is not met.

Not only would these two things aid the the developer in creating and improving the application, they would also improve the quality of bug reports. Instead of bug reports saying "it doesn't do what I think it should do", you get bug reports saying "it does x but the requirements say do y." If the applications still doesn't do what you want it to do, examine the requirements yourself, and if they aren't complete, propose a new one.

Requirements are your road map, and test procedures are the person in the passenger seat reading it to make sure you take the correct exit to Albuquerque.

I am the one who is currently putting the most effort into the KDE Quality Team implementation, so I am qualified to speak for the project:

Let's start by making something clear:
The main idea is not to build a QA project inside KDE. The main idea is to support and embrace new contributors with any background, and help to organize their efforts. For instance: Any doubts about the docbook? We are glad to help. Do you want feedback on your work? We are happy to provide. Looking for guidance? Hop in!

We don't want to point what is good for you: we try to present you with a long list of things one can do to help, and organize these efforts.

The recommended approach for non programmers is different from other projects: it is more like the project manager in a company than of a task specialist. In other words think of acting upon the whole of Kontact instead of acting upon the
context help for the whole KDE project. We recognize that the main tool for helping an application is knowing it well. A quick look at the activities list, presenting the requirements for performing the tasks, is sufficient to prove that.

Linux version.01 was launched in September 1991. (timeline [linuxjournal.com]) Try 12.5 years.

Rather, if you mean the relative amount of time it seems that I've been thrashing around in the 'quirkiness' (to be polite) that is the linux desktop... then I think you've underestimated that figure by a few decades.

The positions pay nothing. There's this thing called "open source software", in which software is largely developed by a community of volunteer contributors. KDE is such a project. You may have heard of some others, such as GNU and the linux kernel.

It is recommended that companies spend 10% of their development budget on researching the usability of their products. Every dollar that is spent on usability saves $100 in support costs.

Red Hat has spent over $700,000,000 buying out a compiler company and a few silly dot coms. They recently sold $500,000,000 in bonds. Their programmers tell me the reason why their software has so many usability problems is that they "can't afford to hire HCI people".

> Hmm. That's not the GNOME that I've seen at all for the last> year and a half (the amount of time that I've been following> GNOME events). I've found people very helpful, very kind> and patient with me as I've learned, and very willing to help> me on my level.

That depends in what ways you participate to GNOME and with what kind of people you had contacts with.

I for my own speak about (well they know who I mean... to not namecall them here). I for my own had very bad expiriences with some

This is one of the reasons why the KDE style guide is shorter than GNOME's HIG; most of the GUI design aspects of KDE are enforced automatically while in GNOME, it is reliant on the programmer. I have to admit though, the HIG is great for PR:)

Being a KDE contributor myself, I feel the urge to correct some of your statements and agree to others.

GNOME has had the Human Interface Guidelines for over a year and a half now.

KDE has User Interface Guidelines since more than 4 years. These guidelines are a bit outdated, but they are followed by almost all applications within KDE. This is one of the reasons why KDE applications are quite consistent with each other. KDE has been dedicated towards usability since its foundation, but usability was never the only goal. KDE was never perfect, but its usability has been constantly improving every version. Compared to most other PC software, KDE has always been doing reasonably well in terms of usability.

The whole project is dedicated toward usability.

True. The GNOME project made a good decision when they introduced HIG, even if many GNOME users were very angry at the time. Removing functionality was one of the main methods of solving GNOME's early usability problems, which should only be done if there is really no other way to solve usability problems.

Most people complaining about KDE's usability are suggesting the same strategy for KDE. I don't agree with this. Solving usability issues in other ways is more difficult and takes more time, but the end result will be better if we stop telling others "I know better than you that you don't need this". But anyway, I agree that having good user interface guidelines is important.

Don't get me wrong, KDE has some inovative technologies behind it, but even 3.2 is miserably lacking in terms of usability and style. IMHO, this "Quality Team Project" looks more like an after-thought or a lame side project than a redirection of the whole project.

My impression is very different. The Quality team idea has been greeted with a lot of very positive responses among the KDE developers. There is a lot of interest in this within the KDE project.

Also, the only reason why gnome was created in the first place is null and void. Now that Novell has taken over Ximain you can expect VENDOR lock in. Want groupware for linux? Thats $300 a seat.

Gnome was created because KDE was based on QT which was not free software. As far as I understand it, QT is now free though the port for windows in not, someone could port the GPL QT onto windows but no-one has (that I have heard of) and until that happens Gnome/GT