[KDE Dot News]
 faq
 flatforty
 contribute
 subscribe
 configure
 search
 rdf
 main


  Announcing the KDE Quality Team
Developer Posted by Carlos Leonhard Woelz on Tuesday 02/Mar/2004, @09:51
from the help-wanted dept.
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 or not, in order to improve all areas of a given application (instead of a given area of the whole project), working orthogonally with the maintainers, developers, documenters, interface designers and artists.

Have you ever wished to help KDE in some way, but never knew how? The KDE Quality Team might be just what you need! People with disparate backgrounds can join the KDE Quality Team Project, for the development of a complex desktop environment requires a wide range of skills. The main tool to help any application is knowing well its interface and functions, so any user who knows and cares for any KDE application can almost immediately help the project. Depending on the team member programming knowledge, artistic and writing skills or willingness to learn, there is no area of the application that cannot be improved.

In terms of support for new contributors, the project already offers:

In an interview conducted by Henrique Pinto, Carlos Woelz, the person who is currently putting the most effort in the project, speaks about the project:

Why there is need for a KDE Quality Team?

There are many people out there who want to contribute, but didn't manage to know where to start, specially non programmers or at least non unix programmers. To them, this is a whole new world (CVS, compiling, docbook, xhtml, etc...). I think there is no better way to help KDE than to support these newcomers.

If you are curious about the original motivation, you can read the original proposal.

What was the inspiration for such a project?

When I started thinking about giving something back to KDE, I had trouble knowing where to start. There is a lot of good information at developer.kde.org, but (obviously) much of it is oriented to unix developers. I felt a bit lost, the learning curve is steep for someone like me coming from the windows world. Also, I started working with applications I knew too little, and with too many of them at the same time.

In which ways KDE will benefit from having a Quality Team?

The KDE developers have been doing a great job. My hope is that we can bring the documentation, artwork, communication with our users, and the little boring details of the user interface to the same level of quality of the KDE applications. Also, managing bugs and wishes can help programmers focus on fixing bugs and adding new features.

How can one get involved with the Team?

If you are an experienced contributor, and are interested in guiding and reviewing the new contributors work, join the kde-quality mailing list. If you like a KDE application and want to help, join the kde-quality mailing list.

For new contributors, there are many different ways to help the KDE project. We have a collection of tasks, with the necessary skills on how to perform them, and links to guides on how to perform them at the KDE Quality Website:

http://quality.kde.org/develop/modules/index.php

The KDE PIM module was chosen as recommended initial target for the KDE Quality Team because of its shorter release cycle, so things are going faster there. There is wiki a page to coordinate the efforts for the PIM Quality Team, where you can have an idea of the current efforts.

http://wiki.kdenews.org/tiki-index.php?page=Quality+Team+KDE+PIM

How will be the relationship between Quality Team members and application maintainers?

The maintainer and developers know the functionality of the application better then anyone, therefore their help and review is needed for all activities around that application. This stresses the importance of doing serious work. If the team does good work, I am sure it will be respected and helped by the maintainers.

I couldn't be happier with the response from the community to this project. The KDE PIM developers, for instance, were planning to start something similar to the KDE Quality Team. We joined forces, Adriaan de Groot is the Quality Team Coordinator for KDE PIM, and they put a KDE PIM page with information about the PIM tasks at the KDE PIM site:

http://pim.kde.org/development/janitor_jobs/

How many people are involved in the project in this initial stage?

Already more than I imagined. The project in integrating nicely to KDE normal development process.

How do you envision KDE and the KDE Quality Team one year from now?

I don't try to envision anything. What I am sure is that I will help the KDE project. All the work put on the Quality Team (writing guides, the website, the structure, etc...) has already produced good documentation. I am not worried about it, because any time spent with the project will be well spent.



<  |  >

 
  Related Links
 ·   Articles on Developer
 ·   Also by Carlos Leonhard Woelz
 ·   Contact author

Thread Threshold:

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

More to come on press & promotion work
by Tom Chance on Tuesday 02/Mar/2004, @10:59
Just a note to let people know that I have some stuff in the works on press & promotion work, specifically:

o How to write press releases, and where to send them
o How to write a good article on a KDE application
o How to get work into online/paper publications

