Slashdot Mirror
Announcing the KDE Quality Team Project
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!"
QA? Testing? This is what open source needs!
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.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
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.
I don't need no instructions to know how to rock!!!!
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.
My operat~1 system unders~1 long filena~1 , does yours?
right you are - but should it be that way? for newbies and technophobes -packages are the way they get stuff onto their machines
For fostering a community unlike any other. www.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.
Quack, quack.
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.