我們都同意，需要大量的 KDE 應用程式加入。但也有很多現有的 KDE 應用程式需要你的幫助。
KOffice 和 KDevelop，儘管受到高度讚賞，但只有極少數開發者，所以你可以從這裡開始。不需要成為 KDE 核心開發人員才能提供協助。KDE 是高度模塊化的，所以你可以完美地改善一個地方，而不了解整個系統如何運作。
如果有需要協助的應用程式，您也可以在 kde-devel 詢問。使用 KDE 最新版看看有否需要協助的地方。主題生成器？konsole 計畫編輯器？改善遊戲？這些專案總是有小功能缺失。去實現它吧！
你是熟悉或關注於特定領域嗎？查看是否有相關的應用程式，可以獲得您的幫助。或者自己寫一個。KDE 需要更多非 geek 導向的應用程式。
The Konqi for some people SDK is at ftp.kde.org/pub/kde/devel/konqi_sdk.tar.bz2
It was posted to artist.kde.org before that site ceased to be updated.
Further images are on KDE merchandise.
您需要了解 C++。閱讀 Qt 的教學和瀏覽 Qt 的文件來熟悉 Qt。然後閱讀KDE的教學和瀏覽架構和文件。您還可以閱讀KDE的書籍。但你不用熟悉整個 KDE 的架構成為 KDE 開發者。使用 KDE 的技術是很容易的，所以集中在你真正需要的，你可以以後再學習其他部分。KDE TechBase 和 doc.qt.nokia.com (或者在您的 $QTDIR/doc/html) 是寶貴的資源，要善用它們。然後瀏覽原始碼，尋找範例目錄，看看其他應用程式的寫法。讀寫程式碼是最好的學習方法。
請見匿名 SVN 頁面。
[miscellany] global-ignores = *.moc *.moc.cc *.moc.cpp config.log config.status \ config.cache *.gmo .deps .libs SunWS_cache *.lo *.la *.rpo *.la.closure \ *_la_closure.cpp *_la_closure.cc *_la_closure.cxx *.all_cc.cc *.all_cpp.cpp \ *.all_C.C *.all_cxx.cxx *_meta_unload.cc *_meta_unload.h *_meta_unload.cpp \ *_meta_unload.C *_meta_unload.cxx index.cache.bz2 .memdump Makefile.rules.in \ Makefile.calls.in Makefile.rules Makefile.calls autom4te.cache *.kidl \ *.o *.lo *.la #*# .*.rej *.rej *.pyc
And to make svn diff ignore whitespace, and print function names:
[helpers] diff-cmd = /usr/local/bin/_svndiff
with the following in /usr/local/bin/_svndiff:
#!/bin/sh exec /usr/bin/diff -b -u -p "$@"
Don't forget to make /usr/local/bin/_svndiff executable.
核心開發者 Waldo Bastian 在郵件中解釋：
It is important to know that but don't be afraid. Usually, things work very well. In 5 years, it has only happened once that a developer had his work put kept in KDE while he wanted to remove it.
See full article at Contribute > Get a SVN Account.
Send a mail to sysadmin (at) kde (dot) org justify why you need SVN access. Make sure to specify your full name and e-mail address, if the From field in your mails doesn't specify them.
Please include the name of your bugs.kde.org account, if non-existent please create one so that it can be given usual developer rights. Closing bugs.kde.org reports with keywords in commit comments only works if the email address of your SVN and bugs.kde.org accounts match. You can change your bugs.kde.org address in the Bugzilla user settings.
You can currently choose between the standard SVN protocol (https using a password) and the svn+ssh using an ssh key. If you choose https, send also an encrypted password (for instance using useradd dummy ; passwd dummy ; grep dummy /etc/passwd /etc/shadow) and see also the tutorial. If you choose svn+ssh, send a public ssh key instead (e.g. ~/.ssh/id_dsa.pub)
See also #How do I create a SSH key?
If you are contributing to an application that is not yours, it is a good idea to first submitting your coding as patches to the author and let him apply them. If the author is not maintaining his application, you might become the new maintainer...
Although there is no restrictions on SVN rights, we expect you not to mess up other developers' code without their consent. You must also respect the feature freezes of the release schedule (published on developer.kde.org)
A detailed list of rules you should follow when committing to the KDE SVN repository are listed in the KDE SVN Commit Policy.
第一步，我們可以把它放在 playground（=kde-alpha）。當準備就緒時，請您的應用程式移動到適當的 KDE 套件包或 extragear 模塊。
This is no longer possible with Subversion. Maybe in the future, if the server is upgraded and allows that.
它包含 Qt 的 Ruby、PHP 和 C# 綁定、KDE 的 Ruby、C# 和 python 綁定以及讓非 KDE 的應用程式作為 KPart 嵌入的 XParts。請見 TechBase 的綁定頁面 。
不，playground 不會發布套件。kdereview 和 extragear 也是相同的：他們沒有凍結和發布。但如果你希望你的應用程式轉移到套件包，請在 beta 發布之前先詢問。
Yes, check the Building 2 Versions documentation.
kde-config 或在所有 KDE 程式使用 --version 參數。
任何一個您都可以使用。它們是二進位相容的（往前和往後）。但 qt-copy 修正幾個 Qt 最新版中的 bug。特別是從 qt-copy 建構，要注意補丁腳本。
Checkout the top-level dir with 'svn co -N /modulename', 'cd modulename', 'svn up admin' to get the admin/ dir and then finally checkout the dir you want with 'svn up subdir'
For instance, to get only reaktivate from playground/utils:
svn co -N /playground/utils; svn up reaktivate
Then compile as usual.
The same answer applies to the question "How do I get a single language out of kde-i18n?".
If you don't know the name of the directory you want to check out, you can browse websvn.kde.org to find it.
kdesdk/scripts/svn2dist 是一個從 KDE 原始碼樹中提取應用程式的腳本，並打包為一個獨立的應用程式。
If you reported a bug that is fixed in a new release of KDE but is still reported as open, you can close it. It might happens because your bug is the same as another one, or simply because the developer fixed something without noticing that it would correct your bug.
You can do that from your Subversion commit. To do so, append to your commit message a line like this:
Where XXXXX is the bug report you want to close. If the report you're closing is adding a new feature, you can use FEATURE instead of BUG.
Managing a bug list is a huge task for the developers and they usually have a lot of bugs listed, some being fixed already without their knowledge, some being unreproducable, some without enough information to be corrected, etc. If you can help managing and updating the list of outstanding bug, you will be gladly welcome. And you will receive an even happier welcome if you provide a patch.
SSH makes use of two keys: a private key and a public key. You should keep the private key secret at all times and only place it on machines over which you have direct control. Public, shared, and community machines are not suitable environments to store SSH private keys. Take action to help prevent theft of your SSH private key data. Setting a password on your SSH private key will help reduce the risks involved with private key theft.
Generate a key pair for each major location you work from. This helps to reduce the impact when your key gets stolen. When someone obtains access to your private key, your key can be abused in attempts to compromise KDE servers. Well known open source projects have been compromised this way in the past, YOU must help us to make sure that this doesn't happen with KDE servers as well. For that reason it is important to notify sysadmin (at) kde (dot) org immediately when you notice that someone may have had access to your private key for example when a computer on which it was stored has been hacked or infected with a virus, worm or trojan.
If you choose to make a backup of your SSH private key data, please ensure that any such backup is stored in a secure manner as well.
For the practical part, the following command can be used to generate a SSH private/public key pair with
ssh-keygen -t dsa
This will create a private key as ~/.ssh/id_dsa and a public key as ~/.ssh/id_dsa.pub.
There are times when you may want to use a key of a different name to the default, perhaps to use seperate keys for different projects. To let SSH know which key you want to use for KDE.org, you can keep a list of servers and their corresponding keys in ~/.ssh/config. For example,
Host svn.kde.org IdentityFile ~/.ssh/id_dsa_kde
In order to use SSH to access KDE servers you need to send your public key to sysadmin (at) kde (dot) org.