Contribute/Quality Team/Essay

Proposed for moving to community.kde.org

It has been proposed that this page should be moved to the community.kde.org wiki for the following reason:

Archive, Internal community team

Introduction

In short, the task of the KDE quality team is to detect the loose ends in an application, and try to tie them together. The team objectives are similar of those of a project manager in a commercial organization. The main challenge of the team member is to interact with different areas of the application development, as there is much to learn.

But that does not mean you have to know all these areas: you can focus in one specific point of the application, like answering users questions, writing articles, documentation, creating artwork, whatever you want! Just find a lacking area and start working! After you feel you have the time and will to try something new, come back here to check the information available for that specific task. This guide's job is to organize all practical information to help you.

There is also a version of this guide at the KDE Wiki Site (wiki.kdenews.org), but it is not updated anymore. If you discover errors or if you know how to make this guide better, feel free to modify the KDE repository (if you have a SVN account), or e-mail the quality.kde.org Webmaster with your changes.

Documentation

Writing documentation is a great way to start helping your application and the KDE project. If you decide to help out, your words will be translated to all languages covered by the KDE translations teams, and you will be helping thousands (millions?) to understand better their desktop and applications. Anyone with reasonable English skills and good knowledge of an application can help.

Modifying the documentation of an application involves: having your local KDE sources working folder, locating the files you want to work with, opening them, adding your improvements and sending the projects your modifications. To quickly learn how to do this, please check the Why Build and Maintain a KDE SVN Working Folder? guide.

Documenting an application involves help documents and context help. Context help is the quick pop up containing a short explanation you get when using the context help hotkey (usually Shift+F1) and clicking on a widget. This help is limited to the objective function of that widget, but it may be exactly what the user was needing to know, thus avoiding the need to open the full help system.

Help documents, (or an application manual, the set of help documents for an application), offer more comprehensive help about an application, and can include detailed information, examples, links to other documentation, information about menu commands, dialogs, screenshots, etc... Since the documentation is translated to many different languages, all the references in the help documents to screenshots, menu items, widgets or dialogs have to be translated in synchrony with the actual application and screenshots. To address this, the document format and tools used for help documents are designed for multi-lingual documents. Context Help: Whatsthis

Context help is inseparable from the dialogs and widgets, as they are the target of the context help. In fact, in order to write context help, you have to touch programming or programming tools. Indeed, the context help is a property of widgets. In object oriented programming, a property can have different values, and behave differently depending on the value. In Qt/KDE programming, the name of the property is "whatsthis", and its value is the text the context help is going to display.

Fortunately, this task is usually not very difficult, as there are good tools to deal with user interface design, and better, you will use the knowledge acquired here later when dealing with user interface in general. Using the Qt framework (Qt is the base of KDE technology), it is possible to separate code and user interface. You have two basic cases here: the user interface is written with the general code of application (usually .cpp files) or in Qt Designer files (.ui files: it is a XML document). The second case is the best to start with, as it is simpler to work with. If you don't have Qt Designer installed, you can do so by installing the devel package of Qt from your distribution or the Qt Designer package (if your distribution has more fine grained packages).

Here you can find a detailed guide for writing whatsthis using Qt Designer and working directly with the source code: WhatsThis Tutorial, by Aaron J. Seigo. Application Help Or Manuals

The KDE help system is based on the docbook format. This format and related tools make it easier to translate and to maintain the documentation for the whole project. The format was specifically designed by the OASIS group with technical documents in mind, and it is a XML based specification. The documentation for each module can be found in the doc folder.

Writing the documents in docbook format is highly recommended. But if you want, you can start improving the documentation now, and learn the docbook format later. but if you do so, please use text only format (ASCII). This way it will be easier for the documenters to transform it to docbook later.

Do not start from scratch if documentation for your application exist: try to improve it. Explain all commands, the main window organization, in sum, all aspects of the interface. A more complete list of what to write about is in the Questions You Should Answer When You Document KDE page, from the KDE Documentation Team Website.

Try to be user friendly, and try to write to the public of your application. Don't forget to proof your text for American English. You can find these tips and consistency rules in The KDE Style Guide. It is short, simple and obligatory. Its purpose is to maintain a uniform level of quality in the documentation.

For writing using the docbook format, the recommended place to start is the The Crash Course to Docbook. It will give you the basic knowledge to start. For more KDE specific stuff, please refer to The KDE Markup Guide to write your first document.

