Quality Team Tasks Page

These are general tasks, listed to help people decide where to start, or which tasks are more adequate to their personal preferences. Of course, you don't have to cover the entire module of your application, or to specialize in one task. As you can see below, your main tool is knowledge of the application. With that, you can cover many areas and care for the general level of quality of the application you choose. If you want to quickly improve your knowledge of the application, you can read the existing documentation.

There are activities for every level of commitment and knowledge, from the user to the programmer, from the newbie to the expert. Just check the requirements for the task. We try to provide all basic information and references to start helping out.

Testing

General information about how to perform testing tasks is offered by the Bugs And Wishes Reports Management Guide.

KDE Stable Testing: While the software evolves careful testing is needed to ensure that new features work and old features are not affected by new ones. A Software Tester has to follow the development for knowing what is supposed to work, then test that this is actually the case and does not introduce new bugs and create bug reports if needed.

Requirements:

• To know well the involved applications
• To maintain a local SVN repository of the KDE 3.4 stable (KDE_3_4_BRANCH) is strongly recommended, in order to test the fixes that are committed to that branch (See the SVN Guide).
• But knowing the application very well and reporting and following the bugs you reported for your distribution is already a great step.

KDE Unstable Testing: While the software evolves, careful testing is needed to ensure that new features work and old features aren't affected by new ones. A Software Tester has to follow the development for knowing what is supposed to work, then test that this is actually the case and doesn't introduce new bugs and create bug reports if needed. Dedicated Software Testers help to ensure that our software becomes and remains stable.

Requirements:

• To know well the involved applications
• To maintain a local repository with the unstable KDE module. Check if your module can be built with kdelibs from 3.4, so you can use the stable KDE 3.4 as a base, or if you have to use unstable KDE. See more about this in the SVN Guide.

Testing Patches: We often get patches from external developers. Before releases we also have the policy to post all non-trivial changes as patch before committing them to SVN. Testing all these patches takes some time and sometimes developers do not have enough time to actually do this. People concentrating on testing patches, collecting and giving feedback would be very helpful to get rid of this bottleneck.

Requirements:

• To maintain a local repository with the unstable KDE module. Check if your module can be built with kdelibs from 3.4, so you can use the stable KDE 3.4 as a base, or if you have to use unstable KDE. See more about this in the SVN Guide.
• To know how to manage your local SVN repository differences from the main repository. More about this in the Managing Your KDE SVN Repository Guide to learn how to apply and revert patches, dealing with conflicts, etc...

Managing Bugs and Wishes: There is a steady flow of incoming bug reports and wishes. The job of a Bug List Maintainer would be to review incoming reports, to try to reproduce the bugs, to gather missing information, to identify duplicates and to keep track of development in order to keep the bug list in sync with the actual development.

Requirements:

• To know well the involved applications
• To maintain a local SVN repository with the unstable KDE module. Check if your module can be built with kdelibs from 3.4, so you can use the stable KDE 3.4 as a base, or if you have to use unstable KDE. See more about this in the SVN Guide. It is also strongly recommended to keep a stable version of KDE, to test bugs against the current stable (KDE_3_4_BRANCH)
• To know how to manage your local SVN repository differences from the main repository. More about this in the Managing Your KDE SVN Working Folder Guide to learn how to apply and revert patches, dealing with conflicts, etc...

As an example of the bug and wish lists for various KDE applications, here is a list of bugs for some KDE PIM applications:

• KMail
• KOrganizer
• KAddressBook
• Kontact
• KPilot

Documentation

General information about how to perform documenting tasks is offered by the Documentation Guide.

Providing Screenshots: For the documentation and the websites we need screenshots. It's not hard to make some basic screenshots, but to completely cover a program and do this in an visually interesting and pleasing way some more effort is needed. Someone responsible for that task could make all the difference.

The specifications for screenshots are fairly strict. It would be useful to make a separate screenshot user for the screenshots, since the settings required for screenshots in documentation may be different from what you want to work with. There are additional screenshots tips in the Documentation Guide

