Skip to content

You are not logged in. Register orLog In

start:

Document written by: Joerg Skottke

About Issues - A Brief Guide

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.

Issue handling flowchart
  1. 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



  2. 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



  3. 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.



  4. 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.



  5. 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.



  6. 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.



  7. 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.



  8. 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@Sun.com) March 28. 2007

Please do not change this site without acknowledge of the autor or the OOo QA Project Lead/Co-Leads.