To help you in this process, you can use many tools. Kate is recommended for writing XML documents, and it is specially useful if you install the XML plug-in from the kdeaddons module. Don't forget to enable it after installing, by opening Kate, clicking the Settings menu, and the in the Configure Kate... menu item. Click the application/plugins icon inside the left side tree view, and check the Kate XML Completion and Kate XML Validation boxes. Now you will be able to see the XML menu when using Kate. If you are editing a docbook document, click the XML menu, then assign meta DTD and selecting the KDE docbook DTD, and you will transform Kate in a powerful docbook editor.

User Interface

User interface is a very wide subject, and very subjective too, as something obvious to someone is absurd to others and vice versa. Therefore, don't assume, argue clearly, stating your logical steps. Your main tool discussing it are objective reasoning and good sense.

It is easy to perform a quick user interface analysis, but it is hard to convince people to change the interface. A good, convincing analysis can gain much if it incorporates information from the KDE guidelines, competing program and operational system analysis, general design principles found in many books, user testing or individual (anecdotal) feedback. It is a volunteer project, and even if everybody agree with you, someone has to implement it. The good part is that given the Qt/KDE Framework, there are some things even a non developer can implement.

The KDE Usability Mailing List is very active and a good place for discussing your ideas. If you are already an usability expert, please check OpenUsability.org, a project that brings open source developers and usability experts together, and is collaborating closely with KDE. Before Starting: Guidelines And Useful Documents

You don't need to read the documents listed here to perform simple tasks, like verifying shortcuts' coherence with other KDE programs, making simple logical analysis or presenting anecdotal usability feedback and opinions. More knowledge is required to perform a more profound study, but you will find all the information needed easily.

The basic KDE documents on usability are KDE User Interface Guidelines (design standards) and KDE User Interface Guidelines (design principles). The first is a comprehensive collection of standards for KDE applications, or in other words, down to earth conventions and rules for immediate use. The second is a general set of useful principles for designing user interface, and a good place to start studying.

There are books and other good sources of information about this fascinating subject, many of them online. The KDE Usability Website has an excellent collection of usability information, including windows, apple and gnome user interface guidelines, usability course notes and even an online book on the subject. Analysis

You can perform very useful analysis using the KDE user interface guidelines and other usability material. Suggestions on what to cover include:

KDE User Interface Guidelines (design standards) conformance: It sets standards for the maximum dialog size, exiting applications and closing documents, capitalization rules, among others. It is really a very good to start reviewing the user interface, as it covers all mains aspects of common applications: dialogs, menus, toolbars, shortcuts and accelerators, drag and drop, the status bar, etc... All KDE application should at least follow these standards, and below we assume they do.

Shortcut keys coherency and accessibility: to reduce the learning time required for an application, shortcut keys should, first, follow as closely as possible the scheme already used by other KDE applications, and second, follow the scheme used by similar applications. One good example is making Konqueror use the same basics hotkeys as Mozilla or Internet Explorer. If you don't agree with a shortcut used in widely in KDE, don't make your application different, try to persuade other people to change to your approach instead. Another good target is to minimize the use of more than two keys at the same time for the most important functions, as handicapped people may have difficulties accessing commands with tree or more keys at the same time. Verify if a commonly used action lack a shortcut, and do some research on what key should be used for it: consistency is the main priority, look what other KDE or similar applications do.

Dialogs review: The basic rules are the user should not be required to read about things unrelated to his current task or decide about things he does not want to. He should get things done easily, fast and with minimum data entry. Worthy points to review are if the dialogs are clear, if the widgets are displayed in a logical sequence, avoiding unnecessary information, if the information is presented in relevance order, if related options are grouped together, either in a simple dialog or a more complex multi-tab dialog. You can use the KDE User Interface Guidelines (design principles) as a guide, checking if its principles are being followed. The Configuration dialogs are constantly being redesigned, because new options are constantly being added and obsolete ones removed, making them obvious targets for review. Examples of improvements are the Panel Configuration Dialog Redesign or the Clock Applet Configuration Dialog.

You have a powerful tool to help you improving the dialogs: the Qt Designer. Using the Qt framework, you have two basic option to write dialogs: a text editor, as writing the general code of application (usually .cpp files) or the Qt Designer(.ui files). If the dialog you are reviewing was developed using the Qt Designer, you may redesign it yourself, even if you have little knowledge of programming. Search for all .ui files among the source files of your application. Open them (you can use the faster ui file viewer) to see if it is the desired dialog. If you cannot find the dialog you are analyzing, it may be because it is hand coded or a shared dialog from KDE libraries (module kdelibs from KDE CVS).