So if you've ever considered a career in journalism, or wanted to do some freelance media work on the side, or even if you just like the idea of promoting KDE apps, then watch this space :-)

Also, people might be interested in an article I wrote on this project:

http://www.newsforge.com/technology/04/03/01/1511242.shtml

[ Reply To This | View ]
  • Re: More to come on press & promotion work
    by Alex on Tuesday 02/Mar/2004, @22:47
    I like the article, well thought out, though I don't think you should have mentioned the programmer stereotype, be it true or not.
    [ Reply To This | View ]
    • Re: More to come on press & promotion work
      by Tom Chance on Wednesday 03/Mar/2004, @00:14
      Heh, the funny thing is that I didn't even say that all or a majority of hackers were "scientific atheists", nor did I imply that theists are unscientific, but I suppose that sort of reaction is always going to come from some people ::)
      [ Reply To This | View ]
      • Re: More to come on press & promotion work
        by Scott Wheeler on Friday 05/Mar/2004, @09:05
        Well, there are a few problems here -- first it should have been "scientific, atheistic" rather than the above form to make it clear that they were independent attributes.

        The proper term would have been "agnostic" since "atheistic" implies an active disbelief in the supernatural rather than the more common simple lack of belief one way or the other.

        And also there are a fair number of religious folks in the KDE community; I don't think that it's a useful generalization to say that KDE substitutes for religious belief aside from the social function that organized religions provide. But there KDE is more like a chess club than like an organized religion.

        And to finish off the mini-rant -- you're using the term "spiritual" to describe "stuff that people just enjoy doing". I don't think that those in the community that consider themselves "spiritual" would enjoy the analogy (since I've rarely heard a person explain their religion in terms of "I just kind of like it") and those that aren't likely resent the term. ;-)
        [ Reply To This | View ]
excellent
by LMCBoy on Tuesday 02/Mar/2004, @12:13
This is very good stuff. Are there any instructions for developers, in order to have their module/application added to the Quality Team project? Right now, it looks like only KDEPIM is available for interested QT volunteers to work on.
[ Reply To This | View ]
  • Re: excellent
    by aleXXX on Tuesday 02/Mar/2004, @12:20
    Hi,

    if you want to help, please join our mailing list

    http://quality.kde.org/contact/mailinglist.php

    You don't have to be a programmer, but of course programmers are also welcome.
    Volunteers can work on any part of KDE they want, as it has always been :-)
    It's just that for the KDE PIM project there have been some goals and tasks collected and written down.

    Bye
    Alex
    [ Reply To This | View ]
  • Re: excellent
    by Carlos Leonhard Woelz on Tuesday 02/Mar/2004, @13:22
    We decided to start with KDE PIM because of the shorter release cycle, so things are more urgent there. But we hope to expand the coverage to more mudules, making easier to new contributors to select what ot do.
    Also, anyone can create a team page for his module / application, and announce it in the mailing list, I will gladly update the website with this new information.
    [ Reply To This | View ]
    • Re: excellent
      by annma on Tuesday 02/Mar/2004, @16:47
      We already started an 'Open Tasks' page in KDE-Edu so that could be linked from the Quality main page.
      We want to focuse on adding WhatThis help in each app, porting some apps to some more modern code, fixing bugs by systematically going through the bug database, improving doc (taking screenshots is an example of a non-developer task). Creating icons and pics for specific apps are also wanted tasks. There is plenty to do and everyone can find something to do in order to help improving KDE. Checking that every string is in proper english and spelled correctly is also a global task that can be done by native english people.
      I hope many people will join and make a difference.
      [ Reply To This | View ]
