This page gives you a brief introduction to how issues are handled
winthin the OpenOffice.org Quality Assurance. Basically it describes
an issue's lifecycle and provides direct links to useful documentation.
You probably came to this page because you have a problem with OpenOffice.org.
Maybe the application crashed, misbehaved or something else just feels wrong to you.
So chances are that you found an issue/bug that should be fixed. When you are new to
writing issues this page should help you to understand the way an issue takes from
being found to finally being fixed.
It is recommended that you start by
logging in
to
IssueTracker.
If you want to learn about the benefits of IssueTracker please read
this abstract
Please search the IssueTracker database to make sure that your issue does not exist yet.
Do a quick search for
duplicates
or go to the more advanced
search form If your issue exists you might want to bookmark it or set yourself on CC
You did not find your issue in the database?
Good, go ahead and write a new one using the
submit form.
If you are unfamiliar with writing good Bugreports we recommend that you read
this document.
Following these rules really makes life easier for all.
If you want to dig a little deeper you might want to read these detailed
bug writing guidelines
as well.
The issue needs to be confirmed
When you are new to OpenOffice.org you don't have the permission to confirm
your issues yourself. So somebody with the required permissions will take over at this point.
The OOo volunteer will try to reproduce your problem and - in case
of failure - get back to you and ask some more questions. If reproduction succeeds
the issue gets a target and will be handed over to development for fixing. If the
issue can not be reproduced it is closed.
Your issue is added to a
CWS
(Childworkspace).
A childworkspace is created in which your issue is fixed by
a developer. When the fix is done the CWS is sent to QA.
The issue needs to be verified on the
CWS Your issue will now be verified, meaning that somebody (which could be you as well)
takes a look at it by installing a developer build from the CWS.
If the fix is not good
(failed completely or insufficient) it goes back to development.
The fix is good and gets
integrated
into the
MWS The issue now has the status fixed/verified and gets integrated into the main
development line and you can download it with the next developer snapshot.
Final verification of the fix
Again somebody verifies that the
fix did not by accident get lost or corrupted. If all went well the status is changed to
closed/fixed. On any problem the task gets back to development and the cycle starts anew.
Additional hint(s)
When working with issues you always have the possibility to find out where
in the process your task is currently located. You just have to look at the status
of your issue. If you want to know more about issue states, please take a look at the
issue lifecycle
document which explains issue states and how they fit into the process in great detail.
Autor: Joerg Skottke (Joerg.Skottke@oracle.com) March 28. 2007
Please do not change this site without acknowledge of the autor or the OOo QA Project Lead/Co-Leads.