Requirements:

• To maintain a local SVN repository with the unstable KDE module. Check if your module can be built with kdelibs from 3.4, so you can use the stable KDE 3.4 as a base, or if you have to use unstable KDE. See more about this in the SVN Guide

Reviewing Documentation: a finer grained review, a list of specific issues, new items to be added, and things that are no longer accurate, are a huge help for the documentation team, either on a application-by-application basis, or for the whole module (or indeed, for any document you can find.) This is a highly time consuming thing to do, and it pretty much eats up the few doc resources prior to each release. With such a list, a writer can generally go through and fix all the items in a fraction of the time it takes to carefully compare the document and the interface and find the changes.

The best way to perform this tasks is to fill a bug (better if it is one bug per issue you find), and notify the Documentation Team and the KDE Quality Team when you are done. It is much better if you use KDE unstable, as you can compare the documentation with the latest version of the application, but it's also helpful if you are using the latest stable KDE version. Sometimes the documentation is much older than the latest KDE stable, and reviewing it against the stable version is already a big improvement.

Requirements:

• Recommended: to maintain a local SVN repository with the unstable KDE module. Check if your module can be built with kdelibs from 3.4, so you can use the stable KDE 3.4 as a base, or if you have to use unstable KDE. See more about this in the SVN Guide

Writing Documentation: Writing documentation involves keeping up with development versions of KDE, tracking new and planned features, getting screenshots, collecting existing documentation, proof-reading and more. Most of these tasks are neither done by the documentation writer nor by the developers so a documenter could play an important role in improving the documentation.

Requirements:

• To know well the involved applications
• To maintain a local SVN repository with the unstable KDE module. Check if your module can be built with kdelibs from 3.4, so you can use the stable KDE 3.4 as a base, or if you have to use unstable KDE. See more about this in the SVN Guide
• To know how to manage your local SVN repository differences from the main repository. More about this in the Managing Your KDE SVN Working Folder Guide to learn how to apply and revert patches, dealing with conflicts, etc...

Writing WhatsThis: whatsthis is the the context help property of Qt/KDE applications. It\'s an excellent first step for a new contributor, as it is gratifying and simple to perform.

Requirements:

• To know well the involved applications
• To maintain a local SVN repository with the unstable KDE module. Check if your module can be built with kdelibs from 3.4, so you can use the stable KDE 3.4 as a base, or if you have to use unstable KDE. See more about this in the SVN Guide
• To know how to manage your local SVN repository differences from the main repository. More about this in the Managing Your KDE SVN Working Folder Guide to learn how to apply and revert patches, dealing with conflicts, etc...

Communication And Promotion

General information on communication and promotion is offered by the Communication And Promotion Guide and by the Media Guide.

Interacting with users: The KDE-users mailing list is a great place to collect info, bugs and feedback from users, and at the same time, try to help them with specific problems. It is also a great place to learn, as many answers you don't have will be answered by the application developers. Evolving from this, you can maintain a FAQ. You don't have (obviously) to know all KDE applications well: you can focus on one or two.

Requirements:

• To know well the involved applications

Writing Articles About the Current Release: Your article can be a tutorial, a walktrough (explaining how to perform certain tasks, better yet if in a graphical way), a comparison of features between other similar apps, tips and tricks article or a review. The Communication And Promotion Guide present tips on how to get your article published.

Requirements:

• To know well the involved applications

Writing Articles About a Future Release: Your article can be preview (showing features of an upcoming release), a review of the future version or a comparison focusing on the differences between the two versions.

Requirements:

• To know well the involved applications
• To maintain a local SVN repository with the unstable KDE module. Check if your module can be built with kdelibs from 3.4, so you can use the stable KDE 3.4 as a base, or if you have to use unstable KDE. See more about this in the SVN Guide.

Development

General information on programming is offered by the Programming Guide. The KDE Developers Corner website offers even more documentation for programmers who want to start hacking KDE, such as HOWTOs and FAQs, tutorias, standards, reference and APIs.

