Communication And Promotion Guide

1. Introduction
2. Documentation
3. User Interface
4. Bug And Wish Reports Management
5. Programming
6. Communication And Promotion
   • Media

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.

[ Edit ]