User:Regina/MYDrafts4

Issues Lifecycle

Writing an issue (Everyone)

1. No support requests. Ask on mailing list or forum to make sure, that you do not miss something in handling of AOO.
2. No duplicates. Search in Bugzilla, whether your problem is already reported.
3. Reproducible. Write a short and precise description, how to reprocude your problem. A small document, that containes only those parts, which are needed to reproduce the problem, is helpful and a screenshot as well.

Newly written issues should always have the state "Unconfirmed", even if you have the rights to set it to "Confirmed".

Make sure it is a valid issue (QA)

1. Is the description suitable to 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 INVALID. Comment like "Feel free to reopen the issue, when you can provide the needed information." Submit changes and then set status to CLOSED.

2. Make sure AOO is affected.

• Is it a support request? Then resolve the issue as INVALID 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 INVALID. 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 such discussion has been recently. Point the reporter to the thread.
• Is the bug only in a special distribution but not in AOO? In that case resolve the issue with reason "INVALID". 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.

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? Then set the status to "CONFIRMED" and the issue type to "ENHANCEMANT" or "FEATURE". Does the feature request contradict the ODF specification? Put this 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? Then examine the fields "Product" and "Component" and correct them if necessary. Can you already narrow the root of the bug? Or give a more suitable test document? Provide all such information, that might help developers to fix it. Set status to "CONFIRMED".

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.

6. Does the bug fulfill the criteria for a "release blocker", then set the flag and inform the ooo-dev mailing list.

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

Work on the issue (Developer)

1. 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".
2. You found the root cause, but fixing it will last a while? Then write a intermediate comment. Does the fix depend on the fix for another issue? Then enter the issue number in the field "Depends on".
3. You have a fix for the issue but no commit rights or want a review before commiting? 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". Inform the ooo-dev list.
4. The patch is submitted? 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.
5. In case of a feature request: If you think, it should not be implemented, discuss this on the 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)

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.