Even if the dialog was written by hand inside the code (no .ui file), you can make a proof of concept using the designer, a mock-up, to show other people your ideas and state clearly the seriousness of your proposal. Trolltech makes available as part of the Qt Designer Manual, a small guide on how to create dialogs using the Qt Designer that should enable you to create simple dialogs or mockups. Usability Tests

An example of empirical test is your own experience with the software. The challenge is to transform it from subjective opinion to objective facts people can work with. One idea is to perform a simple user test, you being the user, setting tasks to perform, documenting the process, taking notes of the problems you find and providing solutions. Most of your conclusions can be used in a way or another to improve the application. But it can be even more useful if the test could be extended to more people, as you are probably not a regular user: you have more intellectual curiosity, different habits and are more capable of working around design flaws. To prove that, the evidence is that you are reading these lines...

It is easy to perform a usability test with other users, and it may result in major improvements in your application. Select the most important tasks to perform with your application and find some friends to perform them. The people you select should fit the profile of the user the application targets, so make a small questionnaire about people's background. More information and tips on how to perform an usability test can be found in the short and useful Infodesign usability testing page (also in PDF format). Employ a chronometer to record the time taken to perform each task and take note of all pitfalls found. Tabulate the data and try to extract conclusions and recommendations. There is invaluable insight and information to be obtained in this kind of test. An example of field test with KDE is the Relevantive Report on KDE usability.

Bug And Wish Reports Management

The main communication tool between developers and users, and the main quality tool is the KDE bugs and wishes database. The database is implemented using the Bugzilla tool for tracking bugs and wishes, developed initially for the Mozilla web browser. Bugs.kde.org is the the web front end implementation of KDE's Bugzilla, and the main place to go when managing bugs, but there are other front ends: the KBugBuster, from the kdesdk module and the e-mail interface, used to add comments, change bugs status, etc...

Many bug reports are filed daily, especially after releases. There are too many to be handled by the developers, so the amount of open reports increases over time. Additionally old bug reports have to be revisited regularly to see if they still apply to the current version. Reviewing the bugs database also give you insight about the most needed features and most pernicious bugs, allowing you to point them, and the developers to actually fix bugs or spend time to add new features to KDE, instead of managing bugs.

Always direct users to the KDE bug tracker system to discuss bugs and wishes, because this way issues will not be forgotten. If the point is a bit more polemic, it is sensible to start a discussion in the application mailing list or in KDE usability mailing list, but instruct them to start by filing the bug, because by searching for similar bugs or wishes they may find answers or insight. Before Starting

To start, open an account on bugs.kde.org if you don't have one. The database records not only the bugs and wishes status, but also related discussions, screenshots, patches, etc.. turning it to a very complete source of information. Please try the following pages at bugs.kde.org, to get used to KDE bugzilla capabilities. The KBugBugster is also useful, but less flexible.

   * Simple search form
   * Advanced search form
   * New wishes/bugs wizard

There are a few fundamental name conventions that you should know:

   * Bug status (UNCONFIRMED, NEW, ASSIGNED, REOPENED, RESOLVED, VERIFIED and CLOSED). (NOTE: Because KDE is missing a team which double checks that bugs are really fixed, the VERIFIED and CLOSED states are not used).
   * Resolution (FIXED, INVALID, WONTFIX, LATER, REMIND, DUPLICATE, WORKSFORME).
   * Severity (WISH, LOW, HIGH CRITICAL).

At the beginning, you will only be able to comment on bug reports which are not your own. Only after acquiring more knowledge on the application and on KDE Bugzilla system, you may ask for rights to confirm bug reports and close non verifiable ones.

You need a current KDE installation in order to be able to test if a bug is still uptodate. This means you should either test with 'trunk', that is the latest development-version of KDE, or the latest branch of KDE. For KDE 3 this is KDE 3.5. Then, you can confirm them, or close if not verifiable. Please refer to the Maintaining your own updated KDE version guide for more information on how to keep an update version of KDE.

Also it is important to have a KDE version compiled with debug information. KDE binaries compiled with debug information are bigger and run slower, but provide invaluable information to the developers when applications crash, as they are able to locate where in the source code it crashed, and sometimes even why. Whenever an application crashes, the KDE crash handler appears. You can now retrieve the backtrace information to add to a bugreport. Managing Reports

