These policies apply to KDE developers and it is expected that all persons with a KDE SVN account follow these policies. The SVN commit policy is the most important one. Persons working on libraries (kdelibs mostly, but central libraries in other SVN modules fall under this as well) should read the library documentation policy (and the apidox howto as well).

These policies apply to KDE developers and it is expected that all persons with a KDE SVN account follow these policies. The SVN commit policy is the most important one. Persons working on libraries (kdelibs mostly, but central libraries in other SVN modules fall under this as well) should read the library documentation policy (and the apidox howto as well).

−

*[[SVN Commit Policy]]<br />Rules for commits to the KDE SVN repository. The three golden rules (make sure it compiles, follow existing coding style, use descriptive log messages) and 18 more rules to follow to make sure that your SVN commits are the best they can be.

+

*[[Policies/SVN Commit Policy]]<br />Rules for commits to the KDE SVN repository. The three golden rules (make sure it compiles, follow existing coding style, use descriptive log messages) and 18 more rules to follow to make sure that your SVN commits are the best they can be.

−

*[[Licensing Policy]]<br/>Files in KDE SVN cannot be arbitrarily licensed. This policy explains what licenses are allowed where in the repository. In short: use LGPL for libraries, GPL or BSD for everything else.

+

*[[Policies/Licensing Policy]]<br/>Files in KDE SVN cannot be arbitrarily licensed. This policy explains what licenses are allowed where in the repository. In short: use LGPL for libraries, GPL or BSD for everything else.

*[[Library Documentation Policy]]<br />Libraries for (re)use should be completely documented. This policy explains why they should be documented as well as how to document things, and what style to follow. The apidox howto contains more technical information on writing documentaton for libraries.

*[[Library Documentation Policy]]<br />Libraries for (re)use should be completely documented. This policy explains why they should be documented as well as how to document things, and what style to follow. The apidox howto contains more technical information on writing documentaton for libraries.

−

*[[Library Code Policy]]<br />KDE Library API and Code should follow some conventions that are explained in this policy

+

*[[Policies/Library Code Policy]]<br />KDE Library API and Code should follow some conventions that are explained in this policy

−

*[[URI & XML Namespaces Policy]]<br />Sometimes KDE technologies and applications needs URIs, such as for XML formats. This policy describes practices for that, and how to allocate URIs.

+

*[[Policies/URI & XML Namespaces Policy]]<br />Sometimes KDE technologies and applications needs URIs, such as for XML formats. This policy describes practices for that, and how to allocate URIs.

== Procedures ==

== Procedures ==

Line 19:

Line 19:

Whereas policies are normative for individual developers -- that is, they describe how developers must behave -- procedures describe how 'the KDE project' as a whole has chosen to behave. We describe what we will do under certain circumstances and why.

Whereas policies are normative for individual developers -- that is, they describe how developers must behave -- procedures describe how 'the KDE project' as a whole has chosen to behave. We describe what we will do under certain circumstances and why.

−

*[[Security Policy]]<br />How security problems can be reported to security@kde.org and how the security team responds to security issues.

+

*[[Policies/Security Policy]]<br />How security problems can be reported to security@kde.org and how the security team responds to security issues.

Revision as of 17:18, 8 September 2006

There are a couple of written and unwritten rules KDE developers ususally adhere to. The following documents summarize some of these policies. The list is still incomplete. If you are interested in helping out with formulating the KDE policies or would like to discuss them please use the kde-policies mailing list which was created for this purpose.

Policies for Developers

These policies apply to KDE developers and it is expected that all persons with a KDE SVN account follow these policies. The SVN commit policy is the most important one. Persons working on libraries (kdelibs mostly, but central libraries in other SVN modules fall under this as well) should read the library documentation policy (and the apidox howto as well).

Policies/SVN Commit PolicyRules for commits to the KDE SVN repository. The three golden rules (make sure it compiles, follow existing coding style, use descriptive log messages) and 18 more rules to follow to make sure that your SVN commits are the best they can be.

Policies/Licensing PolicyFiles in KDE SVN cannot be arbitrarily licensed. This policy explains what licenses are allowed where in the repository. In short: use LGPL for libraries, GPL or BSD for everything else.

Library Documentation PolicyLibraries for (re)use should be completely documented. This policy explains why they should be documented as well as how to document things, and what style to follow. The apidox howto contains more technical information on writing documentaton for libraries.

Policies/URI & XML Namespaces PolicySometimes KDE technologies and applications needs URIs, such as for XML formats. This policy describes practices for that, and how to allocate URIs.

Procedures

Whereas policies are normative for individual developers -- that is, they describe how developers must behave -- procedures describe how 'the KDE project' as a whole has chosen to behave. We describe what we will do under certain circumstances and why.

Policies/Security PolicyHow security problems can be reported to security@kde.org and how the security team responds to security issues.