Difference between revisions of "Issue lifecycle"

Revision as of 12:48, 10 July 2012

Writing an issue (Everyone)

No support requests 

Ask on the user mailing list or community forum to make sure that you do not miss something in handling of AOO. ToDo: Add link to support information

No duplicates 

Search in Bugzilla whether your problem is already reported.

Reproducible 

Write a short and precise description on how to reproduce your problem. A small document, that contains only those parts, which are needed to reproduce the problem, is helpful and a screen-shot as well.

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

ToDo: Add link to guide for using Bugzilla

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 the field 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 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 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. 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? Then 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? 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 an 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 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. 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.