Hi everyone,

I've documented our practices for feature planning and JIRA usage in this wiki 
page:
https://trac.webkit.org/wiki/QtWebKitFeaturePlanning. 

All comments are most welcome!

I'm also pasting the wiki page below.

Best regards,
Henry



= 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 [email protected] 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 [http://bugreports.qt.nokia.com/browse/QTWEBKIT 
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. 


 

_______________________________________________
webkit-qt mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt

Reply via email to