The main tool for bug triage is knowledge of your application. You will learn that you don't need to be a developer to have a good understanding of it: reading bug reports and comments about them, writing documentation or working with the application's user interface will do the trick.

You should always start by stating your opinion in the bug reports and letting the developers take the appropriate action. If you feel you are ready to manage bugs effectively, know well the application and have a bit experience with bugzilla, it is time to ask for permissions. The Quality Team mailinglist, the KDE system administrator, or the mailinglist of the application you are working with, are the right places to ask for it. The developers will probably be happy to have someone working with them, and in the end of the day it is your own reputation as a good contributor that is in the line, as developers will still watch what you are doing. Some of the task below require these permissions.

A good way to start is checking if bugs are still valid:

   * Believe the reporter: if you cannot reproduce a new bug, first ask for more context information, then think about closing it or asking to close it.
   * The bug may be triggered by a combination of factors, or the bug may be fixed in the main branch, but not in the stable branch (if so, ask in the bug report for a backport. If it is not doable, the developers will say so).
   * Add any additional information you can give, e.g. backtrace, additional observations, how to (better) reproduce the faulty behavior or simply add with which day's version the bug still appears.
   * If you can reproduce an UNCONFIRMED bug, please write that in the bugreport and change its status to NEW.
   * If a program hangs, you can "kill -SIGSEGV Processid" the process to get a backtrace.
   * Check if the report is filed into the correct product and component category too. KDE is a very modular, and massively reuse code, and sometimes is hard even for the developers to detect in which component the bug is, so be careful. If the report is not already assigned to some other developer than the current component owner, make sure to select the "Reassign bug to owner of selected component" when moving a report. If a report is filed into a category where there is no single maintainer/active developer and you know which developer is responsible or works on the code (a look into the source or reading kde-cvs mailing list can help), you may assign a bug report to him/her directly.
   * Check if a report describes an error already described in another closed or open report: Resolve it as DUPLICATE with reference to the prior report.
   * Check if the same report was submitted more than one time. Please close the identical bug (the one with the highest number) as INVALID and not as DUPLICATE because otherwise they show up wrongly in the most frequently reported bugs statistics.

Browser (Konqueror) bugs are usually very easy to check and there are lots of them:

   * Add "(regression)" to the title if the page was correctly rendered in a previous stable release.
   * It's a good idea to put the site into the title where an error was encountered to ease duplicate spotting.
   * A parallel installation of a Gecko-based browser and Opera can give you an idea how a web page probably should look like.
   * Try to generate a stripped down testcase of a faulty rendered webpage. Add "(testcase)" to the title if a testcase is attached to the bug report.
   * If a webpage doesn't exist any longer or was obviously rewritten and there was no testcase provided, close the report as WONTFIX.
   * If the reporter or a comment mentions that a page works fine in Safari, it can help the developers to note that in the title too.

Check if the severity is appropriate, but if you don't agree, state so in the bugreport. Let the maintainer change the severity, as it is used by them to remind to fix crucial issues.

Check if the title contains a good summary, e.g. feature requests titled "Feature wanted" don't help when glancing over the report list. If a patch is provided add "(patch)" to the title.

Note: Don't use the "Change Several Bugs at Once" feature for moving reports. There is a bug in Bugzilla which confirms every reports which gets moved.

Programming

Even if you have some programming experience, diving into the KDE project can be a bit daunting at first. It is a very vast project and there are many things that you will have to learn before you can really become productive as a developer. And it may take some time too.

So you want to make a start. But where do you begin? How can you find your way in this labyrinth of webpages, mailinglists, files, HOWTO's, etc.? The objective of this guide is to set out a learning path for a would-be KDE developer. These are just suggestions, of course. If you feel are already proficient with C++ or Qt, jump the respective steps. Step One: Brush Up Your C++

C++ is the programming language for KDE. If you don't know the language of if your exposure to C++ has been limited, you should learn it. There are many books on the market that can help you and you will find many on-line tutorials that will teach you the C++ essentials. Get hold of Bruce Eckels Thinking in C++ on the web. It is excellent and it is free.

Using KDevelop as your IDE is strongly recommended, so make your life easy and use KDevelop to help you adapt to Qt and KDE. You will be learning to use KDevelop in parallel with exploring C++, Qt and KDE. Make sure that you have KDevelop 3.0 installed and go to www.kdevelop.org. There is plenty of information there. But start with the KDevelop 3.x tutorials.

