DRAFT -- Contributing to the API of QtWebKit -- DRAFT

If you would like to contribute new functions or classes to the API of QtWebKit, then we ask you to discuss your changes with the rest of the team. There are certain restrictions with regards to binary and source compatibilty as well as rules for consistency in namings and concepts that require us change the existing process of contributing code to WebKit slightly for these kind of changes.

The process

1. Create a new bugreport in Bugzilla describing your enhancement. Please use the following template for creating the bug: ​http://webkit.org/new-qtwebkit-bug
2. Make your bug block our meta-bug for pending API enhancements for the next release: ​QtWebKit 4.7 Pending API
3. Read the sections below about the principles and conventions we apply when designing the API.
4. Discuss with us on IRC in #qtwebkit and on the public mailing list at ​http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt.
5. After reaching an agreement upload your patch(es) and mark them for review, using the standard process of contributiong code: ​http://webkit.org/coding/contributing.html
6. The WebKit reviews will then review the code, after the API has been reviewed in step 4 above.

API Style, Conventions and Principles

For QtWebKit we follow the same guidelines that are used for the Qt API. You can review the entire the style guide at ​http://qt.gitorious.org/qt/pages/ApiDesignPrinciples

To the users of QtWebKit we promise to maintain binary and source compatibility between minor releases. We share the same policies with KDE and Qt, which are summarized on the KDE website at ​http://techbase.kde.org/Policies/Library_Code_Policy. Another recommended read is the guide about what kind of API changes are binary compatible and what can be done to work around the imposed limitations: ​http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++