Changes between Initial Version and Version 1 of QtWebKitFeaturePlanning

Mar 24, 2010 1:36:44 AM (12 years ago)
Henry Haverinen



  • QtWebKitFeaturePlanning

    v1 v1  
     2= Feature planning for QtWebKit =
     4== Overview ==
     6The 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.
     8QtWebKit 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 and discuss the new feature with others. You can also post a comment to a JIRA item about the new feature, indicating your interest.
     10The JIRA system is only used for high level feature planning. QtWebKit uses the 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.
     12Since all feature development for WebKit happens via Bugzilla entries, please add links to the relevant Bugzilla entries to your JIRA items.
     14== Getting started with JIRA ==
     16The Qt bug tracker is hosted at 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.
     18That'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.
     20JIRA 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.
     22== Using JIRA issue types and workflows ==
     24Use the '''suggestion''' issue type for new features and new significant non-functional improvements, such as major performance work.
     26Use the '''task''' issue type for testing and verification tasks that do not directly map into a new suggestion.
     28Use 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. 
     30When 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".
     32When you've started the work, click the "start work" action, which sets the status of the item to "In progress".
     34When all planned patches have landed into 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.
     36Once 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".
     38If 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.