A good idea is, after reading some of the information below, building an empty program, just generating an empty KDE project. That will give you a skeleton code that produces standard windows, menu, etc. Examine the code, try to understand it. This is very good first step on understanding the basics of a KDE app. Step Two: Study the Qt Toolkit

Although KDE applications are written in C++ it is nearly all done using the Qt application framework. Qt is a product from a Norwegian company called Trolltech and you can find all information that you need about it on their webpage. Don't miss the most important page for would be developers: Qt Reference Documentation. You will find exactly the same page on your PC if you have a full installation of Qt. Read at least the Whitepaper and browse the beginning of the tutorials. Work Your Way Through The Qt Tutorials

The first tutorial from Trolltech is fun and it will teach you a lot about Qt. Try to make it work using KDevelop and make the changes necessary to turn it into a real KDE project. (You could try to get rid of some of the on screen widgets and replace them by menu options.) Then you can work on the second tutorial and try to turn that into a real KDE application too.

Another use the Independent Qt Tutorial. The Independent Qt Tutorial is a on-line book introducing the different areas of Qt step-by-step with task orientated chapters rich on examples and a detailed discussion of the different areas of the Qt toolkit. Study The Qt Examples

Try to understand the other examples that come with the Qt library. Pick at least one and try to recreate it, starting from a KDE skeleton application provided by KDevelop and typing in the code for yourself. Step Three: Familiarize Yourself With a Real KDE Project

Pick a simple KDE application that you like, any one will do, then go to webcvs find the sources and browse the files that you find there, or download the sources using anonymous svn. Look at the different versions of one file and use the Diff to previous option for this purpose. The fact that you can choose your starting point for a comparison and that you can see the changes clearly using the colored option makes this a great learning tool for understanding the evolution of the code. Pick one area of the application and try to really understand it. Read All Info On The kde.org Sites

Go back to the kdevelop website and read the other articles there on KDE development. Go to the KDE Developer's Corner and discover yet another treasure trove of information. Go to the home pages of your favorite applications (you will find links to these on the KDE Homepage) and see if the developers have put up some specific information that you can use. Some projects will have their own developers pages. Have a look at the KOffice Developers Resources as an example. You should try to find the API documentation for the project on which you want to work. And don't forget the Wiki pages! They are an excellent source of information too. Follow KDE Policies

If you are willing to contribute code to the KDE project, it is important to know its policies, understand the role of the application maintainers and the release schedule freezes. You will be working inside project driven by volunteer work, where the doer usually decides the best implementation. The KDE Development Policies page lists the rules to be followed by KDE contributors. There are Commit policies, licencing policies, security policies, and library documentation policies. If you have any comments or doubts about these policies, please direct them to the kde policies mailing list.

To get a feeling for what is going on and what the current problems are, who is who and what they are working on, you should subscribe to a couple of mailing lists. Don't forget to visit the archives to get some historical perspective and to get an answer to your many question before you start asking for the obvious. Step Four: Become an Active Bugbuster

Go to bugs.kde.org, register and use the querytool to find the open bugs for your favorite application. Find an annoying bug and start hacking. Be sure to work on a recent version of the application? You can check very quickly if that part of the code is still up to date with webcvs. This is the right moment to build an unstable-version, either from SVN or from a daily snapshot. Check the Junior Jobs for a list of tasks related to open bugs or wishes that are marked for newbie developers. These tasks are usually a great way to start, as the developers or maintainers are explicitly telling you that you are welcome to fix the bug or implement the wish, and at the same time, the task should not be too complex.

After all of this you will probably be very close to making your first contribution. So if you have found a way to solve a bug, or to advance your project in some other way, adapt the code, post your patch, cross your fingers and hope that it will get accepted.

If you have doubts about helping out KDE, you are welcome to post them in the kde-quality mailing list. To support new contributors is the main goal of the project, so feel free to ask anything related to start helping KDE. For more technical programming doubts, use the application development mailing list, or in its absence, the the kde-devel mailing list.

And don't forget that after reading this you feel that it may be too much and too complicated for you, that there are other ways in which you can help. Visit the KDE Quality Team to find out what else you can do.

Communication And Promotion

An open source product is a result of voluntary work, and the key to its success is the ability to attract new volunteers. Widespread use means usually more probability of attracting prospect contributors, developers, documenters, translators, individuals or part of a corporation or government into contributing. To promote your application, you can write an submit to news sites articles or guides showing interesting features or tips, write HOWTOS (a small guide for explaining how to perform a specific task), submit previews of future features available in the SVN version.