Extentions of the old jobs place
by anon on Tuesday 02/Mar/2004, @12:30
Looks like a great source for new KDE contributers, just like the old "jobs" page used to be on kde.org (but hasn't been actively used since 2001 or so)
[ Reply To This | View ]
  • Re: Extentions of the old jobs place
    by Anonymous on Tuesday 02/Mar/2004, @13:14
    That's why there's also http://wiki.kdenews.org/tiki-index.php?page=Developers+Wanted
    [ Reply To This | View ]
Pardon me...
by David on Tuesday 02/Mar/2004, @13:36
...but this is a ******* brilliant initiative, and it is sure to get more people involved. Now when I get this wireless network and server infrastructure up and running here I'll definitely be reading through this. Perhaps one of the problems for some are the lack of broadband access, and not knowing how to get involved and try things out otherwise. It has been for me.
[ Reply To This | View ]
outdated screenshots specs?
by Pat on Tuesday 02/Mar/2004, @13:42
on http://i18n.kde.org/doc/screenshots.php it says:
"To give our documentation a corporate look we have decided on ONE theme/style for all screenshots:
Window decoration: Keramik
Widget style: Keramik
Colors: Keramik
Background: Flat color - Color must be white"

shouldn't that be Plastik now? :)
[ Reply To This | View ]
  • Re: outdated screenshots specs?
    by mooby on Tuesday 02/Mar/2004, @13:51
    And you will make screenshots for all languages for all applications ? because I don't think that each i18n team want to do another series of screenshots for all the localized docs :)
    [ Reply To This | View ]
    • Re: outdated screenshots specs?
      by porter235 on Tuesday 02/Mar/2004, @15:58
      OK, this has been mentioned before, but why isn't there an automated tool for taking screenshots? Then you set the script and walk away. Computer hums away while you are at work and when you get back there is a big old batch of screenshots ready to be put into files. Hell, match that up with an xml log and an xslt to transform to docbook and then do docbook to pdf. Now you have docbook, pdf documentation ready to go.

      I am not able to code this so, I'll shut up now. (But I might be able to help with the XML, XSLT part of things)
      [ Reply To This | View ]
      • Re: outdated screenshots specs?
        by Didi on Wednesday 03/Mar/2004, @05:57
        This is a very good idea. Would this be very difficult to implement? If the standard KDE framework could provide this functionality as part of a standard test environment a lot of time could be saved and used to improve programs. I envisage a tinderbox like setup that would continuously rebuild and run kde and all apps in all languages creating snapshots as it goes. This could also be used to catch simple errors and could regularly give all the saved pictures a once over to check if everything still looks good.

        (usual disclaimer: don't have time, kde programming skills or broadband access myself)
        [ Reply To This | View ]
  • Re: outdated screenshots specs?
    by Henrique Pinto on Tuesday 02/Mar/2004, @13:52
    No, because Keramik is still the default style...
    [ Reply To This | View ]
    • Re: outdated screenshots specs?
      by John on Tuesday 02/Mar/2004, @14:10
      yes, but plastik is the defacto default among users :)
      [ Reply To This | View ]
      • Re: outdated screenshots specs?
        by Ian Monroe on Tuesday 02/Mar/2004, @14:43
        There was some talk of making it the default default for 3.2 on this site. It seems to be the case they will wait for at least 3.3 but perhaps 4.0 before making changing the default theme, so people aren't thrown off.
        [ Reply To This | View ]
        • Re: outdated screenshots specs?
          by Peter Simonsson on Tuesday 02/Mar/2004, @16:26
          There will be no change of the default style until 4.0.
          [ Reply To This | View ]
          • Good
            by Alex on Tuesday 02/Mar/2004, @22:48
            Keramik looks good, it can be refined, but it looks good and there is no point to change it so fast.
            [ Reply To This | View ]
            • Re: Good
              by Rayiner Hashem on Wednesday 03/Mar/2004, @23:48
              Keramik is like Luna. A few people like it, but among users, there is a very large-scale tendency to immediately switch to a different style. I understand the logistical problem of changing the default style, and agree that we shouldn't change it during point-releases. However, I actually think Keramik is hurting KDE a bit by making KDE screenshots much less appealing then they could be. I have to say I was relieved when the "Deep Inside KDE" article came out with the screenshots in Plastik.

              Keramik also has some practical problems other themes don't. For example, the gradient toolbar looks strange. You've got what appears to be a curved surface with flat icons balanced on it at one point of contact. Further, it interacts badly with the "toolbar crawl" present in all KDE apps when they are resized. Styles that don't have a toolbar background (.NET, ThinKeramik) or have a very subtle one (Alloy, Plastik) make this effect nearly unnoticable. Keramik's toolbars are so distinctive that it accentuates the effect! People might consider this trivial, but people who don't understand the code can easily interpret this to mean that "KDE is slow."
              [ Reply To This | View ]
On /.
by ac on Tuesday 02/Mar/2004, @14:23
http://developers.slashdot.org/article.pl?sid=04/03/02/1924204
[ Reply To This | View ]
Just what is needed!
by Marc Heyvaert on Thursday 04/Mar/2004, @05:08
An exellent initiative.

I am still a newbie and want to contribute to KDE (KOffice in particular) and during these past few months I have struggled with some of the things that are now very clearly explained on the web-page.

I have only notions of programming in C++ and I am a complete beginner in Qt, so my contributions in that area will be limited. Nice to see that there is now an additional platform to discuss what needs to be done and how it can be done efficiently. I'm sure it will enable us to exchange information in a better way.

Marc
[ Reply To This | View ]
script fails
by Patrick Smits on Thursday 04/Mar/2004, @05:32
On http://quality.kde.org/develop/cvsguide/buildstep.php#step5 the script to compile single KDE-modules fails:

kdedev@ip172:~/src/kde/log> more kdelibs-20040304.log
./module-build.sh: line 7: configure: command not found
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target `install'. Stop.

I think the correct module-build.sh script would be:

kdedev@ip172:~/src/kde> cat module-build.sh
builddir="/home/kdedev/src/kde/build/"$1
logfile="/home/kdedev/src/kde/log/"$1"-"$(date +%Y%m%d)".log"
moduledir="/home/kdedev/src/kde/"$1
cd $moduledir
make -f Makefile.cvs >> $logfile 2>&1
cd $builddir
$moduledir/configure --enable-debug > $logfile 2>&1
make >> $logfile 2>&1
make install >> $logfile 2>&1

Works for me!

Patrick
[ Reply To This | View ]
At last, QA for KDE
by James Richard Tyrer on Thursday 04/Mar/2004, @11:18
I am, of course, very happy to see this.

There are additional issues that need to be addressed. The most important of these is regression testing. In KDE-3.2.0 there were serious regressions that were not caught and/or almost not caught. Specific example was bug 73379.

Bug 73379 also illustrates some of the problems that the Quality Team faces -- problems with developers. Various excuses were made as to why the bug wasn't important and then it was closed before it was fixed.

It has now been fixed (and fixed in KDE_3_2_BRANCH) but it should have been caught and fixed before the release of 3.2.0. This bug was a regression; proper regression testing would have caught it. Now, the test cases should be added to a regression testing data base. So that even after it is marked "VERIFIED" if it is still fixed in the next stable release (3.2.1) that future versions will still be tested for this.

Also important is the "won't fix" problem. Yes the maintainer is in charge of his module, but if QA is going to work, he can not arbitrarily use this authority to refuse to fix bugs. Bug 53345 (which had previously been closed without fixing) is an example. My comment #10 which ended with: "Please leave it open till it is fixed" was answered with personal insults. The general issue of what to do when the maintainer says 'won't fix' and closes a bug that the QA team feels is important needs to be addressed.

In general, the 'Ostrich algorithm' is not a proper solution to any bug.

And, third, the QA team needs to be able to set the severity and priority of bugs. The most important point here is that regressions should automatically be marked (at a minimum) Priority:HI and regressions that will be encountered by many users should have Severity:major and in some cases Priority: VHI. The reasons for this should be clear to users but don't seem obvious to developers. So, if (as the some developers seem to insist) QA team members with BugZilla modify authority are not to be allowed to change these, then there must be someone in charge that *is* allowed to do it.

I anticipate that there will be problems. Some developers do not like others reviewing their work. But that is what is necessary for good quality control. Alternatively we can try to move towards TQM where the developers would be responsible for testing their own work. This won't, however, work to start with since as bug 73379 illustrates, some don't do even the most basic testing of their work.

--
JRT
[ Reply To This | View ]
The Fine Print: The previous comments are owned by whomever posted them.
( Reply )
  "There are some gaps in my recollection of the past, I always assumed that was sleep." -- Rob Kaper
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.
[ home | post article | flat forty | subscribe | search | rdf ]