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.
Difference between revisions of "Papyrus-RT/Bug Guidelines"
(→Guidelines: Updated guidelines) |
(Improved consistency of terms uasge, resolved bullet issues, fixed typos) |
||
| Line 8: | Line 8: | ||
=Guidelines= | =Guidelines= | ||
==Definitions== | ==Definitions== | ||
| − | * Product | + | *Product Lead (a.k.a., product owner, product manager) |
| − | * | + | **The person responsible of determining the content of a release, milestone, etc. |
| − | * Development Lead (a.k.a., development owner, development manager, Scrum Master) | + | *Development Lead (a.k.a., development owner, development manager, Scrum Master) |
| − | * | + | **The technical responsible for the development of the software, e.g., code, build, etc. |
| − | * Committer: Someone who is working on the development of the Papyrus-RT project. | + | *Committer: Someone who is working on the development of the Papyrus-RT project. |
==New Bug== | ==New Bug== | ||
#When a bug is entered, it starts life as unconfirmed, unless entered by a committer in which case it is marked as new | #When a bug is entered, it starts life as unconfirmed, unless entered by a committer in which case it is marked as new | ||
#* If a bug is created by copying information from another (source) bug, then to ensure full history and traceability, this must be indicated in the new bug with a '''"See Also"''' link to the source bug. The source bug must also be included in the new bug's '''"See Also"''' list. | #* If a bug is created by copying information from another (source) bug, then to ensure full history and traceability, this must be indicated in the new bug with a '''"See Also"''' link to the source bug. The source bug must also be included in the new bug's '''"See Also"''' list. | ||
==Triage== | ==Triage== | ||
| − | #On a weekly basis, the Product | + | #On a weekly basis, the Product and Development Leads 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 and Development Leads for Papyrus-RT will be responsible for backlog grooming, where "Fix Versions" are updated as we progress through a release. |
#The bug is then be assigned for someone to fix and the status is set to assigned. Assignment of a bug can be done in one of several ways: | #The bug is then be assigned for someone to fix and the status is 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 | #*Someone volunteers for a bug and assigns it to themselves | ||
| − | #*A Product | + | #*A Product Lead or someone assigned the task of managing backlog will do this. |
#*Bugs should not be worked on unless they are assigned. | #*Bugs should not be worked on unless they are assigned. | ||
| − | #When a bug is assigned to someone to be fixed, a '''"fix version"''' must be set. This is important so that the | + | #When a bug is assigned to someone to be fixed, a '''"fix version"''' must be set. This is important so that the Product and Development Leads 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 | + | #Bugs should not be pulled back from later releases without the Product Lead’s approval. |
| − | == | + | ==Tagging Dependencies on base Papyrus== |
#If a bug '''has''' or is '''suspected to have''' a dependency on base Papyrus: | #If a bug '''has''' or is '''suspected to have''' a dependency on base Papyrus: | ||
#*The bug must be identified as being blocked by using the '''"depends_on_papyrus"''' Whiteboard tag | #*The bug must be identified as being blocked by using the '''"depends_on_papyrus"''' Whiteboard tag | ||
| Line 34: | Line 34: | ||
#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, for simple fixes only, 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 | #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, for simple fixes only, 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 | ||
==Closing bugs== | ==Closing bugs== | ||
| − | #Verified bugs are then closed by either the originator or by the | + | #Verified bugs are then closed by either the originator or by the Product Lead |
Latest revision as of 14:06, 26 April 2017
Bug Guidelines
Contents
Introduction
This page describes the guidelines and governance for managing Papyrus for Real Time bugs in Bugzilla.
Guidelines
Definitions
- Product Lead (a.k.a., product owner, product manager)
- The person responsible of determining the content of a release, milestone, etc.
- Development Lead (a.k.a., development owner, development manager, Scrum Master)
- The technical responsible for the development of the software, e.g., code, build, etc.
- Committer: Someone who is working on the development of the Papyrus-RT project.
New Bug
- When a bug is entered, it starts life as unconfirmed, unless entered by a committer in which case it is marked as new
- If a bug is created by copying information from another (source) bug, then to ensure full history and traceability, this must be indicated in the new bug with a "See Also" link to the source bug. The source bug must also be included in the new bug's "See Also" list.
Triage
- On a weekly basis, the Product and Development Leads 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 and Development Leads for Papyrus-RT will be responsible for backlog grooming, where "Fix Versions" are updated as we progress through a release.
- The bug is then be assigned for someone to fix and the status is 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 Lead or someone assigned the task of managing backlog will do this.
- Bugs should not be worked on unless they are assigned.
- When a bug is assigned to someone to be fixed, a "fix version" must be set. This is important so that the Product and Development Leads 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 Lead’s approval.
Tagging Dependencies on base Papyrus
- If a bug has or is suspected to have a dependency on base Papyrus:
- The bug must be identified as being blocked by using the "depends_on_papyrus" Whiteboard tag
- A new bug must be created on base Papyrus, explaining the problem encountered in the context of Papyrus - it is not sufficient to simply copy the content of the Papyrus-RT bug into this new bug.
- This new bug must be identified has blocking Papyrus-RT by using the "blockingpapyrusrt" Whiteboard tag.
Resolving bugs
- 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 "test" keyword is added to the bug. The comments must also indicate that the bug only lacks a test.
Verifying bugs
- 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, for simple fixes only, 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
Closing bugs
- Verified bugs are then closed by either the originator or by the Product Lead