If you got this far reading this document, you're probably interested in helping with TDE documentation. If so, welcome aboard! We're always happy to have new contributors, and whatever your skills, you can help make TDE even better.
To write documentation, there are only three things that are absolutely necessary: some English knowledge, knowing what you want to document, and access to a relatively recent version of the application you want to document.
Notice that the list of requirements does not contain a requirement that you learn DocBook, or any of the other tools we use. We're very happy to receive documentation written in plain text. We would much rather have the content and have to add formatting than have no content at all.
All TDE documentation is originally written in English, so you have to be able to write English to a reasonable level. That said, you don't need to be a native speaker, and you don't need to write word-perfect English. There are native English-speaking proofreaders on the documentation team, and we would much rather have some documentation that needs a little tweaking, than no documentation at all. If you don't feel comfortable writing in English, you might like to contribute to one of the TDE translation teams. You can find more information about translation on http://i18n.kde.org.
If you're a fluent English speaker with an eye for detail, you
might be interested in joining the proofreading
team. Just drop an email to (kde-doc-english AT kde.org)
if
you'd like to help the proofreaders.
TDE is a very large project, with many different parts and programs. Because of this, it can be hard to know where to start if you want to contribute. There are a few rules of thumb that can help you decide what to write about:
Find a topic that you'll enjoy writing about; It will increase your motivation and help you to produce better documentation.
Write about an application you know well. You'll be able to spend more time on writing and less time trying to work out how the application works. On the other hand, documenting an application can be a good way to learn about how it works, especially if you like a challenge!
If you are looking for an application to document, or just checking the status of the application you want to work with, the TDE Quality Team Wiki contains lists of applications, organized by modules, and their general status, including documentation status, and who is working on it. Not all modules and applications are included or up to date, but it is certainly worth checking.
If you start documenting one of the listed applications, please add your
name to the wiki pages as well. But If you just can't find an application to
work with, write to (kde-doc-english AT kde.org)
and ask for
suggestions. There's always something available to do, but there's no obligation
to work on a particular application. Also, contributing to a document doesn't
force you into keeping that document up-to-date (although if you can do that,
it's very welcome!).
Another place to check is the TDE bug list at http://bugs.trinitydesktop.org. This is usually more detailed than the wiki, and provides a place to list specific small changes that are needed to documents. These are often nice small jobs to get you started contributing. A set of quick links to ready made queries are available from the Documentation Project's http://i18n.kde.org/doc/current.php page.
It is also helpful to the team to file more bugs like these above. You will need a bugzilla account, and a recent copy of TDE. Simply open an application, choose ->. Then just read through the document, following along in the application. TDE applications are a moving target to document, and sometimes the documentation has not yet caught up with a change to the interface or behavior of an application. Feel free to file bugs for any of these issues you find, in order of urgency:
Inaccurate information about how an application works
For instance, if you previously needed to save changes to a file before they take effect in the GUI, and this now happens automatically, text referring to manual saving should be removed, or it will confuse readers.
GUI options or menu items (or sometimes, entire dialogs)
This often happens in configuration dialogs, when new items are added, a new grouping of existing options may be created.
New Features that are available and are not yet documented.
To make sure that the documentation you write is up-to-date, you'll need to run a recent version of the application you are working with. This normally means a recent beta version, a version of your application compiled from sources or a version of TDE compiled from sources in the Subversion repository. If you think that compiling from sources is too burdensome, and you cannot get some recent beta packages, there are still some interesting possibilities to work around this requirement:
Write about a stable application: there are many apps with a stable interface which are still lacking good documentation. In this case, the last stable version provided by your distribution will be sufficient to write about it, no compiling required.
Using a remote desktop connection to preview the development version is
an ideal solution to this problem. The FreeNX terminal server technology
enables decent desktop performance even with dial up Internet
connections. We are planning to offer this service to TDE documenters, but
the infrastructure is not yet in place (as of May
2005). You may ask the (kde-quality AT kde.org)
mailing list
about it, if you think this is the way to go.
If you want to try out building TDE from sources, the TDE Quality
website provides
a detailed,
step by step building guide. You can find even more information at the
TDE Developers Website.
If you face any problems in the
compiling process you can't solve by reading the building guide, don't hesitate
to as for help on (kde-quality AT kde.org)
.
Would you like to comment or contribute an update to this page?
Send feedback to the TDE Development Team