Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Papyrus-RT/Bug Guidelines
< Papyrus-RT
Revision as of 14:22, 27 September 2016 by Charles.zeligsoft.com (Talk | contribs) (Added guidelines)
Bug Guidelines
Contents
Introduction
This page describes the guidelines and governance for managing Papyrus for Real Time bugs in Bugzilla.
Guidelines
- When a bug is entered, it starts life as unconfirmed, unless entered by a committer in which case it is marked as new
- On a daily basis, the product manager or product owner will look at unconfirmed bugs and transition them to the new state or close them with one of: invalid, duplicate, won’t fix. The fix version will also be set at this time if it can be decided. The product manager and product owner for Papyrus-R will be responsible for backlog grooming, where fix versions are updated as we progress through a release.
- The bug will then be assigned to someone to work on and the status set to assigned. Assignment of a bug can be done in one of several ways:
- Someone volunteers for a bug and assigns it to themselves
- A product owner, product manager or someone assigned the task of managing backlog will do this.
- Bugs should not be worked unless they are assigned.
- When a bug is assigned to someone to be fixed, a fix version needs to be set. This is important so that the product owner can see if risky fixes are being considered and evaluate the risk based on how close we are to a milestone. Bugs should not be pulled back from later releases without the product owners’ approval.
- Once the bug has been addressed, the bug will be marked as resolved by the assignee. The status should also indicate how it has been addressed: fixed, invalid, “works for me”, duplicate, won’t fix. If appropriate, a test should also be submitted at the same time. If a test is required, but not submitted, then the bug stays in open or assigned and the keyword test is added to the bug. The comments should indicate that the bug only lacks a test.
- The bug fix then needs to be verified that it addresses the original problem. Ideally this is done by the originator, but can be done by anyone, including the person who resolved it. The bug status is then set to verified. If the originator or anyone else has a strong view on who should test the fix, then the QA contact field can be filled in
- Verified bugs are then closed by either the originator, or by the product manager