The KDE PIM Team is, well, the team that makes KDE PIM. There are a lot of different roles that can be played within KDE PIM development. Some of them are documented below. We ignore the sort-of obvious ones of "coder" and "documenter".
Since we want a polished and professional release every time there's lots of little jobs that need to be done. Some of these jobs are ideal for people just getting started in KDE development. Others -- documentation, screenshots, promotion -- are open for everyone who doesn't want to be a developer. All of this is part of the drive to make KDE PIM a high-quality release. It all fits in the KDE Quality Team framework. In fact, the KDE PIM Quality Team is the first large-scale team to be formed and is serving as a test-bed for Quality Team development.
A long list of KDEPIM Quality Team job-titles follows. There are also some much larger jobs -- like developing new applications -- that we would like to see done.
Writing documentation involves keeping up with development versions of different applications, 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 Documentation Coordinator could play an important role in improving the documentation.
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 don't 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.
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.
Bug lists for various KDE PIM applications:
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. A dedicated Screenshot Maker 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.
On the KOrganizer homepage we offer some calendars for the "hot new stuff" feature of KOrganizer. These are e.g. school holidays, the KDE release plan etc. These have to be kept up-to-date. In addition to that we sometimes get external contributions which have to be reviewed and put on the homepage. There also is some data in the holiday plugin which is in need of maintenance. This job doesn't require to compile KOrganizer from SVN. All it needs is somebody spending some time on updating the calendar data if needed and communicating with people contributing calendar data.
Each source file in SVN should have a complete list of copyright holders and an appropriate license. This information isn't 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.
Most of KDE PIM is well-covered in terms of license, but KMail is still a bit of a mess and some authors need tracking down.
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.
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. That's a very important task.
These are larger jobs -- whole new applications -- that we would like to see in KDE PIM. The current KDE PIM developers would be glad to offer assistance and guidance to anyone willing to pick up the task -- but they are too busy with the existing applications to write the entire applications themselves.
Short Description: Kontact lacks a whiteboard where several people can connect to a common destination and draw/write on the same canvas with everyone seeing the updates in (near) realtime.
Long Description: Groups collaborating virtually frequently wish they could just jot down a quick drawing to show the others what they have in mind, just as they would do on a whiteboard in a meeting room or the back of a napkin in a pub. This functionality is available in applications such as MS Netmeeting and Aethera, but not currently in KDE/Kontact.
To fill that void, one could start out with a drawing application already implemented within KDE, such as KPaint, Kolourpaint or Krita and extend that with the ability to export the canvas via the rfb protocol used by vnc. The rfb protocol was designed for exactly that purpose and is a tried and true solution with viewers available for all platforms including handhelds and embedded devices. There is already code to provide rfb server functionality in the desktop exporting feature of KDE (krfb), so no vnc server code would need to be written. It should be a matter of informing the vnc lib whenever the canvas changes to calculate differences and send them across the wire.
Code would need to be written/reused to connect to a server, maybe discover servers on a network, manage bookmarks of servers etc.
Client functionality could be either integrated into the paint program as well, or provided by a separate multi-purpose vnc viewer part, based on some already existing vnc viewer for X. Alternatively the java viewer could be used in a khtml part.
This task would be ideal for someone with a bit of programming experience but not necessarily much knowledge of the KDE libs or QT wishing to contribute. Hopefully most of the functionality should already be there, but needs to be plugged together and made to work. It is fairly self contained and since nobody is working on this yet would not step on anyone's toes.
In order to track this job more effectively, it has been entered into bugs.kde.org as bug 81460.