But even if your application is extensively deployed, this does not automatically means that you will attract people who test beta software and file bug reports, and eventually, people who could join the developers, the quality teams, the translators or the documenters. The first step is trying to be newbie friendly, and to educate newcomers. For instance, directing users in mailing lists to the right sources of information, in a friendly manner is a step in this direction. Lists are potential sources of new contributors, and building a strong community means teaching them they can act to improve the software they use.

Lowering the the barriers to contributing can lure more people to walk the first step. The kde-look.org website makes this easy by allowing people to quickly post their work and receive feedback. Some new contributors can go a long way with feedback, good information and some trust. The kde wiki site (wiki.kdenews.org) is an excellent tool to let people formalize discussions and suggestions. Sometimes, the developers refrain from discussing issues with users because most of the messages and suggestions are naive, because there is already a tool to track issues (bugs and wishes: the KDE bugzilla implementation, and because they may be busy implementing features or fixing bugs. The KDE quality team can fill this gap and organize the users feedback into meaningful proposals. Interacting With Users

Linux is growing into mainstream acceptance. This is both an opportunity and a challenge.

The challenge is to communicate with more and more users who have a different background. They are used to pay for software and expect the software house to do all the work and complain when something is wrong. Many of them will be less than helpful, and simply won't understand the restrictions of open source development, but this is a natural initial behavior.

The opportunity is to use the new flux of people to improve KDE, in any form. Also, users sometimes bring valuable feedback in confuse or improper way. Further dialog with the user can clear the issue, become a new bug or wish report or add valuable comments to existing bug and wish reports, turning the rant into useful information. Obviously, the best way to do it is to instruct the user to fill the report himself. Filling a bug is the first step for a kde contributor, a very valuable step. Every new user for bugs.kde.org (KDE bugs and wishes database) is a small victory, as the user started to understand what free software is about.

The main channel of communication with users are the user mailing list for your application, or in the absence of one, The KDE general users mailing list, or The KDE linux mailing list. Subscribing to these mailing lists is recommended. Other sources of user feedback are The KDE forum and The KDE wiki site. These channels are also a good place to spot potential contributors to KDE. Point them this guide and the KDE Quality Team mailing list if they are interested.

Keeping your application web page up to date with HOWTOs to perform the most complicated tasks, frequent asked questions (FAQ) responses, a summary of features and capabilities and recent news and articles also help. This gives a professional feeling to the application, implies that the application is actively maintained and offer good services to users. If your updates to the documentation did not make the KDE release schedule, post it in the application website. There is a tutorial on how to write a web page for KDE.org new layout. Promoting Your Application

Linux is still in his infancy in terms of desktop deployment. Most people probably never tried your application, so it is important to promote it, in order to compete in market. Promotion is fundamental, as it not only increases the probability that your product is considered as a valid option, but it helps avoiding dangerous pre-concepts and myths.

One of the best ways to promote your application is to submit articles to news sites. The first and obvious choice is The KDE News Site (The Dot), but there are others sites where you can send articles. It is even useful to submit the article first to a news site and the submit a link in The Dot, as they give more importance to exclusive material. Your article can be a tutorial or walktrough (explaining how to perform certain tasks, better yet if in a graphical way), a preview (show features of an upcoming release), a test (user interface test, a benchmark, etc...) or a review. Present detailed information and screenshots, and compare similar software if applicable. There is always something to write about.

You can send articles or news (links). Articles are original material you wrote, and news are links to stories you consider good publicity for your application or KDE.

To learn more about how to work with the media to promote your application, read the Media HOWTO. Interacting With Other Quality Team Members

Sometimes you or other members of the KDE Quality Team will need help to do something for the first time, or simply would like some peer review before proposing a change, posting an article, HOWTO or web page or writing a new doc. The idea is to help each other as we go, as nobody is a specialist in all areas, and there is a wide range of actions for the KDE Quality Team. So if you have any doubt, want to post a draft and receive feedback, the main tool is the KDE Quality Team mailing list.

One example of this interaction is this guide. This guide was originally written by Carlos Woelz, but the idea is to update it frequently with experiences and tips from the Quality Team members. A copy of this guide will always be available at the KDE wiki site for modification, and the website will be synced with wiki in regular intervals. Your experience is important, please correct any mistakes you find and add additional tips and information as you go.

One of the goals of this project is to provide step by step guides for new contributors. If you document your steps as you perform tasks not covered yet, you can easily add a new one.