Maintaining License and Copyright Information: Each source file in SVN should have a complete list of copyright holders and an appropriate license. This information is not complete or up-to-date in all cases. Most of the information could be extracted from the SVN logs and by asking the contributors. This is an important job but costs some time, so it would be a great help if there would be somebody taking some of this work from the developers.

Requirements:

• To maintain a local SVN repository with the unstable KDE module. Check if your module can be built with kdelibs from 3.4, so you can use the stable KDE 3.4 as a base, or if you have to use unstable KDE. See more about this in the SVN Guide
• To know how to manage your local SVN repository differences from the main repository. More about this in the Managing Your KDE SVN Working Folder Guide to learn how to apply and revert patches, dealing with conflicts, etc...
• To know a little about licenses and copyrights.

Maintaining Developer Documentation: There is a lot of developer documentation which isn\'t written or collected in an organized way. This consists of Discussions on the mailing lists, source code documentation, bits and pieces here and there. A Developer Documentation Maintainer would feel responsible to collect this information, watch the mailing lists and other sources of information and keep the developer docs up to date. This would make it easier for new developers to get into the project and would save other developers the time to look for or redundantly produce this kind of information.

KPilot, for instance, has a programming reference (available in webcvs) that could use some polish and publicity.

Requirements:

• To know well the involved applications
• To maintain a local SVN repository with the unstable KDE module. Check if your module can be built with kdelibs from 3.4, so you can use the stable KDE 3.4 as a base, or if you have to use unstable KDE. See more about this in the SVN Guide
• To know how to manage your local SVN repository differences from the main repository. More about this in the Managing Your KDE SVN Working Folder Guide to learn how to apply and revert patches, dealing with conflicts, etc...
• To know c++ programming.

Modules and Application Quality Team Pages

Under each module and application page you can have a general view of the status of the different tasks, more suggestions and a general view of what is needed to make your application rock!

Here you can access more information and tasks about the specific application. You are welcome to post your ideas, doubts, tasks, status updates about the different areas of the application. The modules that have a question mark do not have an updated tasks pages yet. All tasks pages are located in the KDE Wiki site. An excellent way to start helping your favorite application is to update its module tasks pages in the KDE wiki site.

• KDE PIM Open Tasks and Status Homepage: The kdepim module is an excellent target for someone who wants to start contributing. It will have a shorter release schedule than the rest of KDE (for the 3.3 release) and it is very actively developed.
   
• KOffice Open Tasks and Status Homepage: KOffice is a very ambitious suite of applications and offers amazing functionality, but suffers from lack of man power. The applications include KWord, KSpread, KPresenter, Krita, Kexi, Kivio, Karbon 14, KFormula, KChart and Kougar.
   
• KDE Edutainment Tasks Page: with the noble goal of developing high quality educational software, the KDE Edutainment Project currently features language, mathematics, science and teaching tools software. In addition to the wiki page, there is also a Open Tasks Page for tasks that need to be done before KDE 3.3.
   
• KDE Multimedia Software Tasks Page: If you use and like multimedia software, contributing to KDE Multimedia or one of the applications: amaroK, Brahms (Sequencer/Notation Editor), Juk (Music Jukebox), K3b (CD/DVD-Burning), Kaboodle (Media Player), Kaffeine (Media Player), KAudioCreator (CD Ripper), KMid (Midi/Karaoke Player), KMix, KMPlayer, KPlayer, KRec, KSCD (CD Player), Noatun (Media Player), NoteEdit (Notation Editor) and Rosegarden (Sequencer/Notation Editor)
   
• KDE Artists Page: If you have talent drawing raster or vector graphics, composing web pages, creating sounds and effects, the KDE Artists project is for you. KDE Artists work on the artwork of KDE, including icons, Qt styles, KWin window decoration styles, colour schemes, wallpapers, sound themes and more.
   

[ Edit ]