View source for Issue lifecycle

== Writing an issue (Everyone)==
For a detailed guide on how to create an issue, see [[QA/HowToFileIssue]]. Here are some brief notes, though:
; No support requests : Ask on the [https://openoffice.apache.org/mailing-lists.html#users-mailing-list user mailing list] or [https://forum.openoffice.org/en/forum/index.php community forum] to make sure that you do not miss something in handling of AOO. ''ToDo: Add link to support information''
; No duplicates : [https://issues.apache.org/ooo/query.cgi Search in Bugzilla] whether your problem is already reported.
; Reproducible : Write a short and precise description on how to reproduce your problem. In short, document only the essential parts needed to reproduce the problem, in a helpful way. Preferably, attach a screenshot.

Newly written issues should always have the state "Unconfirmed", if you are the only person, that has worked on it so far, even if you have the rights to set it to "Confirmed".

More info about submitting a bug:<br>https://forum.openoffice.org/en/forum/viewtopic.php?f=74&t=13490

== Make sure it is a valid issue (QA + Developer)==
'''1. Is the description suitable to understand and reproduce the problem?'''

If not, ask the reporter and set keyword "needmoreinfo". If no answer after fourteen days, set the field ''status'' to RESOLVED and the reason to ''IRREPRODUCIBLE''. Comment like "Feel free to reopen the issue, when you can provide the needed information." Submit changes and then set the field ''status'' to CLOSED.

'''2. Make sure AOO is affected.'''
* Is it a support request? Then resolve the issue as ''IRREPRODUCIBLE'' and point the submitter to mailing list and forum.
* Does AOO works as designed, but the reporter expects something different? Set the status to RESOLVED and reason to ''IRREPRODUCIBLE''. Point the reporter to the UX group to discuss, how AOO can be improved to meet user expectations. The reason WONTFIX might be appropriate, if the problem has been discussed recently, and the request was rejected. Point the reporter to the thread. ''ToDo: Add mailing list address or home page of UX on Wiki''
* Is the bug only in a special distribution but not in AOO? In that case resolve the issue with reason ''IRREPRODUCIBLE''. Point the reporter to a suitable issue tracker.

'''3. Has the problem already been reported?'''
* Search not only in field "Summary" but in field "Comment" as well.
* Include closed issues in your search, they might lead you to an active duplicate one.
* The existing issues might have wrong components. Therefor restrict your search only, if you get too many hits.
* Be aware that graphic, image, and picture are used interchangeable by issue reporters. Find other synonymous keywords on [[Synonymous_keywords]].

If you find a duplicate, set field ''status'' to RESOLVED and reason to DUPLICATE. Then you get another field. Enter the number of the duplicate issue there. The other issue gets automatically a link. Submit the changes. Then close the issue.

You are likely to find more than one duplicate. Look, which one has the most votes and/or the best description and close the others with setting "Duplicate".

'''4. Is it a feature request?'''
* Set the the field ''status'' to CONFIRMED and the issue type to ENHANCEMANT or FEATURE.
* Does the feature request contradict the ODF specification? Put this info into your comment and point the reporter to OASIS. Such requests need additional work.
* Examine the fields ''Product'' and ''Component'' and correct them if necessary.
* Has the feature request been discussed or does a specification exists in the Wiki? Put a link to it in the field URL.

In case of a bug report further work is needed.

'''5. Can you reproduce the bug?'''
* If you can reproduce the bug, then examine the fields ''Product'', ''Component'', and ''Issue Type'', and correct them if necessary.
* If your test version is newer than the reported version, select your version from the field ''Latest confirmation on''. Or if you use a developer build, add the revision number in your comment.
* Examine the field ''Platform''. If the reporter has set it to ''all'' but has not mentioned in his description on what platforms (plural!) he has tested, then set the operating system to your system. If you have reproduced the bug on a total different system than the reporter (e.g. reporter WinXP, you MacOS), then set the operating system to ''all'' and mention the systems in your comment.
* Examine the description. Could you reproduce the bug with that description, or could you only reproduce it with playing around? Have you reproduced it with less steps? Give an improved description if necessary.
* If a test document is attached, look whether it is suitable. Often test documents contain much more as needed to reproduce the bug. Remove all things, that not needed. If no test document is attached, but a test document would be helpful, then produce a test document (as small as possible!) and attach it.
* Would a screen shot or a video clip help to understand, what is wrong? Then try to produce them and attach it.
*If you cannot reproduce the bug, the error might depend on the operating system or other environment conditions. Resolve issue with reason ''IRREPRODUCIBLE'', but leave issue open and set keyword "needhelp". If you cannot reproduce the bug using the same environment as the reporter, close the issue.
*In case of import, is AOO able to reflect the mentioned property of the alien document format? Exists this property already in the ODF specification? In case of export, is the alien document format able to reflect the mentioned property of AOO? Include this informations in your comment. Close the bug or made it an enhancement.

'''6. How important is the issue?'''
*Examine the field "Importance". Reporters tend to set it to inappropriate values.
*Does the bug fulfill the criteria for a "release blocker", then not only select "Blocker" but inform the ooo-dev mailing list in addition.
*Crashes and scenarios with data loss in common user actions get at least the importance ''P2 major''.
If unsure about this, use the setting ''P3 normal''.  

'''7. Help the developer with additional informations'''
*Minimize the scenario to reproduce the bug. 
*Try to reproduce the bug with an older version of AOO or OOo. If you find, that it works there, add the keyword ''regression''.
*If you work on an older, unconfirmed OOo bug and have reproduced it with a new AOO version, select the version in the field ''Latest confirmation on''.
*Do you get additional information by using a debug build?
*In case of a crash, can you produce a backtrace?
*Use keywords and tags in summary to classify the bug. For example for import and export to the Microsoft Office 97 formats the tag WW8: in the summary is used. Also the keyword ''ms_interoperability'' is likely suitable for such import/export problems.  

If the issue is still open after all the previous steps, set the status to CONFIRMED.

If you have not the rights to do the suggested changes, then write it as suggestion into the comment.

== Work on the issue (Developer)==
# If you want to fix the issue, set the status to ACCEPTED and assign it to yourself by clicking on "take" in the line "Assigned to".
# You found the root cause, but fixing it may take a while? Then write an intermediate comment. Does the fix depend on the fix for another issue? Then enter the issue number in the field "Depends on".
# You have a fix for the issue but no commit rights or want a review before committing? Generate a patch and attach it to the issue. Make sure you use the type "Patch" in the upload. Set the issue type to PATCH. In most cases, you will need review of the patch. When you attache the patch in Bugzilla, use '''Flags/review''' and set to "?" to alert the issues mailing list that a review is needed. You may also want to inform the ooo-dev list. In this case, the patch will be reviewed and/or discussed further or committed.
# The patch is submitted (committed)? Write a comment to the issue, where you reference the revision number. Set the status to RESOLVED with reason FIXED. Do not close the issue.
# In case of a feature request: If you think, it should not be implemented, discuss this on the development mailing list and if your opinion gets consensus, set the status to RESOLVED with reason WONTFIX. Explain the reason in the comment and put the link to the discussion in field URL. Close the issue.


== Verify the fix (QA + Developer)==
Use a developer version or a released version which contains the fix and try to reproduce the bug.

If you can no longer reproduce it, comment with "Verified in version <revision number>". If you know areas which might be affected by the fix, test them too. Close the issue.

If you still can reproduce the bug, set the status to REOPEN and explain why.

[[Category:Quality Assurance]]