Feature planning for QtWebKit

Overview

The Qt port of WebKit has an open and public requirements management system, hosted in the Qt bugtracker JIRA. Everyone in the community can create feature suggestions, add comments, and see the plans for the next QtWebKit releases.

QtWebKit is truly open to contributions, so you don't have to work for Qt Development Frameworks or Nokia in order to implement new features and be assigned with a feature suggestion in JIRA. If you're planning to work on a new QtWebKit feature, it's a good idea to send email to ​webkit-qt@webkit.org and discuss the new feature with others. You can also post a comment to a JIRA item about the new feature, indicating your interest.

The JIRA system is only used for high level feature planning. The QtWebKit team uses the webkit.org Bugzilla for bugs and small implementation tasks, similarly as the other parts of the WebKit project. So please don't add bug reports or minor technical tasks to JIRA, but instead add them to Bugzilla. Note that all bug reports, even those that are specific to the Qt port of WebKit, are hosted in Bugzilla, not in the Qt bugtracker.

Since all feature development for WebKit happens via Bugzilla entries, please add links to the relevant Bugzilla entries to your JIRA items.

Getting started with JIRA

The Qt bug tracker is hosted at ​http://bugreports.qt.nokia.com. The first thing you need to do is to sign up - just click the sign up link on the welcome page to create a user account.

That's it! You're now ready to ​browse the QtWebKit project in JIRA, "watch" items to subscribe email notifications of any changes, and add new items to the QtWebKit project.

JIRA has a separate QtWebKit project for this work. The Qt project in JIRA is used for other parts of Qt - please don't add any QtWebKit related items there, even if they would only concern the Qt port of WebKit.

Using JIRA issue types and workflows

Use the suggestion issue type for new features and new significant non-functional improvements, such as major performance work.

Use the task issue type for testing and verification tasks that do not directly map into a new suggestion.

Use a sub-task or a number of sub-tasks of a suggestion for documenting the testing plan of a new feature. It's extremely useful to document the planned testing approach, even if it was simply layout tests or Qt autotests.

When you're planning to work on a new feature, you should become the assignee for the feature. You can then "accept" the suggestion, so its status becomes "Open".

When you've started the work, click the "start work" action, which sets the status of the item to "In progress".

When all planned patches have landed into webkit.org trunk, you're ready to click the "fixed" workflow action, and the suggestion will become "resolved". This doesn't yet mean that the feature has been verified to work.

Once all the planned testing sub-tasks or separate tasks have been done, you can set the tasks/subtasks as done, add the results of the testing in a comment of the (sub-)task, and then click the "passes the test" workflow action on the suggestion. This sets the status of the suggestion as "Verified".

If the testing of the feature reveals bugs or gaps in the implementation, then paste the results of the testing to the task, and click the "does not pass the test" action on the suggestion. This will set the suggestion back to the "In progress" state.